From djkr at msn.com Sun Jul 1 05:07:03 2007 From: djkr at msn.com (DJK(John) Robinson) Date: Sun, 1 Jul 2007 11:07:03 +0100 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) In-Reply-To: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> Message-ID: Hi Joe, Not sure I fully understand the setup, but here goes. Since your question is about ordering the seeing of notes, I presume you already have some access control in place, so that the system knows whether the current user is D,S,M or E (Dispatcher, Supervisor, etc). I'd probably put all the notes in one table, with each record time-stamped on creation, and identified by employee and creator-type (S,M or E). Then querying can exclude records that the current user shouldn't see, and order on the creation time-stamp. If for some reason you *have* to have separate tables, then still time-stamp records on creation, but use an appropriate union query to bring together the right set for the current user. Or have I misunderstood something? John -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe Hecht Sent: 01 July 2007 00:08 To: 'Access Developers discussion and problem solving' Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Sun Jul 1 07:59:17 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 08:59:17 -0400 Subject: [AccessD] Open a combobox on entering it Message-ID: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> In a couple of apps I've seen, the comboboxes automatically open when you enter them. How is that done? I'm working on an app where the lists are smallish and I'd like to do it. Arthur From ssharkins at setel.com Sun Jul 1 08:12:13 2007 From: ssharkins at setel.com (Susan Harkins) Date: Sun, 1 Jul 2007 09:12:13 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> References: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> Message-ID: <002e01c7bbe1$71993450$2534fad1@SusanOne> Use the control's Dropdown property Susan H. In a couple of apps I've seen, the comboboxes automatically open when you enter them. How is that done? I'm working on an app where the lists are smallish and I'd like to do it. Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.10/873 - Release Date: 6/26/2007 11:54 PM From fuller.artful at gmail.com Sun Jul 1 08:29:57 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 09:29:57 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <002e01c7bbe1$71993450$2534fad1@SusanOne> References: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> <002e01c7bbe1$71993450$2534fad1@SusanOne> Message-ID: <29f585dd0707010629s49d0e71am31470d2f846ac354@mail.gmail.com> I'd love to, but I can't find it. It's an Access 2003 ADP. Does that matter? Arthur On 7/1/07, Susan Harkins wrote: > > Use the control's Dropdown property > > Susan H. > > In a couple of apps I've seen, the comboboxes automatically open when you > enter them. How is that done? I'm working on an app where the lists are > smallish and I'd like to do it. > > Arthur > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.9.10/873 - Release Date: 6/26/2007 > 11:54 PM > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From ssharkins at setel.com Sun Jul 1 08:39:35 2007 From: ssharkins at setel.com (Susan Harkins) Date: Sun, 1 Jul 2007 09:39:35 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707010629s49d0e71am31470d2f846ac354@mail.gmail.com> References: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com><002e01c7bbe1$71993450$2534fad1@SusanOne> <29f585dd0707010629s49d0e71am31470d2f846ac354@mail.gmail.com> Message-ID: <003d01c7bbe5$45e88640$2534fad1@SusanOne> Well Arthur, I guess that's possible, but I don't know why -- the control is still an Access object isn't it? You'd think it would still be available. Susan H. I'd love to, but I can't find it. It's an Access 2003 ADP. Does that matter? From fuller.artful at gmail.com Sun Jul 1 08:44:51 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 09:44:51 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <003d01c7bbe5$45e88640$2534fad1@SusanOne> References: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> <002e01c7bbe1$71993450$2534fad1@SusanOne> <29f585dd0707010629s49d0e71am31470d2f846ac354@mail.gmail.com> <003d01c7bbe5$45e88640$2534fad1@SusanOne> Message-ID: <29f585dd0707010644t19151d2es281f7c491adfc86f@mail.gmail.com> It's not in the Intellisense either. I think I'll try opening the app in Access 2000 and see if it's there. On 7/1/07, Susan Harkins wrote: > > Well Arthur, I guess that's possible, but I don't know why -- the control > is > still an Access object isn't it? You'd think it would still be available. > > Susan H. > > I'd love to, but I can't find it. It's an Access 2003 ADP. Does that > matter? > > From rockysmolin at bchacc.com Sun Jul 1 09:06:25 2007 From: rockysmolin at bchacc.com (rockysmolin at bchacc.com) Date: Sun, 1 Jul 2007 10:06:25 -0400 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) Message-ID: <380-2200770114625873@M2W040.mail2web.com> Joe: I've got a simple schemeto control access levels. I can handle it with you off line. But I'm out of town right now. Won't be back until next Sunday. Can it wait? Anyone who knows access can defeat this scheme but in an environment where people are behaving this works well. Here's the basic steps: 1. Create a User table - Autonumber, User Name, Password, Accesss Level. 2. Create a global variable gintAccessLevel 3. On the opening form load the names and passwords into a combo box. Prompt for user name and password. 4. Store user's access level in gintAccessLevel. 5. On each form oreach function where you want to restrict access check the user access level and bail if the level's not correct. HTH ROcky Original Message: ----------------- From: Joe Hecht jmhecht at earthlink.net Date: Sat, 30 Jun 2007 16:08:12 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web From rockysmolin at bchacc.com Sun Jul 1 09:09:55 2007 From: rockysmolin at bchacc.com (rockysmolin at bchacc.com) Date: Sun, 1 Jul 2007 10:09:55 -0400 Subject: [AccessD] Open a combobox on entering it Message-ID: <380-2200770114955828@M2W008.mail2web.com> Me.cboMyBox.DropDown won't work in the Got Focus event of the box? Rocky Original Message: ----------------- From: Arthur Fuller fuller.artful at gmail.com Date: Sun, 1 Jul 2007 08:59:17 -0400 To: accessd at databaseadvisors.com Subject: [AccessD] Open a combobox on entering it In a couple of apps I've seen, the comboboxes automatically open when you enter them. How is that done? I'm working on an app where the lists are smallish and I'd like to do it. Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- mail2web.com ? What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint From fuller.artful at gmail.com Sun Jul 1 10:10:03 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 11:10:03 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <380-2200770114955828@M2W008.mail2web.com> References: <380-2200770114955828@M2W008.mail2web.com> Message-ID: <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> That was the ticket. Thanks, Rocky. I was using OnEnter. Now it works. Yay!. On 7/1/07, rockysmolin at bchacc.com wrote: > > Me.cboMyBox.DropDown won't work in the Got Focus event of the box? > > Rocky > > > Original Message: > ----------------- > From: Arthur Fuller fuller.artful at gmail.com > Date: Sun, 1 Jul 2007 08:59:17 -0400 > To: accessd at databaseadvisors.com > Subject: [AccessD] Open a combobox on entering it > > > In a couple of apps I've seen, the comboboxes automatically open when you > enter them. How is that done? I'm working on an app where the lists are > smallish and I'd like to do it. > > Arthur > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > > -------------------------------------------------------------------- > mail2web.com ? What can On Demand Business Solutions do for you? > http://link.mail2web.com/Business/SharePoint > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From fuller.artful at gmail.com Sun Jul 1 12:06:47 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 13:06:47 -0400 Subject: [AccessD] Never Take a job for a friend (Three level design question) In-Reply-To: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> Message-ID: <29f585dd0707011006w7126a816l9f2ee03b307d66eb@mail.gmail.com> I think that some of the respondents so far kind of missed your requirements, Joe (or perhaps the beer I'm enjoying for Canada has had more effect than I anticipated). You actually have only 3 meaningful user levels, since dispatchers are powerless. The other three make a grid like this: Sup Mgr Exec Sup W X X Mgr R W X Exec R R W Where R means Read, W means Write, and X means neither. If the user table contained a 3-char column with each horizontal combination written as a string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine the current row's notes field and act accordingly. This demands of course that the Notes rows be tagged with UserLevel column (S, M or E). If a Sup is looking and the current Notes.UserLevel column contains M or E, hide the Notes. If a Mgr is looking and the current Notes UserLevel contains S, then Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. If an Exec is looking, and the current Notes UserLevl contains S or M, Notes.enabled = False, else Notes.Enabled = True. I think that covers it. hth, Arthur This problem will be much easier to deal with if the notes are presented in single-form fashion rather than datasheet. That said, On 6/30/07, Joe Hecht wrote: > > It is simple. Ya Right > > > > I am righting a poor mans HR program. There are four user levels. > Dispatchers can not do notes, can not see notes. Field supervisor can > write > notes. Can not see manager or executive notes. Managers can write notes, > can read Field supervisor notes, not edit them or see executive notes. > Executives can write theirs, see but not edit all other notes. > > > > Notes are many notes to one employee. > > > > How do I do notes so people see them in chronological order? If I do three > sub tables how would I get all notes to same point. One employee can have > multiple incidents good and bad in their record. How would I get all three > levels of notes to same incident? > > > > Ya all know where I am spending my sat night. > > > > > > > > Joe Hecht > > jmhecht at earthlink.net > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From fuller.artful at gmail.com Sun Jul 1 12:07:49 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 13:07:49 -0400 Subject: [AccessD] Never Take a job for a friend (Three level design question) In-Reply-To: <29f585dd0707011006w7126a816l9f2ee03b307d66eb@mail.gmail.com> References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> <29f585dd0707011006w7126a816l9f2ee03b307d66eb@mail.gmail.com> Message-ID: <29f585dd0707011007s2bb4f993s9e9b8638acf37813@mail.gmail.com> Minor addendum, perhaps obvious. If a dispatcher is looking, hide the Notes, period. Arthur On 7/1/07, Arthur Fuller wrote: > > I think that some of the respondents so far kind of missed your > requirements, Joe (or perhaps the beer I'm enjoying for Canada has had more > effect than I anticipated). > > You actually have only 3 meaningful user levels, since dispatchers are > powerless. The other three make a grid like this: > > Sup Mgr Exec > Sup W X X > Mgr R W X > Exec R R W > > Where R means Read, W means Write, and X means neither. If the user table > contained a 3-char column with each horizontal combination written as a > string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine the > current row's notes field and act accordingly. > > This demands of course that the Notes rows be tagged with UserLevel column > (S, M or E). > > If a Sup is looking and the current Notes.UserLevel column contains M or > E, hide the Notes. > If a Mgr is looking and the current Notes UserLevel contains S, then > Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. > If an Exec is looking, and the current Notes UserLevl contains S or M, > Notes.enabled = False, else Notes.Enabled = True. > > I think that covers it. > > hth, > Arthur > > > This problem will be much easier to deal with if the notes are presented > in single-form fashion rather than datasheet. That said, > > > On 6/30/07, Joe Hecht wrote: > > > > It is simple. Ya Right > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > Dispatchers can not do notes, can not see notes. Field supervisor can > > write > > notes. Can not see manager or executive notes. Managers can write > > notes, > > can read Field supervisor notes, not edit them or see executive notes. > > Executives can write theirs, see but not edit all other notes. > > > > > > > > Notes are many notes to one employee. > > > > > > > > How do I do notes so people see them in chronological order? If I do > > three > > sub tables how would I get all notes to same point. One employee can > > have > > multiple incidents good and bad in their record. How would I get all > > three > > levels of notes to same incident? > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > Joe Hecht > > > > jmhecht at earthlink.net > > > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > From miscellany at mvps.org Sun Jul 1 15:36:12 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 08:36:12 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> Message-ID: <4688103C.7040209@mvps.org> Arthur, I'm pleased you have it working. However, I am not sure what the problem was before. I have often done this on the Enter event of a combobox, and I think it has always worked for me. Regards Steve Arthur Fuller wrote: > That was the ticket. Thanks, Rocky. I was using OnEnter. Now it works. Yay!. > From fuller.artful at gmail.com Sun Jul 1 16:35:10 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 17:35:10 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <4688103C.7040209@mvps.org> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> Message-ID: <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> Maybe it did in prior versions, but in 2003 it's easy enough to check. Whip up a test screen with a combo on it and then open the OnEnter event and use intellisense. The dropdown attribute disappears from the list. Arthur On 7/1/07, Steve Schapel wrote: > > Arthur, > > I'm pleased you have it working. However, I am not sure what the > problem was before. I have often done this on the Enter event of a > combobox, and I think it has always worked for me. > > Regards > Steve > > > Arthur Fuller wrote: > > That was the ticket. Thanks, Rocky. I was using OnEnter. Now it works. > Yay!. > > > - From miscellany at mvps.org Sun Jul 1 17:33:21 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 10:33:21 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> Message-ID: <46882BB1.4080200@mvps.org> Hi Arthur, I have been working with Access 2003 almost exclusively for several years, so very familiar with it. I would have used this method hundreds of times. I have no explanation for why this is not working for you. Me.NameOfYourCombobox.Dropdown Regards Steve Arthur Fuller wrote: > Maybe it did in prior versions, but in 2003 it's easy enough to check. Whip > up a test screen with a combo on it and then open the OnEnter event and use > intellisense. The dropdown attribute disappears from the list. From jmhecht at earthlink.net Sun Jul 1 22:08:56 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Sun, 1 Jul 2007 20:08:56 -0700 Subject: [AccessD] Code help please Message-ID: <003601c7bc56$54b69650$6701a8c0@ACER2G> Hi all wise and mighty list. A2k3 I have a field job title. All job titles require license information unless job tile = admin Silly me I set required in table rules. I need some code that says something like If job title <> "admin" (string) Then Issueing agency .required = true Licenseexp.required = true dotExpdate.required =true I do not see a .required property that I can set in code. TIA Joe Hecht jmhecht at earthlink.net From miscellany at mvps.org Sun Jul 1 22:35:25 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 15:35:25 +1200 Subject: [AccessD] Code help please In-Reply-To: <003601c7bc56$54b69650$6701a8c0@ACER2G> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> Message-ID: <4688727D.6020205@mvps.org> Hi Joe, I think there are two approaches you could take here. First approach... Go to the design view of the table. Set the Required property for all these fields to No. Select 'Properties' from the View menu. In the Validation Rule property, something like this... ([job title]="admin") Or ([Issueing agency] Is Not Null And [Licenseexp] Is Not Null And [dotExpdate] Is Not Null) Validation Text property can be set as required. This assumes no Default Values. Second approach... Code on the Before Update event of the form, for example... If Me.job_title <> "admin" Then If IsNull(Me.Issueing_agency + Me.Licenseexp + Me.dotExpdate) Then MsgBox "Some stuff missing" End If End If Regards Steve Joe Hecht wrote: > Hi all wise and mighty list. > > > > A2k3 > > > > I have a field job title. > > > > All job titles require license information unless job tile = admin > > > > Silly me I set required in table rules. > > > > I need some code that says something like > > > > If job title <> "admin" (string) > > > > Then > > > > Issueing agency .required = true > > Licenseexp.required = true > > dotExpdate.required =true > > > > I do not see a .required property that I can set in code. > > > > TIA > > > > > > > > > > > > Joe Hecht > > jmhecht at earthlink.net > > > From jmhecht at earthlink.net Sun Jul 1 22:42:20 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Sun, 1 Jul 2007 20:42:20 -0700 Subject: [AccessD] Code help please In-Reply-To: <4688727D.6020205@mvps.org> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> <4688727D.6020205@mvps.org> Message-ID: <003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> I will take a look. Still would prefer to code the required field by field. Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 01, 2007 8:35 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Code help please Hi Joe, I think there are two approaches you could take here. First approach... Go to the design view of the table. Set the Required property for all these fields to No. Select 'Properties' from the View menu. In the Validation Rule property, something like this... ([job title]="admin") Or ([Issueing agency] Is Not Null And [Licenseexp] Is Not Null And [dotExpdate] Is Not Null) Validation Text property can be set as required. This assumes no Default Values. Second approach... Code on the Before Update event of the form, for example... If Me.job_title <> "admin" Then If IsNull(Me.Issueing_agency + Me.Licenseexp + Me.dotExpdate) Then MsgBox "Some stuff missing" End If End If Regards Steve Joe Hecht wrote: > Hi all wise and mighty list. > > > > A2k3 > > > > I have a field job title. > > > > All job titles require license information unless job tile = admin > > > > Silly me I set required in table rules. > > > > I need some code that says something like > > > > If job title <> "admin" (string) > > > > Then > > > > Issueing agency .required = true > > Licenseexp.required = true > > dotExpdate.required =true > > > > I do not see a .required property that I can set in code. > > > > TIA > > > > > > > > > > > > Joe Hecht > > jmhecht at earthlink.net > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Sun Jul 1 22:52:03 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 15:52:03 +1200 Subject: [AccessD] Code help please In-Reply-To: <003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> <4688727D.6020205@mvps.org> <003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> Message-ID: <46887663.6000404@mvps.org> Hi Joe, Joe Hecht wrote: > Still would prefer to code the required field by field. As far as I know, this is not possible. Regards Steve From miscellany at mvps.org Sun Jul 1 22:55:04 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 15:55:04 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> Message-ID: <46887718.30704@mvps.org> Hi Arthur, I just had a further thought about this... You need to use the name of the combobox. If you have named the control different from the field it is bound to, and if you are using the name of the field in your code, you will have problems. Regards Steve Arthur Fuller wrote: > Maybe it did in prior versions, but in 2003 it's easy enough to check. Whip > up a test screen with a combo on it and then open the OnEnter event and use > intellisense. The dropdown attribute disappears from the list. > From jmhecht at earthlink.net Sun Jul 1 22:57:01 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Sun, 1 Jul 2007 20:57:01 -0700 Subject: [AccessD] Code help please In-Reply-To: <46887663.6000404@mvps.org> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> <4688727D.6020205@mvps.org><003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> <46887663.6000404@mvps.org> Message-ID: <004901c7bc5d$0c55d2c0$6701a8c0@ACER2G> Thanks for help Steve Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 01, 2007 8:52 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Code help please Hi Joe, Joe Hecht wrote: > Still would prefer to code the required field by field. As far as I know, this is not possible. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Sun Jul 1 23:07:09 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 16:07:09 +1200 Subject: [AccessD] Code help please In-Reply-To: <46887663.6000404@mvps.org> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> <4688727D.6020205@mvps.org> <003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> <46887663.6000404@mvps.org> Message-ID: <468879ED.6000902@mvps.org> > As far as I know, this is not possible. ... unless you mean like this: Dim DataMissing As String If Me.job_title <> "admin" Then If IsNull(Me.Issueing_agency) Then DataMissing = "Issuing Agency, " End If If IsNull(Me.Licenseexp) Then DataMissing = DataMissing & "Licence Exp, " End If If IsNull(Me.dotExpdate) Then DataMissing = DataMissing & "Dot Exp Date, " End If If Len(DataMissing) Then DataMissing = Left(DataMissing, Len(DataMissing) - 2) MsgBox "Data entry required in " & DataMissing & "." End If End If Maybe a more elegant way of coding this, but just throwing the idea in the ring. :-) Regards Steve From thewaddles at sbcglobal.net Mon Jul 2 00:18:32 2007 From: thewaddles at sbcglobal.net (Kevin Waddle) Date: Sun, 1 Jul 2007 22:18:32 -0700 Subject: [AccessD] Manipulate AC95 mdb files without converting Message-ID: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> Access Guru's, I have a client that uses a VB application that creates and uses an Access 95 mdb. He would like to add data directly to the mdb from Access 2002 or Excel. Is it possible, directly or through an add-in, to manipulate data in an Access 95 file? Thank you, Kevin 3 out of 4 Americans make up 75% of the population. From anitatiedemann at gmail.com Mon Jul 2 00:26:04 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Mon, 2 Jul 2007 15:26:04 +1000 Subject: [AccessD] Manipulate AC95 mdb files without converting In-Reply-To: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> References: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> Message-ID: Kevin You should be able to simply open the database with any later versions of Access and enter data directly into it. Anita Smith Australia > Access Guru's, > > I have a client that uses a VB application that creates and uses an Access > 95 mdb. > > He would like to add data directly to the mdb from Access 2002 or Excel. > > Is it possible, directly or through an add-in, to manipulate data in an > Access 95 file? > > Thank you, > Kevin > > > 3 out of 4 Americans make up 75% of the population. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From thewaddles at sbcglobal.net Mon Jul 2 01:17:43 2007 From: thewaddles at sbcglobal.net (Kevin Waddle) Date: Sun, 1 Jul 2007 23:17:43 -0700 Subject: [AccessD] Manipulate AC95 mdb files without converting In-Reply-To: References: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> Message-ID: <00ef01c7bc70$b3da5da0$6600a8c0@TheWaddles> Anita, I'm sorry I didn't make it clear what I am trying to do. But your suggestion pointed me in the right direction. I am trying to import data from an Excel file into the AC95 db. What I ended up doing is creating an Access Object within Excel and running a RunSQL command on each line in the Excel Sheet. Thank you, Kevin 355/113 - Not the famous number Pi, but a great simulation! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Sunday, July 01, 2007 10:26 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Manipulate AC95 mdb files without converting Kevin You should be able to simply open the database with any later versions of Access and enter data directly into it. Anita Smith Australia > Access Guru's, > > I have a client that uses a VB application that creates and uses an > Access > 95 mdb. > > He would like to add data directly to the mdb from Access 2002 or Excel. > > Is it possible, directly or through an add-in, to manipulate data in > an Access 95 file? > > Thank you, > Kevin > > > 3 out of 4 Americans make up 75% of the population. > > -- > 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 Mon Jul 2 02:47:34 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 2 Jul 2007 03:47:34 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <46887718.30704@mvps.org> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> <46887718.30704@mvps.org> Message-ID: <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> That could be it. I did name the combo after the field. On 7/1/07, Steve Schapel wrote: > > Hi Arthur, > > I just had a further thought about this... You need to use the name of > the combobox. If you have named the control different from the field it > is bound to, and if you are using the name of the field in your code, > you will have problems. > > Regards > Steve > From miscellany at mvps.org Mon Jul 2 02:53:10 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 19:53:10 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> <46887718.30704@mvps.org> <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> Message-ID: <4688AEE6.7000200@mvps.org> Hmmm. Well, in that case, probably not. If the control and the field are both named the same as each other, then you can't get it wrong! :-) Regards Steve Arthur Fuller wrote: > That could be it. I did name the combo after the field. > From fuller.artful at gmail.com Mon Jul 2 05:04:31 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 2 Jul 2007 06:04:31 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <4688AEE6.7000200@mvps.org> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> <46887718.30704@mvps.org> <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> <4688AEE6.7000200@mvps.org> Message-ID: <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. Arthur On 7/2/07, Steve Schapel wrote: > > Hmmm. Well, in that case, probably not. If the control and the field > are both named the same as each other, then you can't get it wrong! :-) > > Regards > Steve > > From ewaldt at gdls.com Mon Jul 2 05:49:14 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Mon, 2 Jul 2007 06:49:14 -0400 Subject: [AccessD] The Business Side Of Databases In-Reply-To: Message-ID: Maybe VB. NYET. ;-) Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems (586) 825-4838 Message: 4 Date: Fri, 29 Jun 2007 13:15:48 -0400 From: "jwcolby" Subject: Re: [AccessD] The Business Side Of Databases To: "'Access Developers discussion and problem solving'" Message-ID: <20070629171552.A85F1BE98 at smtp-auth.no-ip.com> Content-Type: text/plain; charset="US-ASCII" That is exactly what I am looking for. Does it run VB.Net? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of ewaldt at gdls.com Sent: Friday, June 29, 2007 1:05 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] The Business Side Of Databases Hey, John, I just found my kids' old Timex Sinclair 1000. Would that be slow enough? :-) Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems Date: Thu, 28 Jun 2007 13:25:09 -0400 From: "jwcolby" Subject: Re: [AccessD] The Business Side Of Databases To: "'Access Developers discussion and problem solving'" Message-ID: <20070628172512.97DACBE52 at smtp-auth.no-ip.com> Content-Type: text/plain; charset="us-ascii" Well, I like the slower machine idea!!! Great minds think alike. In fact I am searching EBAY for some old Commodore 64 machines to make my servers. ;-) This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From JHewson at karta.com Mon Jul 2 07:59:11 2007 From: JHewson at karta.com (Jim Hewson) Date: Mon, 2 Jul 2007 07:59:11 -0500 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com><29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com><4688103C.7040209@mvps.org><29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com><46887718.30704@mvps.org><29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com><4688AEE6.7000200@mvps.org> <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> Message-ID: <6C1791BC61725F44A28C24208026A511126B67@karta-exc-int.Karta.com> Arthur, I too am getting to the stage in life where change is more trouble than it's worth. However, I have had several cases where if I renamed the control by appending the name the errors and problems have disappeared. Most significant in using the domain functions. Jim jhewson at karta.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 02, 2007 5:05 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. Arthur On 7/2/07, Steve Schapel wrote: > > Hmmm. Well, in that case, probably not. If the control and the field > are both named the same as each other, then you can't get it wrong! :-) > > Regards > Steve > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bheygood at abestsystems.com Mon Jul 2 08:29:29 2007 From: bheygood at abestsystems.com (Bob Heygood) Date: Mon, 2 Jul 2007 06:29:29 -0700 Subject: [AccessD] Open Protected Excel via VBA In-Reply-To: References: Message-ID: <002301c7bcad$0471cf00$6401a8c0@speedy> Good Morning to the list, Could someone provide me with a least a jump start on some code to open some sheets in excel that have been protected with a password? I have the password. Best, Bob Heygood From Jim.Hale at FleetPride.com Mon Jul 2 08:43:24 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Mon, 2 Jul 2007 08:43:24 -0500 Subject: [AccessD] Open Protected Excel via VBA In-Reply-To: <002301c7bcad$0471cf00$6401a8c0@speedy> References: <002301c7bcad$0471cf00$6401a8c0@speedy> Message-ID: I think this may be the syntax you are looking for. appExcel.Sheets("instruc").Unprotect Password:=strPW HTH Jim hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bob Heygood Sent: Monday, July 02, 2007 8:29 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Open Protected Excel via VBA Good Morning to the list, Could someone provide me with a least a jump start on some code to open some sheets in excel that have been protected with a password? I have the password. Best, Bob Heygood -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From Jim.Hale at FleetPride.com Mon Jul 2 09:02:20 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Mon, 2 Jul 2007 09:02:20 -0500 Subject: [AccessD] Open Protected Excel via VBA In-Reply-To: References: <002301c7bcad$0471cf00$6401a8c0@speedy> Message-ID: If you meant protected sheets within a workbook, appExcel.Sheets("instruc").Unprotect Password:=strPW Works. If you meant to unprotect a Workbook try the following code snippets: appexcel.Workbooks.Open strPath1 & "\" & strFilename, 0 appexcel.ActiveWorkbook.Unprotect Password:=strPW Jim Hale *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From markamatte at hotmail.com Mon Jul 2 10:50:41 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Mon, 02 Jul 2007 15:50:41 +0000 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) In-Reply-To: <29f585dd0707011007s2bb4f993s9e9b8638acf37813@mail.gmail.com> Message-ID: Joe, I have a db that allows multiple people can add notes. No One can edit old notes. Each note has a DT stamp,User_ID, and note type. The notes are added via an unbound box. If I wanted to impliment what you described...I would probably add a field to my notes table...and along with DTS and USER...I would add a User_Type to the notes. Dispatchers =D Field supervisor =F manager =M executive notes=E Each time a note is created the User_Type would be populated with one of the above depending on the users level of access. One the form/subform displaying the notes...I would change the data source via VBA(depending on user), the 'where' clause specifically. If a dispatcher is logged in..."where User_Type ='D'"...since Dispatchers cannot add notes...none would be returned. See below: EXAMPLE WHERE CLAUSES Dispatchers =where User_Type ='D' Field supervisor =where User_Type ='D' or User_Type ='F' manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' or User_Type='E' Just a thought... Good Luck, Mark A. Matte >From: "Arthur Fuller" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Never Take a job for a friend (Three level >designquestion) >Date: Sun, 1 Jul 2007 13:07:49 -0400 > >Minor addendum, perhaps obvious. If a dispatcher is looking, hide the >Notes, >period. > >Arthur > > >On 7/1/07, Arthur Fuller wrote: > > > > I think that some of the respondents so far kind of missed your > > requirements, Joe (or perhaps the beer I'm enjoying for Canada has had >more > > effect than I anticipated). > > > > You actually have only 3 meaningful user levels, since dispatchers are > > powerless. The other three make a grid like this: > > > > Sup Mgr Exec > > Sup W X X > > Mgr R W X > > Exec R R W > > > > Where R means Read, W means Write, and X means neither. If the user >table > > contained a 3-char column with each horizontal combination written as a > > string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine the > > current row's notes field and act accordingly. > > > > This demands of course that the Notes rows be tagged with UserLevel >column > > (S, M or E). > > > > If a Sup is looking and the current Notes.UserLevel column contains M or > > E, hide the Notes. > > If a Mgr is looking and the current Notes UserLevel contains S, then > > Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. > > If an Exec is looking, and the current Notes UserLevl contains S or M, > > Notes.enabled = False, else Notes.Enabled = True. > > > > I think that covers it. > > > > hth, > > Arthur > > > > > > This problem will be much easier to deal with if the notes are presented > > in single-form fashion rather than datasheet. That said, > > > > > > On 6/30/07, Joe Hecht wrote: > > > > > > It is simple. Ya Right > > > > > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > > Dispatchers can not do notes, can not see notes. Field supervisor can > > > write > > > notes. Can not see manager or executive notes. Managers can write > > > notes, > > > can read Field supervisor notes, not edit them or see executive notes. > > > Executives can write theirs, see but not edit all other notes. > > > > > > > > > > > > Notes are many notes to one employee. > > > > > > > > > > > > How do I do notes so people see them in chronological order? If I do > > > three > > > sub tables how would I get all notes to same point. One employee can > > > have > > > multiple incidents good and bad in their record. How would I get all > > > three > > > levels of notes to same incident? > > > > > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > > > > > > > > > Joe Hecht > > > > > > jmhecht at earthlink.net > > > > > > > > > > > > -- > > > 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 _________________________________________________________________ Don?t miss your chance to WIN $10,000 and other great prizes from Microsoft Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ From cfoust at infostatsystems.com Mon Jul 2 12:03:46 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 2 Jul 2007 10:03:46 -0700 Subject: [AccessD] Never Take a job for a friend (Three leveldesignquestion) In-Reply-To: References: <29f585dd0707011007s2bb4f993s9e9b8638acf37813@mail.gmail.com> Message-ID: Is there some reason NOT to use Access security for this? It still works in 2003 format. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Monday, July 02, 2007 8:51 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Joe, I have a db that allows multiple people can add notes. No One can edit old notes. Each note has a DT stamp,User_ID, and note type. The notes are added via an unbound box. If I wanted to impliment what you described...I would probably add a field to my notes table...and along with DTS and USER...I would add a User_Type to the notes. Dispatchers =D Field supervisor =F manager =M executive notes=E Each time a note is created the User_Type would be populated with one of the above depending on the users level of access. One the form/subform displaying the notes...I would change the data source via VBA(depending on user), the 'where' clause specifically. If a dispatcher is logged in..."where User_Type ='D'"...since Dispatchers cannot add notes...none would be returned. See below: EXAMPLE WHERE CLAUSES Dispatchers =where User_Type ='D' Field supervisor =where User_Type ='D' or User_Type ='F' manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' or User_Type='E' Just a thought... Good Luck, Mark A. Matte >From: "Arthur Fuller" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Never Take a job for a friend (Three level >designquestion) >Date: Sun, 1 Jul 2007 13:07:49 -0400 > >Minor addendum, perhaps obvious. If a dispatcher is looking, hide the >Notes, period. > >Arthur > > >On 7/1/07, Arthur Fuller wrote: > > > > I think that some of the respondents so far kind of missed your > > requirements, Joe (or perhaps the beer I'm enjoying for Canada has > > had >more > > effect than I anticipated). > > > > You actually have only 3 meaningful user levels, since dispatchers > > are powerless. The other three make a grid like this: > > > > Sup Mgr Exec > > Sup W X X > > Mgr R W X > > Exec R R W > > > > Where R means Read, W means Write, and X means neither. If the user >table > > contained a 3-char column with each horizontal combination written > > as a string (i.e. WXX, RWX and RRW) then the OnCurrent event can > > examine the current row's notes field and act accordingly. > > > > This demands of course that the Notes rows be tagged with UserLevel >column > > (S, M or E). > > > > If a Sup is looking and the current Notes.UserLevel column contains > > M or E, hide the Notes. > > If a Mgr is looking and the current Notes UserLevel contains S, then > > Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. > > If an Exec is looking, and the current Notes UserLevl contains S or > > M, Notes.enabled = False, else Notes.Enabled = True. > > > > I think that covers it. > > > > hth, > > Arthur > > > > > > This problem will be much easier to deal with if the notes are > > presented in single-form fashion rather than datasheet. That said, > > > > > > On 6/30/07, Joe Hecht wrote: > > > > > > It is simple. Ya Right > > > > > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > > Dispatchers can not do notes, can not see notes. Field supervisor > > > can write notes. Can not see manager or executive notes. Managers > > > can write notes, can read Field supervisor notes, not edit them or > > > see executive notes. > > > Executives can write theirs, see but not edit all other notes. > > > > > > > > > > > > Notes are many notes to one employee. > > > > > > > > > > > > How do I do notes so people see them in chronological order? If I > > > do three sub tables how would I get all notes to same point. One > > > employee can have multiple incidents good and bad in their record. > > > How would I get all three levels of notes to same incident? > > > > > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > > > > > > > > > Joe Hecht > > > > > > jmhecht at earthlink.net > > > > > > > > > > > > -- > > > 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 _________________________________________________________________ Don't miss your chance to WIN $10,000 and other great prizes from Microsoft Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ From adtejpal at gmail.com Mon Jul 2 12:58:38 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Mon, 2 Jul 2007 23:28:38 +0530 Subject: [AccessD] Open a combobox on entering it References: <380-2200770114955828@M2W008.mail2web.com><29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com><4688103C.7040209@mvps.org><29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com><46887718.30704@mvps.org><29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com><4688AEE6.7000200@mvps.org> <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> Message-ID: <00e801c7bcd2$f6b4da30$7757a27a@pcadt> Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Arthur Fuller To: Access Developers discussion and problem solving Sent: Monday, July 02, 2007 15:34 Subject: Re: [AccessD] Open a combobox on entering it I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. Arthur From cfoust at infostatsystems.com Mon Jul 2 13:06:43 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 2 Jul 2007 11:06:43 -0700 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <00e801c7bcd2$f6b4da30$7757a27a@pcadt> References: <380-2200770114955828@M2W008.mail2web.com><29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com><4688103C.7040209@mvps.org><29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com><46887718.30704@mvps.org><29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com><4688AEE6.7000200@mvps.org><29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> <00e801c7bcd2$f6b4da30$7757a27a@pcadt> Message-ID: I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Arthur Fuller To: Access Developers discussion and problem solving Sent: Monday, July 02, 2007 15:34 Subject: Re: [AccessD] Open a combobox on entering it I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Mon Jul 2 13:58:58 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Mon, 02 Jul 2007 11:58:58 -0700 Subject: [AccessD] Open a combobox on entering it In-Reply-To: Message-ID: <0JKK0069ZF6PEP20@l-daemon> Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 02, 2007 11:07 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Arthur Fuller To: Access Developers discussion and problem solving Sent: Monday, July 02, 2007 15:34 Subject: Re: [AccessD] Open a combobox on entering it I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. 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 miscellany at mvps.org Mon Jul 2 14:15:33 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 03 Jul 2007 07:15:33 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <00e801c7bcd2$f6b4da30$7757a27a@pcadt> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> <46887718.30704@mvps.org> <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> <4688AEE6.7000200@mvps.org> <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> <00e801c7bcd2$f6b4da30$7757a27a@pcadt> Message-ID: <46894ED5.3080903@mvps.org> I agree 100% with your assertions here, A.D. For myself, I *always* adopt the naming convention of using the same name for a bound control as the name of the field it is bound to. And of course, I always ensure that an unbound or calculated control is *not* named the same as a field in the object's record source. I know of no reason why this practice could cause a problem. Regards Steve A.D.TEJPAL wrote: > Naming of Bound Controls On Forms / Reports > (Visa Vis Record Source) > ================================== > > Arthur, > > You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. > > There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: > > ==================================== > 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. > 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. > ==================================== > > If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. > > What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. > > On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. > > Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. > From adtejpal at gmail.com Mon Jul 2 13:30:12 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Tue, 3 Jul 2007 00:00:12 +0530 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> Message-ID: <001101c7bcdf$1eb25100$b057a27a@pcadt> Joe, It might be desirable to enforce ChainOfCommand discipline as well. For example One chief executive can have more than one managers. Each of these managers has more than one supervisors. Each supervisor in turn has more than one employees under his control. Manager A can see all the notes recorded by supervisors for employees under his command only. Similarly only those in the chain of command for a particular employee can record notes for that employee. For this, recursive joins would be necessary. Would you like a solution to be explored on these lines ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Sunday, July 01, 2007 04:38 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net From jmhecht at earthlink.net Mon Jul 2 14:56:53 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Mon, 2 Jul 2007 12:56:53 -0700 (GMT-07:00) Subject: [AccessD] Never Take a job for a friend (Three level designquestion) Message-ID: <18346248.1183406213937.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> AD, Thanks. It is a small company and each level can deal with any one below them. If you have time I can use help writing the notes code. I can send you the DB when I get home tonight. Los Angeles time. -----Original Message----- >From: "A.D.TEJPAL" >Sent: Jul 2, 2007 11:30 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Never Take a job for a friend (Three level designquestion) > >Joe, > > It might be desirable to enforce ChainOfCommand discipline as well. For example One chief executive can have more than one managers. Each of these managers has more than one supervisors. Each supervisor in turn has more than one employees under his control. > > Manager A can see all the notes recorded by supervisors for employees under his command only. Similarly only those in the chain of command for a particular employee can record notes for that employee. > > For this, recursive joins would be necessary. Would you like a solution to be explored on these lines ? > >Best wishes, >A.D.Tejpal >--------------- > > ----- Original Message ----- > From: Joe Hecht > To: 'Access Developers discussion and problem solving' > Sent: Sunday, July 01, 2007 04:38 > Subject: [AccessD] Never Take a job for a friend (Three level designquestion) > > > It is simple. Ya Right > > I am righting a poor mans HR program. There are four user levels. > > Dispatchers can not do notes, can not see notes. > > Field supervisor can write notes. Can not see manager or executive notes. > > Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. > > Executives can write theirs, see but not edit all other notes. > > Notes are many notes to one employee. > > How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? > > Ya all know where I am spending my sat night. > > Joe Hecht > jmhecht at earthlink.net >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From jmhecht at earthlink.net Mon Jul 2 14:59:55 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Mon, 2 Jul 2007 12:59:55 -0700 (GMT-07:00) Subject: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Message-ID: <8414823.1183406395897.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Greetings oh mighty queen of the shy ones. : ) I will see the network instalation and have a better idea after next Monday or Tuesday night. Joe -----Original Message----- >From: Charlotte Foust >Sent: Jul 2, 2007 10:03 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) > >Is there some reason NOT to use Access security for this? It still >works in 2003 format. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Monday, July 02, 2007 8:51 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Never Take a job for a friend (Three >leveldesignquestion) > >Joe, > >I have a db that allows multiple people can add notes. No One can edit >old notes. Each note has a DT stamp,User_ID, and note type. The notes >are added via an unbound box. > >If I wanted to impliment what you described...I would probably add a >field to my notes table...and along with DTS and USER...I would add a >User_Type to the notes. > >Dispatchers =D >Field supervisor =F >manager =M >executive notes=E > >Each time a note is created the User_Type would be populated with one of >the above depending on the users level of access. > >One the form/subform displaying the notes...I would change the data >source via VBA(depending on user), the 'where' clause specifically. If >a dispatcher is logged in..."where User_Type ='D'"...since Dispatchers >cannot add notes...none would be returned. See below: > >EXAMPLE WHERE CLAUSES >Dispatchers =where User_Type ='D' >Field supervisor =where User_Type ='D' or User_Type ='F' >manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' >executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' >or User_Type='E' > >Just a thought... > >Good Luck, > >Mark A. Matte > >>From: "Arthur Fuller" >>Reply-To: Access Developers discussion and problem >>solving >>To: "Access Developers discussion and problem >>solving" >>Subject: Re: [AccessD] Never Take a job for a friend (Three level >>designquestion) >>Date: Sun, 1 Jul 2007 13:07:49 -0400 >> >>Minor addendum, perhaps obvious. If a dispatcher is looking, hide the >>Notes, period. >> >>Arthur >> >> >>On 7/1/07, Arthur Fuller wrote: >> > >> > I think that some of the respondents so far kind of missed your >> > requirements, Joe (or perhaps the beer I'm enjoying for Canada has >> > had >>more >> > effect than I anticipated). >> > >> > You actually have only 3 meaningful user levels, since dispatchers >> > are powerless. The other three make a grid like this: >> > >> > Sup Mgr Exec >> > Sup W X X >> > Mgr R W X >> > Exec R R W >> > >> > Where R means Read, W means Write, and X means neither. If the user >>table >> > contained a 3-char column with each horizontal combination written >> > as a string (i.e. WXX, RWX and RRW) then the OnCurrent event can >> > examine the current row's notes field and act accordingly. >> > >> > This demands of course that the Notes rows be tagged with UserLevel >>column >> > (S, M or E). >> > >> > If a Sup is looking and the current Notes.UserLevel column contains >> > M or E, hide the Notes. >> > If a Mgr is looking and the current Notes UserLevel contains S, then > >> > Notes.enabled = False; if the Notes UserLevel is E, then hide the >Note. >> > If an Exec is looking, and the current Notes UserLevl contains S or >> > M, Notes.enabled = False, else Notes.Enabled = True. >> > >> > I think that covers it. >> > >> > hth, >> > Arthur >> > >> > >> > This problem will be much easier to deal with if the notes are >> > presented in single-form fashion rather than datasheet. That said, >> > >> > >> > On 6/30/07, Joe Hecht wrote: >> > > >> > > It is simple. Ya Right >> > > >> > > >> > > >> > > I am righting a poor mans HR program. There are four user levels. >> > > Dispatchers can not do notes, can not see notes. Field supervisor >> > > can write notes. Can not see manager or executive notes. Managers > >> > > can write notes, can read Field supervisor notes, not edit them or > >> > > see executive notes. >> > > Executives can write theirs, see but not edit all other notes. >> > > >> > > >> > > >> > > Notes are many notes to one employee. >> > > >> > > >> > > >> > > How do I do notes so people see them in chronological order? If I >> > > do three sub tables how would I get all notes to same point. One >> > > employee can have multiple incidents good and bad in their record. > >> > > How would I get all three levels of notes to same incident? >> > > >> > > >> > > >> > > Ya all know where I am spending my sat night. >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > Joe Hecht >> > > >> > > jmhecht at earthlink.net >> > > >> > > >> > > >> > > -- >> > > 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 > >_________________________________________________________________ >Don't miss your chance to WIN $10,000 and other great prizes from >Microsoft Office Live >http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From jmhecht at earthlink.net Mon Jul 2 21:03:07 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Mon, 2 Jul 2007 19:03:07 -0700 Subject: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Looking for AD In-Reply-To: <001101c7bcdf$1eb25100$b057a27a@pcadt> References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> <001101c7bcdf$1eb25100$b057a27a@pcadt> Message-ID: <003701c7bd16$4d18ce70$6701a8c0@ACER2G> Hi AD, It is 7:00 Pacific. Are you on line? Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 11:30 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Joe, It might be desirable to enforce ChainOfCommand discipline as well. For example One chief executive can have more than one managers. Each of these managers has more than one supervisors. Each supervisor in turn has more than one employees under his control. Manager A can see all the notes recorded by supervisors for employees under his command only. Similarly only those in the chain of command for a particular employee can record notes for that employee. For this, recursive joins would be necessary. Would you like a solution to be explored on these lines ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Sunday, July 01, 2007 04:38 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jmhecht at earthlink.net Mon Jul 2 21:09:17 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Mon, 2 Jul 2007 19:09:17 -0700 Subject: [AccessD] Never Take a job for a friend (Three leveldesignquestion) In-Reply-To: References: <29f585dd0707011007s2bb4f993s9e9b8638acf37813@mail.gmail.com> Message-ID: <003d01c7bd17$2c9861f0$6701a8c0@ACER2G> Mark, I may want to steal ( I mean borrow )after I see the network setup next week. Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Monday, July 02, 2007 8:51 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Joe, I have a db that allows multiple people can add notes. No One can edit old notes. Each note has a DT stamp,User_ID, and note type. The notes are added via an unbound box. If I wanted to impliment what you described...I would probably add a field to my notes table...and along with DTS and USER...I would add a User_Type to the notes. Dispatchers =D Field supervisor =F manager =M executive notes=E Each time a note is created the User_Type would be populated with one of the above depending on the users level of access. One the form/subform displaying the notes...I would change the data source via VBA(depending on user), the 'where' clause specifically. If a dispatcher is logged in..."where User_Type ='D'"...since Dispatchers cannot add notes...none would be returned. See below: EXAMPLE WHERE CLAUSES Dispatchers =where User_Type ='D' Field supervisor =where User_Type ='D' or User_Type ='F' manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' or User_Type='E' Just a thought... Good Luck, Mark A. Matte >From: "Arthur Fuller" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Never Take a job for a friend (Three level >designquestion) >Date: Sun, 1 Jul 2007 13:07:49 -0400 > >Minor addendum, perhaps obvious. If a dispatcher is looking, hide the >Notes, >period. > >Arthur > > >On 7/1/07, Arthur Fuller wrote: > > > > I think that some of the respondents so far kind of missed your > > requirements, Joe (or perhaps the beer I'm enjoying for Canada has had >more > > effect than I anticipated). > > > > You actually have only 3 meaningful user levels, since dispatchers are > > powerless. The other three make a grid like this: > > > > Sup Mgr Exec > > Sup W X X > > Mgr R W X > > Exec R R W > > > > Where R means Read, W means Write, and X means neither. If the user >table > > contained a 3-char column with each horizontal combination written as a > > string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine the > > current row's notes field and act accordingly. > > > > This demands of course that the Notes rows be tagged with UserLevel >column > > (S, M or E). > > > > If a Sup is looking and the current Notes.UserLevel column contains M or > > E, hide the Notes. > > If a Mgr is looking and the current Notes UserLevel contains S, then > > Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. > > If an Exec is looking, and the current Notes UserLevl contains S or M, > > Notes.enabled = False, else Notes.Enabled = True. > > > > I think that covers it. > > > > hth, > > Arthur > > > > > > This problem will be much easier to deal with if the notes are presented > > in single-form fashion rather than datasheet. That said, > > > > > > On 6/30/07, Joe Hecht wrote: > > > > > > It is simple. Ya Right > > > > > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > > Dispatchers can not do notes, can not see notes. Field supervisor can > > > write > > > notes. Can not see manager or executive notes. Managers can write > > > notes, > > > can read Field supervisor notes, not edit them or see executive notes. > > > Executives can write theirs, see but not edit all other notes. > > > > > > > > > > > > Notes are many notes to one employee. > > > > > > > > > > > > How do I do notes so people see them in chronological order? If I do > > > three > > > sub tables how would I get all notes to same point. One employee can > > > have > > > multiple incidents good and bad in their record. How would I get all > > > three > > > levels of notes to same incident? > > > > > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > > > > > > > > > Joe Hecht > > > > > > jmhecht at earthlink.net > > > > > > > > > > > > -- > > > 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 _________________________________________________________________ Dont miss your chance to WIN $10,000 and other great prizes from Microsoft Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ From adtejpal at gmail.com Mon Jul 2 22:57:10 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Tue, 3 Jul 2007 09:27:10 +0530 Subject: [AccessD] Never Take a job for a friend (Threeleveldesignquestion) Looking for AD References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G><001101c7bcdf$1eb25100$b057a27a@pcadt> <003701c7bd16$4d18ce70$6701a8c0@ACER2G> Message-ID: <006001c7bd26$52fbf780$f157a27a@pcadt> Yes Joe ! I am now on line (it is 09-15 Hrs Indian Standard Time). I shall try to put together a sample db, meeting all your requirements. However, in order to make it generic and suitable for larger organizations, the additional feature of ChainOfCommand integrity would also be included. Best wishes, A.D.Tejpal adtejpal at gmail.com ------------------------- ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 07:33 Subject: Re: [AccessD] Never Take a job for a friend (Threeleveldesignquestion) Looking for AD Hi AD, It is 7:00 Pacific. Are you on line? Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 11:30 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Joe, It might be desirable to enforce ChainOfCommand discipline as well. For example One chief executive can have more than one managers. Each of these managers has more than one supervisors. Each supervisor in turn has more than one employees under his control. Manager A can see all the notes recorded by supervisors for employees under his command only. Similarly only those in the chain of command for a particular employee can record notes for that employee. For this, recursive joins would be necessary. Would you like a solution to be explored on these lines ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Sunday, July 01, 2007 04:38 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net From adtejpal at gmail.com Mon Jul 2 23:46:04 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Tue, 3 Jul 2007 10:16:04 +0530 Subject: [AccessD] Open a combobox on entering it References: <0JKK0069ZF6PEP20@l-daemon> Message-ID: <01d001c7bd2d$46d2b320$f157a27a@pcadt> Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 02, 2007 11:07 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- << SNIPPED >> From accessd at shaw.ca Tue Jul 3 07:08:38 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 03 Jul 2007 05:08:38 -0700 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <01d001c7bd2d$46d2b320$f157a27a@pcadt> Message-ID: <0JKL003TOQUQCO93@l-daemon> Hi A.D. Tejpal: If you would like I could give you a copy of the application before I played around with it. The application was giving the strangest errors. In one example: a combo box would not take the assignment of an initial value but there were no error messages generated... and the issue was not consistent... sometimes it would work fine... but when the combo box name was changed this problem was gone with no other modifications. I have read some warning about this effect, a number of years ago, the article discussed 'Context and Naming-Conventions' but I can not find any reference to the white-paper. Maybe someone else can remember? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 9:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 02, 2007 11:07 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- << SNIPPED >> -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From adtejpal at gmail.com Tue Jul 3 08:56:35 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Tue, 3 Jul 2007 19:26:35 +0530 Subject: [AccessD] Open a combobox on entering it References: <0JKL003TOQUQCO93@l-daemon> Message-ID: <003501c7bd7a$248145a0$1a58a27a@pcadt> Jim, I would be glad to have a look at it. It would be nice if you could kindly send it to me after removing passwords if any. For ready reference, names of forms / reports that have been giving problems, may please be mentioned, along with the typical steps needed to re-create the adverse behavior. I trust the file is in non-2007 format. Best wishes, A.D.Tejpal adtejpal at gmail.com ------------------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 17:38 Subject: Re: [AccessD] Open a combobox on entering it Hi A.D. Tejpal: If you would like I could give you a copy of the application before I played around with it. The application was giving the strangest errors. In one example: a combo box would not take the assignment of an initial value but there were no error messages generated... and the issue was not consistent... sometimes it would work fine... but when the combo box name was changed this problem was gone with no other modifications. I have read some warning about this effect, a number of years ago, the article discussed 'Context and Naming-Conventions' but I can not find any reference to the white-paper. Maybe someone else can remember? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 9:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 02, 2007 11:07 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- << SNIPPED >> From markamatte at hotmail.com Tue Jul 3 09:28:04 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 03 Jul 2007 14:28:04 +0000 Subject: [AccessD] Never Take a job for a friend (Threeleveldesignquestion) In-Reply-To: <003d01c7bd17$2c9861f0$6701a8c0@ACER2G> Message-ID: No Prob...Just let me know. >From: "Joe Hecht" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Never Take a job for a friend >(Threeleveldesignquestion) >Date: Mon, 2 Jul 2007 19:09:17 -0700 > >Mark, > >I may want to steal ( I mean borrow )after I see the network setup next >week. > >Joe Hecht >jmhecht at earthlink.net > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Monday, July 02, 2007 8:51 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Never Take a job for a friend (Three >leveldesignquestion) > >Joe, > >I have a db that allows multiple people can add notes. No One can edit old >notes. Each note has a DT stamp,User_ID, and note type. The notes are >added via an unbound box. > >If I wanted to impliment what you described...I would probably add a field >to my notes table...and along with DTS and USER...I would add a User_Type >to > >the notes. > >Dispatchers =D >Field supervisor =F >manager =M >executive notes=E > >Each time a note is created the User_Type would be populated with one of >the > >above depending on the users level of access. > >One the form/subform displaying the notes...I would change the data source >via VBA(depending on user), the 'where' clause specifically. If a >dispatcher is logged in..."where User_Type ='D'"...since Dispatchers cannot >add notes...none would be returned. See below: > >EXAMPLE WHERE CLAUSES >Dispatchers =where User_Type ='D' >Field supervisor =where User_Type ='D' or User_Type ='F' >manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' >executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' or >User_Type='E' > >Just a thought... > >Good Luck, > >Mark A. Matte > > >From: "Arthur Fuller" > >Reply-To: Access Developers discussion and problem > >solving > >To: "Access Developers discussion and problem > >solving" > >Subject: Re: [AccessD] Never Take a job for a friend (Three level > >designquestion) > >Date: Sun, 1 Jul 2007 13:07:49 -0400 > > > >Minor addendum, perhaps obvious. If a dispatcher is looking, hide the > >Notes, > >period. > > > >Arthur > > > > > >On 7/1/07, Arthur Fuller wrote: > > > > > > I think that some of the respondents so far kind of missed your > > > requirements, Joe (or perhaps the beer I'm enjoying for Canada has had > >more > > > effect than I anticipated). > > > > > > You actually have only 3 meaningful user levels, since dispatchers are > > > powerless. The other three make a grid like this: > > > > > > Sup Mgr Exec > > > Sup W X X > > > Mgr R W X > > > Exec R R W > > > > > > Where R means Read, W means Write, and X means neither. If the user > >table > > > contained a 3-char column with each horizontal combination written as >a > > > string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine >the > > > current row's notes field and act accordingly. > > > > > > This demands of course that the Notes rows be tagged with UserLevel > >column > > > (S, M or E). > > > > > > If a Sup is looking and the current Notes.UserLevel column contains M >or > > > E, hide the Notes. > > > If a Mgr is looking and the current Notes UserLevel contains S, then > > > Notes.enabled = False; if the Notes UserLevel is E, then hide the >Note. > > > If an Exec is looking, and the current Notes UserLevl contains S or M, > > > Notes.enabled = False, else Notes.Enabled = True. > > > > > > I think that covers it. > > > > > > hth, > > > Arthur > > > > > > > > > This problem will be much easier to deal with if the notes are >presented > > > in single-form fashion rather than datasheet. That said, > > > > > > > > > On 6/30/07, Joe Hecht wrote: > > > > > > > > It is simple. Ya Right > > > > > > > > > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > > > Dispatchers can not do notes, can not see notes. Field supervisor >can > > > > write > > > > notes. Can not see manager or executive notes. Managers can write > > > > notes, > > > > can read Field supervisor notes, not edit them or see executive >notes. > > > > Executives can write theirs, see but not edit all other notes. > > > > > > > > > > > > > > > > Notes are many notes to one employee. > > > > > > > > > > > > > > > > How do I do notes so people see them in chronological order? If I do > > > > three > > > > sub tables how would I get all notes to same point. One employee can > > > > have > > > > multiple incidents good and bad in their record. How would I get all > > > > three > > > > levels of notes to same incident? > > > > > > > > > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Joe Hecht > > > > > > > > jmhecht at earthlink.net > > > > > > > > > > > > > > > > -- > > > > 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 > >_________________________________________________________________ >Dont miss your chance to WIN $10,000 and other great prizes from Microsoft >Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://liveearth.msn.com From robert at webedb.com Tue Jul 3 09:38:28 2007 From: robert at webedb.com (Robert L. Stewart) Date: Tue, 03 Jul 2007 09:38:28 -0500 Subject: [AccessD] Never Take a job for a friend In-Reply-To: References: Message-ID: <200707031444.l63EiR5I004467@databaseadvisors.com> Since it is for a "friend," I would say absolutely do not use security. Personally, I would not want to get sucked into having to maintain it. Robert At 09:28 AM 7/3/2007, you wrote: >Date: Mon, 2 Jul 2007 10:03:46 -0700 >From: "Charlotte Foust" >Subject: Re: [AccessD] Never Take a job for a friend (Three > leveldesignquestion) >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >Is there some reason NOT to use Access security for this? It still >works in 2003 format. > >Charlotte Foust From cfoust at infostatsystems.com Tue Jul 3 10:20:17 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 3 Jul 2007 08:20:17 -0700 Subject: [AccessD] Never Take a job for a friend In-Reply-To: <200707031444.l63EiR5I004467@databaseadvisors.com> References: <200707031444.l63EiR5I004467@databaseadvisors.com> Message-ID: It needn't be that draconian, and security isn't all that hard. How could it be any harder than keeping track of who is supposed to have which permissions entirely through code? It would save a lot of work for Joe if there were simply 3, or however many, user groups with specific permissions. Then a simple login to the application would handle the details. You could even just create logins for each group and not go any further into personal logins. People being what they are, sooner or later someone would find out the other logins and try them "for fun", of course. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Tuesday, July 03, 2007 7:38 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Never Take a job for a friend Since it is for a "friend," I would say absolutely do not use security. Personally, I would not want to get sucked into having to maintain it. Robert At 09:28 AM 7/3/2007, you wrote: >Date: Mon, 2 Jul 2007 10:03:46 -0700 >From: "Charlotte Foust" >Subject: Re: [AccessD] Never Take a job for a friend (Three > leveldesignquestion) >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >Is there some reason NOT to use Access security for this? It still >works in 2003 format. > >Charlotte Foust -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Tue Jul 3 11:20:54 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 03 Jul 2007 16:20:54 +0000 Subject: [AccessD] Never Take a job for a friend In-Reply-To: Message-ID: Lately I've been using API calls to get the username they are logged on to the computer with...then have a table listing potential users and their level of access. Just remember to leave someone access to update this table. Mark >From: "Charlotte Foust" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Never Take a job for a friend >Date: Tue, 3 Jul 2007 08:20:17 -0700 > >It needn't be that draconian, and security isn't all that hard. How >could it be any harder than keeping track of who is supposed to have >which permissions entirely through code? > >It would save a lot of work for Joe if there were simply 3, or however >many, user groups with specific permissions. Then a simple login to the >application would handle the details. You could even just create logins >for each group and not go any further into personal logins. People >being what they are, sooner or later someone would find out the other >logins and try them "for fun", of course. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. >Stewart >Sent: Tuesday, July 03, 2007 7:38 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Never Take a job for a friend > >Since it is for a "friend," I would say >absolutely do not use security. Personally, I would not want to get >sucked into having to maintain it. > >Robert > >At 09:28 AM 7/3/2007, you wrote: > >Date: Mon, 2 Jul 2007 10:03:46 -0700 > >From: "Charlotte Foust" > >Subject: Re: [AccessD] Never Take a job for a friend (Three > > leveldesignquestion) > >To: "Access Developers discussion and problem solving" > > > >Message-ID: > > > > >Content-Type: text/plain; charset="us-ascii" > > > >Is there some reason NOT to use Access security for this? It still > >works in 2003 format. > > > >Charlotte Foust > > >-- >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 _________________________________________________________________ http://newlivehotmail.com From fuller.artful at gmail.com Tue Jul 3 11:21:46 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 3 Jul 2007 12:21:46 -0400 Subject: [AccessD] Forgotten Syntax Message-ID: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> I want to assign a value to a form that is guaranteed to be open. Scenario: OnEnter of a field on form A pops up a dialog that asks for a couple of values. Then I want to post the result to the field on form A and close the popup. Something like: Forms("A").form.B.ResultPlace = Me.Result or something. I keep forgetting this syntax. This time I'll tatoo it. A. From miscellany at mvps.org Tue Jul 3 11:34:21 2007 From: miscellany at mvps.org (Steve Schapel) Date: Wed, 04 Jul 2007 04:34:21 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <003501c7bd7a$248145a0$1a58a27a@pcadt> References: <0JKL003TOQUQCO93@l-daemon> <003501c7bd7a$248145a0$1a58a27a@pcadt> Message-ID: <468A7A8D.2080305@mvps.org> A.D., I am interested in this topic, and would therefore appreciate if you can announce your findings after you have worked with Jim's database. Regards Steve A.D.TEJPAL wrote: > Jim, > > I would be glad to have a look at it. It would be nice if you could > kindly send it to me after removing passwords if any. For ready > reference, names of forms / reports that have been giving problems, > may please be mentioned, along with the typical steps needed to > re-create the adverse behavior. From bheygood at abestsystems.com Tue Jul 3 12:01:10 2007 From: bheygood at abestsystems.com (Bob Heygood) Date: Tue, 3 Jul 2007 10:01:10 -0700 Subject: [AccessD] Open Protected Excel via VBA In-Reply-To: References: <002301c7bcad$0471cf00$6401a8c0@speedy> Message-ID: <00b001c7bd93$c17ebfe0$6401a8c0@speedy> Hey Jim, Works Great Thanks so much. Bob Heygood -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim Sent: Monday, July 02, 2007 7:02 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open Protected Excel via VBA If you meant protected sheets within a workbook, appExcel.Sheets("instruc").Unprotect Password:=strPW Works. If you meant to unprotect a Workbook try the following code snippets: appexcel.Workbooks.Open strPath1 & "\" & strFilename, 0 appexcel.ActiveWorkbook.Unprotect Password:=strPW Jim Hale *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Tue Jul 3 12:03:56 2007 From: miscellany at mvps.org (Steve Schapel) Date: Wed, 04 Jul 2007 05:03:56 +1200 Subject: [AccessD] Forgotten Syntax In-Reply-To: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> References: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> Message-ID: <468A817C.8030401@mvps.org> Arthur, What does the "B" refer to in your example? Do you mean you want the result in a control on a subform? If the value form the popup form is going into a control on form A, then... Forms!A!ResultPlace = Me.Result If the value form the popup form is going into a control on subform B on form A, then... Forms!A!B.Form!ResultPlace = Me.Result Regards Steve Arthur Fuller wrote: > I want to assign a value to a form that is guaranteed to be open. Scenario: > OnEnter of a field on form A pops up a dialog that asks for a couple of > values. Then I want to post the result to the field on form A and close the > popup. > > Something like: > > Forms("A").form.B.ResultPlace = Me.Result > > or something. I keep forgetting this syntax. This time I'll tatoo it. > > A. From fuller.artful at gmail.com Tue Jul 3 12:32:05 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 3 Jul 2007 13:32:05 -0400 Subject: [AccessD] Forgotten Syntax In-Reply-To: <468A817C.8030401@mvps.org> References: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> <468A817C.8030401@mvps.org> Message-ID: <29f585dd0707031032x10eba3c0i2bde173efca200b9@mail.gmail.com> I should have been more clear, sorry about that. Call the popup form C, from which I want to execute the code. The target field is on form B, which is a subform of form A. Arthur On 7/3/07, Steve Schapel wrote: > > Arthur, > > What does the "B" refer to in your example? Do you mean you want the > result in a control on a subform? > > If the value form the popup form is going into a control on form A, > then... > Forms!A!ResultPlace = Me.Result > > If the value form the popup form is going into a control on subform B on > form A, then... > Forms!A!B.Form!ResultPlace = Me.Result > > Regards > Steve > From miscellany at mvps.org Tue Jul 3 12:41:23 2007 From: miscellany at mvps.org (Steve Schapel) Date: Wed, 04 Jul 2007 05:41:23 +1200 Subject: [AccessD] Forgotten Syntax In-Reply-To: <29f585dd0707031032x10eba3c0i2bde173efca200b9@mail.gmail.com> References: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> <468A817C.8030401@mvps.org> <29f585dd0707031032x10eba3c0i2bde173efca200b9@mail.gmail.com> Message-ID: <468A8A43.8040509@mvps.org> Ok, Arthur, so I think just as per my earlier reply: Forms!A!B.Form!ResultPlace = Me.Result Regards Steve Arthur Fuller wrote: > I should have been more clear, sorry about that. Call the popup form C, from > which I want to execute the code. The target field is on form B, which is a > subform of form A. From adtejpal at gmail.com Tue Jul 3 23:43:54 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Wed, 4 Jul 2007 10:13:54 +0530 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP References: Message-ID: <007801c7bdf6$36aed360$7c58a27a@pcadt> It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- From darrend at nimble.com.au Wed Jul 4 00:15:46 2007 From: darrend at nimble.com.au (Darren D) Date: Wed, 4 Jul 2007 15:15:46 +1000 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <007801c7bdf6$36aed360$7c58a27a@pcadt> Message-ID: <200707040516.l645G6TE011652@databaseadvisors.com> Brilliant Now all my posts will be sent straight to Marty - directly Well done - Congrats - Darren -----Original Message----- From: A.D.TEJPAL [mailto:adtejpal at gmail.com] Sent: Wednesday, 4 July 2007 2:44 PM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM From john at winhaven.net Wed Jul 4 00:26:25 2007 From: john at winhaven.net (John Bartow) Date: Wed, 4 Jul 2007 00:26:25 -0500 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <007801c7bdf6$36aed360$7c58a27a@pcadt> References: <007801c7bdf6$36aed360$7c58a27a@pcadt> Message-ID: <003201c7bdfb$dea71000$6402a8c0@ScuzzPaq> Congratulations Marty! Very well deserved IMHO. Thank you for all of your contributions to the various Database Advisors lists. Sincerely, John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Tuesday, July 03, 2007 11:44 PM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From darren at activebilling.com.au Wed Jul 4 00:31:39 2007 From: darren at activebilling.com.au (Darren D) Date: Wed, 4 Jul 2007 15:31:39 +1000 Subject: [AccessD] A2003:Merging Many files into one file Message-ID: <200707040532.l645Vx4s016666@databaseadvisors.com> Hi All I have no clue on how to do this I have say.10 txt files that I want to merge into 1 big txt file Any clues? Many thanks in advance Darren No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM From martyconnelly at shaw.ca Wed Jul 4 02:43:53 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Wed, 04 Jul 2007 00:43:53 -0700 Subject: [AccessD] A2003:Merging Many files into one file In-Reply-To: <200707040532.l645Vx4s016666@databaseadvisors.com> References: <200707040532.l645Vx4s016666@databaseadvisors.com> Message-ID: <468B4FB9.8030906@shaw.ca> Use the old dos command with a Shell function or DOS cmd Multifiles with wildcard copy "C:\temp\short*.txt" "c:\:temp\mybigfile.txt" or copy "C:\temp\short1.txt" + C:\temp\short2.txt" "c:\:temp\mybigfile.txt" get the help file for copy or xcopy at cmd prompt C:\>copy /? Copies one or more files to another location. COPY [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B] [+ source [/A | /B] [+ ...]] [destination [/A | /B]] source Specifies the file or files to be copied. /A Indicates an ASCII text file. /B Indicates a binary file. destination Specifies the directory and/or filename for the new file(s). /V Verifies that new files are written correctly. /N Uses short filename, if available, when copying a file with a non-8dot3 name. /Y Suppresses prompting to confirm you want to overwrite an existing destination file. /-Y Causes prompting to confirm you want to overwrite an existing destination file. /Z Copies networked files in restartable mode. The switch /Y may be preset in the COPYCMD environment variable. This may be overridden with /-Y on the command line. Default is to prompt on overwrites unless COPY command is being executed from within a batch script. To append files, specify a single file for destination, but multiple files for source (using wildcards or file1+file2+file3 format). Darren D wrote: >Hi All > > > >I have no clue on how to do this > > > >I have say.10 txt files that I want to merge into 1 big txt file > > > >Any clues? > > > >Many thanks in advance > > > >Darren > > > > -- Marty Connelly Victoria, B.C. Canada From Gustav at cactus.dk Wed Jul 4 04:29:01 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Wed, 04 Jul 2007 11:29:01 +0200 Subject: [AccessD] Manipulate AC95 mdb files without converting Message-ID: Hi Anita Is that really you? I was sure you had left the list. Welcome back! /gustav >>> anitatiedemann at gmail.com 02-07-2007 07:26 >>> Kevin You should be able to simply open the database with any later versions of Access and enter data directly into it. Anita Smith Australia From ssharkins at setel.com Wed Jul 4 13:07:53 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 4 Jul 2007 14:07:53 -0400 Subject: [AccessD] Omission of Me Message-ID: <000001c7be66$3ede82e0$06b62ad1@SusanOne> Does anyone remember what version of Access dropped the need for Me or the Forms.formname identifiers when the form (or report) is current? I think it was XP, but I really don't remember. It seems like it's been around for a really long time, so maybe it was 2000? Susan H. From accma at sympatico.ca Wed Jul 4 18:07:44 2007 From: accma at sympatico.ca (Annie Courchesne, CMA) Date: Wed, 4 Jul 2007 19:07:44 -0400 Subject: [AccessD] Performance tips anyone? Message-ID: <002201c7be90$215364f0$6800a8c0@anniec> Hi all, I have a customer that complains about his database (BE/FE A97 running in runtime mode) is slow. The number of concurrent user keep growing over the years and it's up to 10 or 12 now. What I'm looking at right now is to optimize the whole database and upgrade to Access 2003. I've look at the performance tips from this page (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some pretty usefull information. Anyone has other tips on getting this database more performing? I was also wondering if using a dedicated server for the database would help to improve performance? And what about SQL Server 2005 Express? I've read here that it's free and has a large capacity (more than enough for what I need). Will it really help in speeding up the database? How hard is it to set up? Any good documentation I can read on this? Thanks to all of you! Annie Courchesne, CMA From jwcolby at colbyconsulting.com Wed Jul 4 18:52:18 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 4 Jul 2007 19:52:18 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <20070704235234.7B130BCEC@smtp-auth.no-ip.com> If you are not doing so yet, the biggest single thing that you can do is keep a pointer to a table in the BE open. You can do that by opening a table, query or form based on a table etc. Doesn't matter how you do it but keep a pointer open. What happens is that the first time a table in the BE is used, JET has to acquire locks on the BE which takes longer and longer as more and more users are in the database. Once that first lock is acquired however, the next usage of the BE is much faster. Thus keeping some table open to the BE establishes that first lock and then keeps it open. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Wednesday, July 04, 2007 7:08 PM To: accessd at databaseadvisors.com Subject: [AccessD] Performance tips anyone? Hi all, I have a customer that complains about his database (BE/FE A97 running in runtime mode) is slow. The number of concurrent user keep growing over the years and it's up to 10 or 12 now. What I'm looking at right now is to optimize the whole database and upgrade to Access 2003. I've look at the performance tips from this page (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some pretty usefull information. Anyone has other tips on getting this database more performing? I was also wondering if using a dedicated server for the database would help to improve performance? And what about SQL Server 2005 Express? I've read here that it's free and has a large capacity (more than enough for what I need). Will it really help in speeding up the database? How hard is it to set up? Any good documentation I can read on this? Thanks to all of you! Annie Courchesne, CMA -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From anitatiedemann at gmail.com Wed Jul 4 19:41:42 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 10:41:42 +1000 Subject: [AccessD] Manipulate AC95 mdb files without converting In-Reply-To: References: Message-ID: Hi Gustav, Yes it's me. I never really left the list. I just did not receive posts for a long time. I thought I would get the posts for a while to see whats happening. It appears that the number of posts have dropped off a lot which is good because I don't have time to read that many. I hope you are all well and still working away in Access. I still work with Access but have moved to SQL server for the back end. I still love using Access to develop the front ends simply because I can get a lot done in a short space of time. I find that using SQL server stored procedures is just so efficient, it allows the developer to move a lot of functionality to the database. I was wondering what the general opinions of the latest version of Access are? I installed it, but have not worked with it yet. It appears to have been designed for non developers? Anita Smith Australia On 7/4/07, Gustav Brock wrote: > > Hi Anita > > Is that really you? I was sure you had left the list. > Welcome back! > > /gustav > > >>> anitatiedemann at gmail.com 02-07-2007 07:26 >>> > Kevin > You should be able to simply open the database with any later versions of > Access and enter data directly into it. > Anita Smith > Australia > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From darrend at nimble.com.au Wed Jul 4 19:49:58 2007 From: darrend at nimble.com.au (Darren D) Date: Thu, 5 Jul 2007 10:49:58 +1000 Subject: [AccessD] A2003:Merging Many files into one file In-Reply-To: <468B4FB9.8030906@shaw.ca> Message-ID: <200707050050.l650oTd1005120@databaseadvisors.com> Marty - Brilliant and simple Just what I needed Thanks DD -----Original Message----- From: MartyConnelly [mailto:martyconnelly at shaw.ca] Sent: Wednesday, 4 July 2007 5:44 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] A2003:Merging Many files into one file Use the old dos command with a Shell function or DOS cmd Multifiles with wildcard copy "C:\temp\short*.txt" "c:\:temp\mybigfile.txt" or copy "C:\temp\short1.txt" + C:\temp\short2.txt" "c:\:temp\mybigfile.txt" get the help file for copy or xcopy at cmd prompt C:\>copy /? Copies one or more files to another location. COPY [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B] [+ source [/A | /B] [+ ...]] [destination [/A | /B]] source Specifies the file or files to be copied. /A Indicates an ASCII text file. /B Indicates a binary file. destination Specifies the directory and/or filename for the new file(s). /V Verifies that new files are written correctly. /N Uses short filename, if available, when copying a file with a non-8dot3 name. /Y Suppresses prompting to confirm you want to overwrite an existing destination file. /-Y Causes prompting to confirm you want to overwrite an existing destination file. /Z Copies networked files in restartable mode. The switch /Y may be preset in the COPYCMD environment variable. This may be overridden with /-Y on the command line. Default is to prompt on overwrites unless COPY command is being executed from within a batch script. To append files, specify a single file for destination, but multiple files for source (using wildcards or file1+file2+file3 format). Darren D wrote: >Hi All > > > >I have no clue on how to do this > > > >I have say.10 txt files that I want to merge into 1 big txt file > > > >Any clues? > > > >Many thanks in advance > > > >Darren > > > > -- Marty Connelly Victoria, B.C. Canada -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM From anitatiedemann at gmail.com Wed Jul 4 20:00:17 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 11:00:17 +1000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <002201c7be90$215364f0$6800a8c0@anniec> References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: Annie, There are a number of things you can do to speed up an Access Database. I haven't looked at the link you provided, but here are a few suggestions based on my experience over the years: * Make sure your tables contain indexes on the fields frequently used for criteria in queries * Put the criteria on the ONE side of the relationship in queries * Don't open forms and reports with large underlying recordsources. If possible open the forms with only 1 underlying record - not a whole table. * I have found that opening a form specifying the procedure arguments makes it open faster DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of DoCmd.OpenForm "MyForm" Upgrading to A2003 probably won't make much difference. Using Runtime mode should not make it run any slower either. SQL server Express is a great option, but you would probably have to rewrite the form and report recordsources to really take advantage of it. It is not hard to set up. I think there is an upgrade wizard that will upgrade an Access Database to SQL Server. I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. I hope this helps a bit. Anita On 7/5/07, Annie Courchesne, CMA wrote: > > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over > the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and > upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would > help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From developer at ultradnt.com Wed Jul 4 23:04:13 2007 From: developer at ultradnt.com (Steve Conklin) Date: Thu, 5 Jul 2007 00:04:13 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> Replace any DoCmd.RunSQL's with CurrentDB.execute. Steve -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Wednesday, July 04, 2007 9:00 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Annie, There are a number of things you can do to speed up an Access Database. I haven't looked at the link you provided, but here are a few suggestions based on my experience over the years: * Make sure your tables contain indexes on the fields frequently used for criteria in queries * Put the criteria on the ONE side of the relationship in queries * Don't open forms and reports with large underlying recordsources. If possible open the forms with only 1 underlying record - not a whole table. * I have found that opening a form specifying the procedure arguments makes it open faster DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of DoCmd.OpenForm "MyForm" Upgrading to A2003 probably won't make much difference. Using Runtime mode should not make it run any slower either. SQL server Express is a great option, but you would probably have to rewrite the form and report recordsources to really take advantage of it. It is not hard to set up. I think there is an upgrade wizard that will upgrade an Access Database to SQL Server. I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. I hope this helps a bit. Anita On 7/5/07, Annie Courchesne, CMA wrote: > > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running > in runtime mode) is slow. The number of concurrent user keep growing > over the years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and > upgrade to Access 2003. I've look at the performance tips from this > page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > some pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database > would help to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free > and has a large capacity (more than enough for what I need). Will it > really help in speeding up the database? How hard is it to set up? > Any good documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > > -- > 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 jwcolby at colbyconsulting.com Wed Jul 4 23:29:03 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 00:29:03 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Anita, >I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). And of course all of the things you mentioned in terms of FE optimizations. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Wednesday, July 04, 2007 9:00 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Annie, There are a number of things you can do to speed up an Access Database. I haven't looked at the link you provided, but here are a few suggestions based on my experience over the years: * Make sure your tables contain indexes on the fields frequently used for criteria in queries * Put the criteria on the ONE side of the relationship in queries * Don't open forms and reports with large underlying recordsources. If possible open the forms with only 1 underlying record - not a whole table. * I have found that opening a form specifying the procedure arguments makes it open faster DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of DoCmd.OpenForm "MyForm" Upgrading to A2003 probably won't make much difference. Using Runtime mode should not make it run any slower either. SQL server Express is a great option, but you would probably have to rewrite the form and report recordsources to really take advantage of it. It is not hard to set up. I think there is an upgrade wizard that will upgrade an Access Database to SQL Server. I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. I hope this helps a bit. Anita From miscellany at mvps.org Wed Jul 4 23:54:24 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 16:54:24 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> References: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Message-ID: <468C7980.9070407@mvps.org> I agree, John. Access should handle more than 10-12 users under most circumstances, and generally many more than that. It is very difficult to make comparisons in terms of "number of users", as this will vary enormously depending on the nature of the application, and the way in which the users are hitting the database. Regards Steve jwcolby wrote: > Anita, > >> I think that 10-12 users is the absolute maximum you will get out of an > Access database it will continue to get slower over the years as the > database grows. At some stage you would probably have to upgrade to SQL > server. > > Errrrr! Wrong answer. > > I have a database with 25 users in the database every day. The BE is > currently about 800 mbytes. This BE has tables with hundreds of thousands > of records in some tables, 30K-50K records in the main tables (claimant / > claim). I open a VERY complex tabbed form with about 20 tabs on it, with > subforms on each tab (JIT subforms). > > Users on fast machines open the form in about 1.2 seconds. Users on very > old slow machines take about 5 to 6 seconds. > > Speed of the individual workstation is the single largest determinate of > acceptable speed. A high speed processor and LOTS of memory (1 gig for > Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference > as well (which requires a gigabit NIC in the machines as well). > > And of course all of the things you mentioned in terms of FE optimizations. > From miscellany at mvps.org Wed Jul 4 23:56:17 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 16:56:17 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <468C79F1.3060408@mvps.org> Anita Smith wrote: > * I have found that opening a form specifying the procedure arguments makes > it open faster > DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of > DoCmd.OpenForm "MyForm" That's very interesting, Anita, I hadn't heard about this. Thanks. Is this a subjective impression, or did you do some speed measurement testing? Regards Steve From anitatiedemann at gmail.com Wed Jul 4 23:56:49 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 14:56:49 +1000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> References: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Message-ID: John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita From miscellany at mvps.org Wed Jul 4 23:59:28 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 16:59:28 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: <000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> References: <002201c7be90$215364f0$6800a8c0@anniec> <000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> Message-ID: <468C7AB0.8090900@mvps.org> Sorry to be contrary, Steve, but I don't think this is supported by the evidence. In fact, I believe DoCmd.OpenQuery would perform faster if you are running a saved query, as long as the number of records hasn't changed dramatically since the last time it was run. But either way, I think this is possibly academic interest only, as the speed differences here are likely to be imperceptible. Regards Steve Steve Conklin wrote: > Replace any DoCmd.RunSQL's with CurrentDB.execute. > From anitatiedemann at gmail.com Thu Jul 5 00:01:34 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 15:01:34 +1000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <468C79F1.3060408@mvps.org> References: <002201c7be90$215364f0$6800a8c0@anniec> <468C79F1.3060408@mvps.org> Message-ID: Steve, One day while testing a form I found it was slow to open (I like my forms to open instantly). When I added the arguments it magically speeded up. I am at a loss as to why? Anita On 7/5/07, Steve Schapel wrote: > > Anita Smith wrote: > > * I have found that opening a form specifying the procedure arguments > makes > > it open faster > > DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of > > DoCmd.OpenForm "MyForm" > > That's very interesting, Anita, I hadn't heard about this. Thanks. Is > this a subjective impression, or did you do some speed measurement > testing? > > Regards > Steve > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From miscellany at mvps.org Thu Jul 5 00:09:37 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 17:09:37 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: <002201c7be90$215364f0$6800a8c0@anniec> References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <468C7D11.9050201@mvps.org> Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > From adtejpal at gmail.com Thu Jul 5 00:11:03 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Thu, 5 Jul 2007 10:41:03 +0530 Subject: [AccessD] Naming of controls - [Was: Open a combobox on entering it] References: <0JKL003TOQUQCO93@l-daemon> Message-ID: <008c01c7bec3$561511b0$4e57a27a@pcadt> Jim, Thanks for making the file available for study. My findings are placed in the note appended below. Certain factors as brought out are suspected to have contributed to the inconsistent behavior mentioned in your post. I understand this is a db that was handed over to you. Of course, if it had been your own creation, the aberrations would not have crept in. A gist of the findings: (a) A particular bound control is named as per a field other than its actual control source. Moreover, the name of its source field is a reserved word (Name). Combination of these factors makes it a case of multiplied pitfall. (b) Embedded quote in field name. Better avoid. (c) Lookup fields used in tables. Not considered desirable. (d) Subdatasheet property of tables is Auto. It should be set to None. (e) In many cases, table column headings are at variance with field names. Better keep the tables simple & straightforward. Instead, the objective can be met through suitable captions on form labels. As mentioned by you, the problem experienced at your end has been surfacing intermittently. In limited tests at my end, no abnormality could be detected. However, it can be expected that if the points brought out above (details in the note below) are attended to and even with names of pure bound controls kept same as their source fields, the db should perform consistently. Simultaneously, it has to be ensured that the names of unbound and calculated controls never coincide with any field name in the record source. Best wishes, A.D.Tejpal --------------- Findings ======================================= 1 - Bound text box named LstnmVol on form frmHoursWorked: (a) Control source for this text box is a field named Name (a reserved word). (b) LstnmVol is itself a field in tblVolunteers, one of the source tables for the query serving as record source for this form. (c) Combination of (a) & (b) above, is bound to invite trouble as it becomes a case of contaminated bound control, named after an existing field in one of the source tables, even though that particular field is not its control source. Moreover, the control source actually used (Name) happens to be a reserved word. (d) It appears that to start with, this control was bound to field LstnmVol and was correctly named accordingly. Later when calculated field Name was used as the control source, re-naming of the control accordingly (to match the name of new control source) seems to have been overlooked. (e) Suggested step - Modify the name of calculated field in record source from Name to VName. Control source as well as name of this text box would then become VName. 2 - Control named DtEnt'dHW on form frmHoursWorked: (a) There is an embedded quote in the name of control as well as source field. (b) Suggested step - Eliminate embedded quote in field as well as control name. 3 - Data Tables: (a) In many cases, column headings are different from field names. It is considered desirable to keep the tables as simple & straightforward as possible. The process of depicting the fields under more convenient names should better be handled at form level, through suitable captions for labels. (b) Subdatasheet property of all tables should be set to None. (At present it is Auto). (c) Two fields in table tblHourWorked are found to be lookup type. This is considered a violation of ten commandments. Note: (a) SQL serving as record source for form frmHoursWorked involves inner join on EventNum between tables tblHourWorked and tblEvents. At present, this field is blank in tblHourWorked, leading to no record getting displayed. For testing, tblEvents was removed from the query, temporarily. Retaining this table & displaying the records by converting to Left join would have rendered the recordset non-updateable. (b) Compile error in form lstEditHrsWkd on account of missing End If in two subroutines. This was rectified. ======================================= ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 17:38 Subject: Re: [AccessD] Open a combobox on entering it Hi A.D. Tejpal: If you would like I could give you a copy of the application before I played around with it. The application was giving the strangest errors. In one example: a combo box would not take the assignment of an initial value but there were no error messages generated... and the issue was not consistent... sometimes it would work fine... but when the combo box name was changed this problem was gone with no other modifications. I have read some warning about this effect, a number of years ago, the article discussed 'Context and Naming-Conventions' but I can not find any reference to the white-paper. Maybe someone else can remember? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 9:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim From miscellany at mvps.org Thu Jul 5 00:28:49 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 17:28:49 +1200 Subject: [AccessD] Naming of controls - [Was: Open a combobox on entering it] In-Reply-To: <008c01c7bec3$561511b0$4e57a27a@pcadt> References: <0JKL003TOQUQCO93@l-daemon> <008c01c7bec3$561511b0$4e57a27a@pcadt> Message-ID: <468C8191.9050107@mvps.org> A.D., I so enjoyed your use of the terminology "a case of multiplied pitfall". :-) I was very interested to see your discussion, so thanks for doing it. In particular, I would certainly expect a control named the same as the name of *another* field in the form's record source, to eventually cause a hiccup. Regards Steve A.D.TEJPAL wrote: > Jim, > > Thanks for making the file available for study. My findings are placed in the note appended below. Certain factors as brought out are suspected to have contributed to the inconsistent behavior mentioned in your post. I understand this is a db that was handed over to you. Of course, if it had been your own creation, the aberrations would not have crept in. > > A gist of the findings: > (a) A particular bound control is named as per a field other than its actual control source. Moreover, the name of its source field is a reserved word (Name). Combination of these factors makes it a case of multiplied pitfall. > (b) Embedded quote in field name. Better avoid. > (c) Lookup fields used in tables. Not considered desirable. > (d) Subdatasheet property of tables is Auto. It should be set to None. > (e) In many cases, table column headings are at variance with field names. Better keep the tables simple & straightforward. Instead, the objective can be met through suitable captions on form labels. > > As mentioned by you, the problem experienced at your end has been surfacing intermittently. In limited tests at my end, no abnormality could be detected. > > However, it can be expected that if the points brought out above (details in the note below) are attended to and even with names of pure bound controls kept same as their source fields, the db should perform consistently. Simultaneously, it has to be ensured that the names of unbound and calculated controls never coincide with any field name in the record source. From jwcolby at colbyconsulting.com Thu Jul 5 00:42:34 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 01:42:34 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705054251.62982BD59@smtp-auth.no-ip.com> Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 00:45:53 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 01:45:53 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <468C7D11.9050201@mvps.org> Message-ID: <20070705054610.9B201BDAC@smtp-auth.no-ip.com> >And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Thursday, July 05, 2007 1:10 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running > in runtime mode) is slow. The number of concurrent user keep growing > over the years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and > upgrade to Access 2003. I've look at the performance tips from this > page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > some pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database > would help to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free > and has a large capacity (more than enough for what I need). Will it > really help in speeding up the database? How hard is it to set up? > Any good documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From anitatiedemann at gmail.com Thu Jul 5 01:17:04 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 16:17:04 +1000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705054610.9B201BDAC@smtp-auth.no-ip.com> References: <468C7D11.9050201@mvps.org> <20070705054610.9B201BDAC@smtp-auth.no-ip.com> Message-ID: Perhaps you could write some code to run through all the queries to run them before redeploying the database. Anita On 7/5/07, jwcolby wrote: > > >And here's another thing I only found out about this week... the first > time > a saved query is run after the database is compacted, will be slow, > because > the query plan has to be re-created. > > Ohhhh that is something to consider, I kinda knew this but never thought > of > it in quite this light. I build and then upload to a server. The users > download the FE every day. Thus the first time they open anything it will > be slow, every day. Sigh. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel > Sent: Thursday, July 05, 2007 1:10 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Performance tips anyone? > > Annie, > > If you have forms with lots of comboboxes, it certainly helps if you don't > populate them unless and until they are needed, i.e. set the Row Source on > their Enter event. > > Similarly, if you have forms with subforms on different pages of a tab > control, leave the Source Object of the subforms blanks, and only set it > if > and when that tab is selected. > > And here's another thing I only found out about this week... the first > time > a saved query is run after the database is compacted, will be slow, > because > the query plan has to be re-created. So if you compact/repair the > front-end > application file, queries will run slow the first time, and forms based on > queries will open slowly the first time. An argument against 'Compact On > Close' - but then, for memory, I don't think Comapct On Close was > available > in Access 97. > > Regards > Steve > > > Annie Courchesne, CMA wrote: > > Hi all, > > > > > > > > I have a customer that complains about his database (BE/FE A97 running > > in runtime mode) is slow. The number of concurrent user keep growing > > over the years and it's up to 10 or 12 now. > > > > > > > > What I'm looking at right now is to optimize the whole database and > > upgrade to Access 2003. I've look at the performance tips from this > > page > > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > > some pretty usefull information. > > > > > > > > Anyone has other tips on getting this database more performing? > > > > > > > > I was also wondering if using a dedicated server for the database > > would help to improve performance? > > > > > > > > And what about SQL Server 2005 Express? I've read here that it's free > > and has a large capacity (more than enough for what I need). Will it > > really help in speeding up the database? How hard is it to set up? > > Any good documentation I can read on this? > > > > > > > > Thanks to all of you! > > > > > > > > > > > > Annie Courchesne, CMA > > > > > > > -- > 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 accessd at shaw.ca Thu Jul 5 01:25:39 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Wed, 04 Jul 2007 23:25:39 -0700 Subject: [AccessD] Naming of controls - [Was: Open a combobox on entering it] In-Reply-To: <008c01c7bec3$561511b0$4e57a27a@pcadt> Message-ID: <0JKP006VV0AWAEU0@l-daemon> Hi A D Tejpal: No problem. That example is definitely one of the worse I have seen for a while. Added to those coding issues is a poor design. Consider that the lady that made the database designed it never having worked in Access or any database before, she is a hair-dresser who was doing a friend a favour, I think she did rather well. Regards Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Wednesday, July 04, 2007 10:11 PM To: Access Developers discussion and problem solving Cc: A. D. TEJPAL Subject: Re: [AccessD] Naming of controls - [Was: Open a combobox on entering it] Jim, Thanks for making the file available for study. My findings are placed in the note appended below. Certain factors as brought out are suspected to have contributed to the inconsistent behavior mentioned in your post. I understand this is a db that was handed over to you. Of course, if it had been your own creation, the aberrations would not have crept in. A gist of the findings: (a) A particular bound control is named as per a field other than its actual control source. Moreover, the name of its source field is a reserved word (Name). Combination of these factors makes it a case of multiplied pitfall. (b) Embedded quote in field name. Better avoid. (c) Lookup fields used in tables. Not considered desirable. (d) Subdatasheet property of tables is Auto. It should be set to None. (e) In many cases, table column headings are at variance with field names. Better keep the tables simple & straightforward. Instead, the objective can be met through suitable captions on form labels. As mentioned by you, the problem experienced at your end has been surfacing intermittently. In limited tests at my end, no abnormality could be detected. However, it can be expected that if the points brought out above (details in the note below) are attended to and even with names of pure bound controls kept same as their source fields, the db should perform consistently. Simultaneously, it has to be ensured that the names of unbound and calculated controls never coincide with any field name in the record source. Best wishes, A.D.Tejpal --------------- Findings ======================================= 1 - Bound text box named LstnmVol on form frmHoursWorked: (a) Control source for this text box is a field named Name (a reserved word). (b) LstnmVol is itself a field in tblVolunteers, one of the source tables for the query serving as record source for this form. (c) Combination of (a) & (b) above, is bound to invite trouble as it becomes a case of contaminated bound control, named after an existing field in one of the source tables, even though that particular field is not its control source. Moreover, the control source actually used (Name) happens to be a reserved word. (d) It appears that to start with, this control was bound to field LstnmVol and was correctly named accordingly. Later when calculated field Name was used as the control source, re-naming of the control accordingly (to match the name of new control source) seems to have been overlooked. (e) Suggested step - Modify the name of calculated field in record source from Name to VName. Control source as well as name of this text box would then become VName. 2 - Control named DtEnt'dHW on form frmHoursWorked: (a) There is an embedded quote in the name of control as well as source field. (b) Suggested step - Eliminate embedded quote in field as well as control name. 3 - Data Tables: (a) In many cases, column headings are different from field names. It is considered desirable to keep the tables as simple & straightforward as possible. The process of depicting the fields under more convenient names should better be handled at form level, through suitable captions for labels. (b) Subdatasheet property of all tables should be set to None. (At present it is Auto). (c) Two fields in table tblHourWorked are found to be lookup type. This is considered a violation of ten commandments. Note: (a) SQL serving as record source for form frmHoursWorked involves inner join on EventNum between tables tblHourWorked and tblEvents. At present, this field is blank in tblHourWorked, leading to no record getting displayed. For testing, tblEvents was removed from the query, temporarily. Retaining this table & displaying the records by converting to Left join would have rendered the recordset non-updateable. (b) Compile error in form lstEditHrsWkd on account of missing End If in two subroutines. This was rectified. ======================================= ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 17:38 Subject: Re: [AccessD] Open a combobox on entering it Hi A.D. Tejpal: If you would like I could give you a copy of the application before I played around with it. The application was giving the strangest errors. In one example: a combo box would not take the assignment of an initial value but there were no error messages generated... and the issue was not consistent... sometimes it would work fine... but when the combo box name was changed this problem was gone with no other modifications. I have read some warning about this effect, a number of years ago, the article discussed 'Context and Naming-Conventions' but I can not find any reference to the white-paper. Maybe someone else can remember? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 9:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Andrew.Curtis at wapl.com.au Thu Jul 5 01:21:36 2007 From: Andrew.Curtis at wapl.com.au (Curtis, Andrew (WAPL)) Date: Thu, 5 Jul 2007 14:21:36 +0800 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705054251.62982BD59@smtp-auth.no-ip.com> References: <20070705054251.62982BD59@smtp-auth.no-ip.com> Message-ID: Anita, you havent said how big your FE is in mb? Also, does every user have a copy of the FE on their own PC, or are they accessing a common FE also from a network? In my experience this has a direct bearing on the load speed. Some other things I have found along the way: A) only select data based on deterministic fields. In other words if you have a table with field1, field2, with field1="job" and field2="2222", don't go building a query that concatenates these fields then open a form based on that query using (select * from queryx where concatfield="job2222"). Any index on field1 and 2 of the table would be ignored if the index were not compound (including both fields). If you find yourself routinely selecting data from tables that don't have exactly what your after (select * from tablex where field1="job" and field2="2222" then you may incur a performance hit. Consider in this case, a third field in tablex called "fullfield" with a value of "job2222", indexed. Then select straight from the table. The fullfield could be filled at data entry. B) FE bloat, usually caused by long running queries, repair and compact of the FE reduces the size in this case. C) fill tabs on forms, only when the tab is selected. This way when the form is opened, only the default tab needs to bet data on opening. If any of this is off base, appologies in advance, but I have just been through a similar exercise with another persons creation with quite staggering results. --Regards Andrew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, 5 July 2007 1:43 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 This message and any attached files may contain information that is confidential and/or subject of legal privilege intended only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete the message. From Andrew.Curtis at wapl.com.au Thu Jul 5 01:31:43 2007 From: Andrew.Curtis at wapl.com.au (Curtis, Andrew (WAPL)) Date: Thu, 5 Jul 2007 14:31:43 +0800 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705054251.62982BD59@smtp-auth.no-ip.com> References: <20070705054251.62982BD59@smtp-auth.no-ip.com> Message-ID: This article may help you out. Performance analyzer http://articles.techrepublic.com.com/5100-1035_11-5034310.html you may need to sign up, its free and worthwhile. --andrew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, 5 July 2007 1:43 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 This message and any attached files may contain information that is confidential and/or subject of legal privilege intended only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete the message. From accma at sympatico.ca Thu Jul 5 05:25:59 2007 From: accma at sympatico.ca (Annie Courchesne, CMA) Date: Thu, 5 Jul 2007 06:25:59 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <000901c7beee$e163b390$6800a8c0@anniec> Hi Anita, Thanks for the tips. About the tip for opening a form with complete argument, would this also apply to openreport? A lot of report are quite slow to open. Thanks! Annie Courchesne, CMA -----Message d'origine----- De?: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Anita Smith Envoy??: 4 juillet 2007 21:00 ??: Access Developers discussion and problem solving Objet?: Re: [AccessD] Performance tips anyone? Annie, There are a number of things you can do to speed up an Access Database. I haven't looked at the link you provided, but here are a few suggestions based on my experience over the years: * Make sure your tables contain indexes on the fields frequently used for criteria in queries * Put the criteria on the ONE side of the relationship in queries * Don't open forms and reports with large underlying recordsources. If possible open the forms with only 1 underlying record - not a whole table. * I have found that opening a form specifying the procedure arguments makes it open faster DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of DoCmd.OpenForm "MyForm" Upgrading to A2003 probably won't make much difference. Using Runtime mode should not make it run any slower either. SQL server Express is a great option, but you would probably have to rewrite the form and report recordsources to really take advantage of it. It is not hard to set up. I think there is an upgrade wizard that will upgrade an Access Database to SQL Server. I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. I hope this helps a bit. Anita On 7/5/07, Annie Courchesne, CMA wrote: > > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over > the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and > upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would > help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > > -- > 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 accma at sympatico.ca Thu Jul 5 05:35:26 2007 From: accma at sympatico.ca (Annie Courchesne, CMA) Date: Thu, 5 Jul 2007 06:35:26 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <468C7D11.9050201@mvps.org> References: <002201c7be90$215364f0$6800a8c0@anniec> <468C7D11.9050201@mvps.org> Message-ID: <000a01c7bef0$330cbdd0$6800a8c0@anniec> Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De?: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy??: 5 juillet 2007 01:10 ??: Access Developers discussion and problem solving Objet?: Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Thu Jul 5 06:02:58 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 05 Jul 2007 13:02:58 +0200 Subject: [AccessD] Performance tips anyone? Message-ID: Hi Annie It sounds like you have the FEs on the server? Try to copy them to a workstation, relink BE tables and test performance. You should observe a great improvement. If so, at start up of a workstation, copy a master of each FE to a local drive and use these. Or (also,) move the temp tables to a separate local database which you recreate at every start up. Write protect the report FE to disable bloat. /gustav >>> accma at sympatico.ca 05-07-2007 12:35 >>> Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De : accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy? : 5 juillet 2007 01:10 ? : Access Developers discussion and problem solving Objet : Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA From ewaldt at gdls.com Thu Jul 5 07:05:11 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 5 Jul 2007 08:05:11 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: John: Could you include code to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From jwcolby at colbyconsulting.com Thu Jul 5 07:13:27 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 08:13:27 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705121344.A2BA7BD5A@smtp-auth.no-ip.com> Yep, I need to do something like this. Often in Access this isn't very feasible since many people use references to controls on forms, which means the form has to be open to cause the query to run. I stopped using that method long ago, preferring to use "filters" (static functions) to pass parameters to queries. So I can probably write code to iterate the querydef collection, grabbing the name of each query and executing it. Even then it could take awhile to execute every query in a FE. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of ewaldt at gdls.com Sent: Thursday, July 05, 2007 8:05 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? John: Could you include code to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ewaldt at gdls.com Thu Jul 5 07:19:59 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 5 Jul 2007 08:19:59 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: John: Could you include code to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From accma at sympatico.ca Thu Jul 5 07:33:23 2007 From: accma at sympatico.ca (Annie Courchesne, CMA) Date: Thu, 5 Jul 2007 08:33:23 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Hi Gustav, The FEs are on the local machine... sorry for not specifying this. The temp tables are on the local machine also, but I never thought to have those table put in a completely seperated db and to recreate them at start up... I'll have to look this up. Thanks! Annie Courchesne, CMA -----Message d'origine----- De : accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part deGustav Brock Envoy? : 5 juillet, 2007 07:03 ? : accessd at databaseadvisors.com Objet : Re: [AccessD] Performance tips anyone? Hi Annie It sounds like you have the FEs on the server? Try to copy them to a workstation, relink BE tables and test performance. You should observe a great improvement. If so, at start up of a workstation, copy a master of each FE to a local drive and use these. Or (also,) move the temp tables to a separate local database which you recreate at every start up. Write protect the report FE to disable bloat. /gustav >>> accma at sympatico.ca 05-07-2007 12:35 >>> Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De : accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy? : 5 juillet 2007 01:10 ? : Access Developers discussion and problem solving Objet : Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ewaldt at gdls.com Thu Jul 5 07:41:59 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 5 Jul 2007 08:41:59 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: John: Could you include code to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From Jdemarco at hudsonhealthplan.org Thu Jul 5 08:20:37 2007 From: Jdemarco at hudsonhealthplan.org (Jim DeMarco) Date: Thu, 5 Jul 2007 09:20:37 -0400 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <007801c7bdf6$36aed360$7c58a27a@pcadt> References: <007801c7bdf6$36aed360$7c58a27a@pcadt> Message-ID: <0B8880A20E2CF24280FA60901E108FB08F28FD@TTNEXCHSVR.hshhp.com> Awesome news!! Congrats Marty you certainly deserve it. Wasn't there just a thread on this here?? Were we clairvoyant? Jim DeMarco -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Wednesday, July 04, 2007 12:44 AM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 08:26:22 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 09:26:22 -0400 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <007801c7bdf6$36aed360$7c58a27a@pcadt> Message-ID: <20070705132640.76E80BEF0@smtp-auth.no-ip.com> Indeed, congrats Marty, well deserved. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Wednesday, July 04, 2007 12:44 AM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 08:28:05 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 09:28:05 -0400 Subject: [AccessD] FW: Performance tips anyone? Message-ID: <20070705132822.AF216BF04@smtp-auth.no-ip.com> Can our list manager help Thomas figure out why he gets bounce messages. His messages are getting through but he is being told they aren't. Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com _____ From: ewaldt at gdls.com [mailto:ewaldt at gdls.com] Sent: Thursday, July 05, 2007 9:07 AM To: jwcolby at colbyconsulting.com Subject: Re: Performance tips anyone? John: I keep sending this to the list, but it keeps being rejected; something about "the recipient's BlackBerry Handheld". Anyway, thought I'd send it on to you. You've probably already thought of it, but just in case... Could you include code in a module to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From jwcolby at colbyconsulting.com Thu Jul 5 08:45:58 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 09:45:58 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <000a01c7bef0$330cbdd0$6800a8c0@anniec> Message-ID: <20070705134615.7C7B3BD93@smtp-auth.no-ip.com> I have to say, that is a big database, specifically the Fes. Definitely get the temp tables out of the FE. What you might want to do is create the temp db and temp table on-the-fly as you start a report. That way it is always started from scratch and no compact/repair is ever required. You can even move to using the "IN SOMEDATABASE" clause to allow accessing the data without having to create links to the temp Bes. The other thing you will want to do is a decompile / compile / compact / repair to shrink the FE size. If you haven't done that in awhile, you might be amazed how much it shrinks down. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Thursday, July 05, 2007 6:35 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De?: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy??: 5 juillet 2007 01:10 ??: Access Developers discussion and problem solving Objet?: Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running > in runtime mode) is slow. The number of concurrent user keep growing > over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > some pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database > would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free > and has a large capacity (more than enough for what I need). Will it > really help in speeding up the database? How hard is it to set up? > Any good documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > -- 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 Thu Jul 5 09:03:13 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 05 Jul 2007 10:03:13 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <002201c7be90$215364f0$6800a8c0@anniec> References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <013001c7bf0d$3adadb10$8abea8c0@XPS> Annie, Besides keeping a pointer open to the BE at all times, which John already mentioned: 1. Make sure that the MDB/MDEs are not being virus scanned on the clients and server. 2. If a NT/2000/2003 server is used to share the backend, consider turning off OPLOCKS (opportunistic locking). 3. Make sure the backend is only a level or two deep in the directory structure and access via a drive letter rather then UNC naming convention. I think everything else has already been mentioned. At the application level, Indexing of course is critical. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Wednesday, July 04, 2007 7:08 PM To: accessd at databaseadvisors.com Subject: [AccessD] Performance tips anyone? Hi all, I have a customer that complains about his database (BE/FE A97 running in runtime mode) is slow. The number of concurrent user keep growing over the years and it's up to 10 or 12 now. What I'm looking at right now is to optimize the whole database and upgrade to Access 2003. I've look at the performance tips from this page (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some pretty usefull information. Anyone has other tips on getting this database more performing? I was also wondering if using a dedicated server for the database would help to improve performance? And what about SQL Server 2005 Express? I've read here that it's free and has a large capacity (more than enough for what I need). Will it really help in speeding up the database? How hard is it to set up? Any good documentation I can read on this? Thanks to all of you! Annie Courchesne, CMA -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 09:09:14 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 10:09:14 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <013001c7bf0d$3adadb10$8abea8c0@XPS> Message-ID: <20070705140931.CD7D8BDC9@smtp-auth.no-ip.com> Wow, this thread needs to be distilled and placed up on our site as a "how to". There have been a lot of good suggestions here. I actually ran into the virus checker thing a few years back and spent an hour or two tracking it down, but did I remember that for this thread? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 10:03 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Annie, Besides keeping a pointer open to the BE at all times, which John already mentioned: 1. Make sure that the MDB/MDEs are not being virus scanned on the clients and server. 2. If a NT/2000/2003 server is used to share the backend, consider turning off OPLOCKS (opportunistic locking). 3. Make sure the backend is only a level or two deep in the directory structure and access via a drive letter rather then UNC naming convention. I think everything else has already been mentioned. At the application level, Indexing of course is critical. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Wednesday, July 04, 2007 7:08 PM To: accessd at databaseadvisors.com Subject: [AccessD] Performance tips anyone? Hi all, I have a customer that complains about his database (BE/FE A97 running in runtime mode) is slow. The number of concurrent user keep growing over the years and it's up to 10 or 12 now. What I'm looking at right now is to optimize the whole database and upgrade to Access 2003. I've look at the performance tips from this page (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some pretty usefull information. Anyone has other tips on getting this database more performing? I was also wondering if using a dedicated server for the database would help to improve performance? And what about SQL Server 2005 Express? I've read here that it's free and has a large capacity (more than enough for what I need). Will it really help in speeding up the database? How hard is it to set up? Any good documentation I can read on this? Thanks to all of you! Annie Courchesne, CMA -- 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 markamatte at hotmail.com Thu Jul 5 09:11:56 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 05 Jul 2007 14:11:56 +0000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Message-ID: I've been able to handle about 40(on a LAN)...lot of transactional stuff...but with more than 40 I seemed to end up with corruption every other day. I had about a 1 second screen transition. Mark A. Matte >From: "jwcolby" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 00:29:03 -0400 > >Anita, > > >I think that 10-12 users is the absolute maximum you will get out of an >Access database it will continue to get slower over the years as the >database grows. At some stage you would probably have to upgrade to SQL >server. > >Errrrr! Wrong answer. > >I have a database with 25 users in the database every day. The BE is >currently about 800 mbytes. This BE has tables with hundreds of thousands >of records in some tables, 30K-50K records in the main tables (claimant / >claim). I open a VERY complex tabbed form with about 20 tabs on it, with >subforms on each tab (JIT subforms). > >Users on fast machines open the form in about 1.2 seconds. Users on very >old slow machines take about 5 to 6 seconds. > >Speed of the individual workstation is the single largest determinate of >acceptable speed. A high speed processor and LOTS of memory (1 gig for >Windows XP Pro) are essential. Moving to a 1 gbit lan made a big >difference >as well (which requires a gigabit NIC in the machines as well). > >And of course all of the things you mentioned in terms of FE optimizations. > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith >Sent: Wednesday, July 04, 2007 9:00 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Performance tips anyone? > >Annie, >There are a number of things you can do to speed up an Access Database. I >haven't looked at the link you provided, but here are a few suggestions >based on my experience over the years: > >* Make sure your tables contain indexes on the fields frequently used for >criteria in queries >* Put the criteria on the ONE side of the relationship in queries >* Don't open forms and reports with large underlying recordsources. If >possible open the forms with only 1 underlying record - not a whole table. >* I have found that opening a form specifying the procedure arguments makes >it open faster > DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of > DoCmd.OpenForm "MyForm" > >Upgrading to A2003 probably won't make much difference. > >Using Runtime mode should not make it run any slower either. > >SQL server Express is a great option, but you would probably have to >rewrite >the form and report recordsources to really take advantage of it. It is not >hard to set up. I think there is an upgrade wizard that will upgrade an >Access Database to SQL Server. > >I think that 10-12 users is the absolute maximum you will get out of an >Access database it will continue to get slower over the years as the >database grows. At some stage you would probably have to upgrade to SQL >server. > >I hope this helps a bit. > >Anita > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 From markamatte at hotmail.com Thu Jul 5 09:21:41 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 05 Jul 2007 14:21:41 +0000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <000a01c7bef0$330cbdd0$6800a8c0@anniec> Message-ID: Here in this office they have what they call a 'resource server'...basically a desktop...with a shared folder housing the BE. The DB is the only thing on this machine. The reason is that their public drive gets so much traffic...the db was taking a serious performance hit. So I have a copy of the FE on each machine...the BE on an isolated shared machine. Everytime they launch the FE...the FE is updated if updates are available...relinks the BE if necessary...and off we go. Mark A. Matte >From: "Annie Courchesne, CMA" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 06:35:26 -0400 > >Hi all, > >Wow, lots of great tips! > >Any thoughts about having a dedicated server for the BE db only? > >The BE db is 650mb with 200 tables. The largest table 1.5 millions >records. > > >The FE db is split in two db, one with the forms and one with the report. >The form db is 45mb with about 2000 objects. The report db is 14 mb with >about 1000 objects. The report db as to be compacted regularly since it's >using temp table and the size can grow to 500 mb depending of the report >printed. > >Thanks! > >Annie Courchesne, CMA > > >-----Message d'origine----- >De?: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel >Envoy??: 5 juillet 2007 01:10 >??: Access Developers discussion and problem solving >Objet?: Re: [AccessD] Performance tips anyone? > >Annie, > >If you have forms with lots of comboboxes, it certainly helps if you >don't populate them unless and until they are needed, i.e. set the Row >Source on their Enter event. > >Similarly, if you have forms with subforms on different pages of a tab >control, leave the Source Object of the subforms blanks, and only set it >if and when that tab is selected. > >And here's another thing I only found out about this week... the first >time a saved query is run after the database is compacted, will be slow, >because the query plan has to be re-created. So if you compact/repair >the front-end application file, queries will run slow the first time, >and forms based on queries will open slowly the first time. An argument >against 'Compact On Close' - but then, for memory, I don't think Comapct >On Close was available in Access 97. > >Regards >Steve > > >Annie Courchesne, CMA wrote: > > Hi all, > > > > > > > > I have a customer that complains about his database (BE/FE A97 running >in > > runtime mode) is slow. The number of concurrent user keep growing over >the > > years and it's up to 10 or 12 now. > > > > > > > > What I'm looking at right now is to optimize the whole database and >upgrade > > to Access 2003. I've look at the performance tips from this page > > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > > pretty usefull information. > > > > > > > > Anyone has other tips on getting this database more performing? > > > > > > > > I was also wondering if using a dedicated server for the database would >help > > to improve performance? > > > > > > > > And what about SQL Server 2005 Express? I've read here that it's free >and > > has a large capacity (more than enough for what I need). Will it really > > help in speeding up the database? How hard is it to set up? Any good > > documentation I can read on this? > > > > > > > > Thanks to all of you! > > > > > > > > > > > > Annie Courchesne, CMA > > > > > > >-- >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 _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 From jimdettman at verizon.net Thu Jul 5 09:25:22 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 05 Jul 2007 10:25:22 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Message-ID: <001801c7bf10$534792d0$8abea8c0@XPS> Mark, You hit on a key point; with JET, and a well designed and written app, it's not performance that is an issue, but one of corruption. With a typical read/write app, by the time you get past 40 or so users, it's almost impossible to keep the environment stable enough to prevent corruptions from occurring. Case in point, years ago I was aware of one JET based reporting/ready only app that ran perfectly fine with 200+ users. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Thursday, July 05, 2007 10:12 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? I've been able to handle about 40(on a LAN)...lot of transactional stuff...but with more than 40 I seemed to end up with corruption every other day. I had about a 1 second screen transition. Mark A. Matte >From: "jwcolby" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 00:29:03 -0400 > >Anita, > > >I think that 10-12 users is the absolute maximum you will get out of an >Access database it will continue to get slower over the years as the >database grows. At some stage you would probably have to upgrade to SQL >server. > >Errrrr! Wrong answer. > >I have a database with 25 users in the database every day. The BE is >currently about 800 mbytes. This BE has tables with hundreds of thousands >of records in some tables, 30K-50K records in the main tables (claimant / >claim). I open a VERY complex tabbed form with about 20 tabs on it, with >subforms on each tab (JIT subforms). > >Users on fast machines open the form in about 1.2 seconds. Users on very >old slow machines take about 5 to 6 seconds. > >Speed of the individual workstation is the single largest determinate of >acceptable speed. A high speed processor and LOTS of memory (1 gig for >Windows XP Pro) are essential. Moving to a 1 gbit lan made a big >difference >as well (which requires a gigabit NIC in the machines as well). > >And of course all of the things you mentioned in terms of FE optimizations. > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith >Sent: Wednesday, July 04, 2007 9:00 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Performance tips anyone? > >Annie, >There are a number of things you can do to speed up an Access Database. I >haven't looked at the link you provided, but here are a few suggestions >based on my experience over the years: > >* Make sure your tables contain indexes on the fields frequently used for >criteria in queries >* Put the criteria on the ONE side of the relationship in queries >* Don't open forms and reports with large underlying recordsources. If >possible open the forms with only 1 underlying record - not a whole table. >* I have found that opening a form specifying the procedure arguments makes >it open faster > DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of > DoCmd.OpenForm "MyForm" > >Upgrading to A2003 probably won't make much difference. > >Using Runtime mode should not make it run any slower either. > >SQL server Express is a great option, but you would probably have to >rewrite >the form and report recordsources to really take advantage of it. It is not >hard to set up. I think there is an upgrade wizard that will upgrade an >Access Database to SQL Server. > >I think that 10-12 users is the absolute maximum you will get out of an >Access database it will continue to get slower over the years as the >database grows. At some stage you would probably have to upgrade to SQL >server. > >I hope this helps a bit. > >Anita > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migratio n_HM_mini_2G_0507 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Thu Jul 5 09:34:46 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 05 Jul 2007 16:34:46 +0200 Subject: [AccessD] Performance tips anyone? Message-ID: Hi Mark We've had success too with this kind of a server loaded with Linux/Samba, either NAS-Lite or FreeNAS (discussed previously in several threads). /gustav >>> markamatte at hotmail.com 05-07-2007 16:21 >>> Here in this office they have what they call a 'resource server'...basically a desktop...with a shared folder housing the BE. The DB is the only thing on this machine. The reason is that their public drive gets so much traffic...the db was taking a serious performance hit. So I have a copy of the FE on each machine...the BE on an isolated shared machine. Everytime they launch the FE...the FE is updated if updates are available...relinks the BE if necessary...and off we go. Mark A. Matte From listmaster at databaseadvisors.com Thu Jul 5 10:23:11 2007 From: listmaster at databaseadvisors.com (Bryan Carbonnell) Date: Thu, 5 Jul 2007 11:23:11 -0400 Subject: [AccessD] FW: Performance tips anyone? In-Reply-To: <20070705132822.AF216BF04@smtp-auth.no-ip.com> References: <20070705132822.AF216BF04@smtp-auth.no-ip.com> Message-ID: On 7/5/07, jwcolby wrote: > Can our list manager help Thomas figure out why he gets bounce messages. > His messages are getting through but he is being told they aren't. Thomas, Contact me off list and I'll work on this with you. -- Bryan Carbonnell - listmaster at databaseadvisors.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From DWUTKA at Marlow.com Thu Jul 5 10:47:41 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 10:47:41 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Brave? I have a database with ~80, and it's predecessor used to handle ~125 users. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Wednesday, July 04, 2007 11:57 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 10:51:47 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 10:51:47 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705054251.62982BD59@smtp-auth.no-ip.com> Message-ID: It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwcolby at colbyconsulting.com Thu Jul 5 10:54:08 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 11:54:08 -0400 Subject: [AccessD] FW: Performance tips anyone? In-Reply-To: Message-ID: <20070705155426.AA3C7BF4B@smtp-auth.no-ip.com> Bryan, I don't think he is seeing his posts to the list, (he is getting bounce notices) so it is doubtful that he is seeing YOUR posts to the list either, although that might not be true. Anyway, I think you need to contact him directly. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bryan Carbonnell Sent: Thursday, July 05, 2007 11:23 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] FW: Performance tips anyone? On 7/5/07, jwcolby wrote: > Can our list manager help Thomas figure out why he gets bounce messages. > His messages are getting through but he is being told they aren't. Thomas, Contact me off list and I'll work on this with you. -- Bryan Carbonnell - listmaster at databaseadvisors.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Thu Jul 5 11:12:44 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 09:12:44 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <0JKP008WWRHA2JB0@l-daemon> Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From developer at ultradnt.com Thu Jul 5 11:21:19 2007 From: developer at ultradnt.com (Steve Conklin) Date: Thu, 5 Jul 2007 12:21:19 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <468C7AB0.8090900@mvps.org> References: <002201c7be90$215364f0$6800a8c0@anniec><000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> <468C7AB0.8090900@mvps.org> Message-ID: <001401c7bf20$89329240$0764a8c0@ULTRADNT> Steve: I have made this change in production apps, and have seen the time drop from minutes to seconds. Steve -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Thursday, July 05, 2007 12:59 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Sorry to be contrary, Steve, but I don't think this is supported by the evidence. In fact, I believe DoCmd.OpenQuery would perform faster if you are running a saved query, as long as the number of records hasn't changed dramatically since the last time it was run. But either way, I think this is possibly academic interest only, as the speed differences here are likely to be imperceptible. Regards Steve Steve Conklin wrote: > Replace any DoCmd.RunSQL's with CurrentDB.execute. > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 11:30:15 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 12:30:15 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <0JKP008WWRHA2JB0@l-daemon> Message-ID: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 Jim.Hale at FleetPride.com Thu Jul 5 11:41:15 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 5 Jul 2007 11:41:15 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <000a01c7bef0$330cbdd0$6800a8c0@anniec> References: <002201c7be90$215364f0$6800a8c0@anniec> <468C7D11.9050201@mvps.org> <000a01c7bef0$330cbdd0$6800a8c0@anniec> Message-ID: Is your network local, ie. the backend is on a server with a fast connection? No one has mentioned this but my experience has been anything outside the local office connecting to a backend on our network is unacceptably slow (I believe we have dedicated T1s, I'll find out from the notwork guy). Connecting through a VPN connection over the net is unacceptable for us even with broadband. My backends range from 100mg-400mg. Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Thursday, July 05, 2007 5:35 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De?: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy??: 5 juillet 2007 01:10 ??: Access Developers discussion and problem solving Objet?: Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running > in runtime mode) is slow. The number of concurrent user keep growing > over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > some pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database > would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free > and has a large capacity (more than enough for what I need). Will it > really help in speeding up the database? How hard is it to set up? > Any good documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > -- 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From accessd at shaw.ca Thu Jul 5 11:55:40 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 09:55:40 -0700 Subject: [AccessD] Global Tracking Security chips In-Reply-To: Message-ID: <0JKP007CMTGXLVM2@l-daemon> Hi All: Has anyone heard of or used Global Tracking Security chips? A potential client is asking about information on this as they will be putting on an art show where there are many irreplaceable pieces that will be displayed. MTIA Jim From cfoust at infostatsystems.com Thu Jul 5 11:52:00 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 09:52:00 -0700 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <003201c7bdfb$dea71000$6402a8c0@ScuzzPaq> References: <007801c7bdf6$36aed360$7c58a27a@pcadt> <003201c7bdfb$dea71000$6402a8c0@ScuzzPaq> Message-ID: My congratulations as well, Marty. Well done and well deserved!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Tuesday, July 03, 2007 11:44 PM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- From cfoust at infostatsystems.com Thu Jul 5 11:55:39 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 09:55:39 -0700 Subject: [AccessD] Omission of Me In-Reply-To: <000001c7be66$3ede82e0$06b62ad1@SusanOne> References: <000001c7be66$3ede82e0$06b62ad1@SusanOne> Message-ID: What do you mean by "dropped the need for"? The Me and the other forms of identifiers tell the database engine what it's dealing with so that intellisense is available and syntax checking knows enough to blow up on a misspelling or squawk if the Option Explicit is set on. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 04, 2007 11:08 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Omission of Me Does anyone remember what version of Access dropped the need for Me or the Forms.formname identifiers when the form (or report) is current? I think it was XP, but I really don't remember. It seems like it's been around for a really long time, so maybe it was 2000? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Thu Jul 5 12:12:24 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 10:12:24 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> Message-ID: <0JKP00LIVU8Q9590@l-daemon> Hi John: You are right about newbies learning how to use 'unbound'. For my part, my experience extends from before Access when 'unbound' was the only way... but Access has been for many years the best presentation and reporting tool around... bar none. The Visual Studio (.Net) versions are replacing this and with the new Reporting features in all MS SQL versions we have moved full-circle back to 'unbound' world. In this new environment newbies will have to learn to use 'unbound'. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 cfoust at infostatsystems.com Thu Jul 5 12:08:48 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 10:08:48 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> References: <0JKP008WWRHA2JB0@l-daemon> <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> Message-ID: I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 DWUTKA at Marlow.com Thu Jul 5 12:13:41 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 12:13:41 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <0JKP008WWRHA2JB0@l-daemon> Message-ID: Heavy user performance is keyed to being unbound. I will concede that with a low number of users (30 or less) bound still has a lot of advantages. Then again, I don't write Access interfaces very often, most of my stuff is VB or ASP for a front end. (Wrote a Data Class builder for VB 6. Point it at a database, select a table, and it builds a single data class and collection data class for me. Makes VB interfaces even easier). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 11:13 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 12:15:33 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 12:15:33 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> Message-ID: But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From cfoust at infostatsystems.com Thu Jul 5 12:14:57 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 10:14:57 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <0JKP00LIVU8Q9590@l-daemon> References: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> <0JKP00LIVU8Q9590@l-daemon> Message-ID: Not necessarily, or at least, not in the same way. The forms and reports in .Net can be bound to a dataset with ease, it's the data that is largely unbound or at least bound JIT. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 10:12 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Hi John: You are right about newbies learning how to use 'unbound'. For my part, my experience extends from before Access when 'unbound' was the only way... but Access has been for many years the best presentation and reporting tool around... bar none. The Visual Studio (.Net) versions are replacing this and with the new Reporting features in all MS SQL versions we have moved full-circle back to 'unbound' world. In this new environment newbies will have to learn to use 'unbound'. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 jwcolby at colbyconsulting.com Thu Jul 5 12:22:41 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 13:22:41 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705172259.4A273BF60@smtp-auth.no-ip.com> Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 DWUTKA at Marlow.com Thu Jul 5 12:28:45 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 12:28:45 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705172259.4A273BF60@smtp-auth.no-ip.com> Message-ID: I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwcolby at colbyconsulting.com Thu Jul 5 12:32:08 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 13:32:08 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim From cfoust at infostatsystems.com Thu Jul 5 12:38:11 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 10:38:11 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705172259.4A273BF60@smtp-auth.no-ip.com> References: <20070705172259.4A273BF60@smtp-auth.no-ip.com> Message-ID: Well, if the shoe fits .... LOL No, John, I'm saying that newcomers to Access shouldn't just use the paint by numbers approach. Since Access is being positioned for power users rather than developers, my remarks were directed toward said users. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:23 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with >unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 cfoust at infostatsystems.com Thu Jul 5 12:40:48 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 10:40:48 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705173226.C6086BF69@smtp-auth.no-ip.com> References: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Message-ID: Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From reuben at gfconsultants.com Thu Jul 5 12:44:27 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Thu, 5 Jul 2007 13:44:27 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Message-ID: Damn, who brought up bound vs unbound again? They need taken out back and beatin. Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 05, 2007 1:32 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > > Drew, > > >But Access is just as well suited for unbound solutions too. > > Just as well suited as what? Access is NOT as well suited for > unbound as it > is for bound. Access just has TONS of features in it directly > dependent on > bound forms and controls. Unbounders throw all that stuff away; > To try and > implement that stuff in an unbound solution requires a LOT of custom code. > AFAICT most Access "unbounders" make no effort to recreate most of what > Access just "gives" us bounders. > > And Access is certainly NOT as well suited for unbound as VB.Net > (or even VB > 6), not that I am an expert in .Net yet. But you are talking a > whole nother > ball game when you talk .Net. > > So as much as I love ya, I have to disagree with that one. I > think you are > one of the "been doing Access unbound so long you forgot the pain" folk. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > Sent: Thursday, July 05, 2007 1:16 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Performance tips anyone? > > But Access is just as well suited for unbound solutions too. The only > exception to that rule is it's goofiness with callback routines. (Can't go > into debug if you have a callback routine ANYWHERE. Goes haywire). > > Drew > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, July 05, 2007 11:30 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > Jim, > > >You mentioning this will not cause near the stir as it did 10 years ago > as > most (all?) have now accepted the reality. ;-) > > LOL, no not quite. Access is a tool built from the ground up for bound. > To > even discuss unbound for Access NOW, when much more robust > unbound tools are > available is ... well... kinda silly. Unless of course you have > been doing > unbound with Access for the last 10 years in which case you have the > expertise to do so. Telling the average Access nubee to use > Access unbound > is IMHO a disservice to the nubee. He might as well just go learn VB.Net. > > As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am > not an Access nubee). > > The right tool for the job so to speak. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence > Sent: Thursday, July 05, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > Yes, Drew you have hit on the key to performance... 'unbound'. > > You mentioning this will not cause near the stir as it did 10 years ago as > most (all?) have now accepted the reality. ;-) > > Jim > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From ssharkins at setel.com Thu Jul 5 12:58:32 2007 From: ssharkins at setel.com (Susan Harkins) Date: Thu, 5 Jul 2007 13:58:32 -0400 Subject: [AccessD] Omission of Me In-Reply-To: References: <000001c7be66$3ede82e0$06b62ad1@SusanOne> Message-ID: <007601c7bf2e$1b00b320$1c32fad1@SusanOne> I always use Me because I don't know what version readers are using. It seems to me that its possible to drop Me in certain cases. If IsNull(cboSubject) Then MsgBox "Please select a subject", vbOKOnly, "Error" Exit Sub End If The above's the only thing I can come up with -- in older versions, wasn't the Me identifier required before the control, as in the following: If IsNull(Me.cboSubject) Then Or, am I just making stuff up again? Susan H. What do you mean by "dropped the need for"? The Me and the other forms of identifiers tell the database engine what it's dealing with so that intellisense is available and syntax checking knows enough to blow up on a misspelling or squawk if the Option Explicit is set on. Charlotte Foust From jwcolby at colbyconsulting.com Thu Jul 5 13:53:41 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 14:53:41 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Thu Jul 5 14:00:27 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 05 Jul 2007 15:00:27 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Message-ID: <006601c7bf36$c0cce0a0$8abea8c0@XPS> Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 Jul 5 14:02:01 2007 From: davidmcafee at gmail.com (David McAfee) Date: Thu, 5 Jul 2007 12:02:01 -0700 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: References: <007801c7bdf6$36aed360$7c58a27a@pcadt> <003201c7bdfb$dea71000$6402a8c0@ScuzzPaq> Message-ID: <8786a4c00707051202p77962928w79735d64aced0e5c@mail.gmail.com> Congratulations Marty, much deserved! > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL > Sent: Tuesday, July 03, 2007 11:44 PM > To: Access Developers discussion and problem solving > Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP > > It is my pleasure to announce that Marty Connelly has joined the > family of Access MVP's. > > My heartiest congratulations Marty! The recognition accorded to you > is richly deserved and was keenly anticipated. We are all delighted. > > Your contributions to various forums carry such a wealth of > information that most of your posts qualify for inclusion in a > collection meant for ready reference. > > Best wishes, > A.D.Tejpal > From jwcolby at colbyconsulting.com Thu Jul 5 14:06:16 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 15:06:16 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705190634.6DE42BCB7@smtp-auth.no-ip.com> I never said anything about hard to use unbound, I said suited to unbound. It plainly is NOT. Access is designed from the ground for bound. It is like taking a Mercedes and yanking the engine out, taking a cutting torch to the frame and trying to stuff a Chevy v8 in it, then splice in all other systems. Yea, it can be done, but it is not "well suited" for that. ANY unbound is harder than bound (regardless of the engine), because you are doing all of the work that the built in "bound code" does for you automatically. You know that Charlotte, you just like to argue. I (bound) do not have to do any locking, etc. You do. And there are TONS of other things that come with the bounded-ness that you either do not provide, or code in all over again. In my personal opinion, it IS hard to use unbound for exactly those reasons. If I wanted to write code to replace the Access bound engine I would not use the Access bound engine!!! At least not if I were starting a project today, July 2007. And of course I do count you in with Drew. Those who have done it so long they forgot the pain. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 Jim.Hale at FleetPride.com Thu Jul 5 14:34:05 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 5 Jul 2007 14:34:05 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <006601c7bf36$c0cce0a0$8abea8c0@XPS> References: <20070705173226.C6086BF69@smtp-auth.no-ip.com> <006601c7bf36$c0cce0a0$8abea8c0@XPS> Message-ID: < You just have to write the same code you would have to write in *any* language to work with unbound objects.> That may be true but I have to side with John also. Many of the users who initially have the timidity to try Access haven't ever coded in *any* other language. The initial learning curve for power user newbies is hard enough without having to worry about unbound concepts. Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 2:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From DWUTKA at Marlow.com Thu Jul 5 14:54:58 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 14:54:58 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Message-ID: I've only played around in .Net. Have not really found a use for it yet. Not that it's a bad language or system, it's just that everything I do already has the VB runtimes, and I have so much VB code that I just am sticking with VB 6 for now. So I can't debate what VB.Net can and can't do. As far as Access goes, I haven't been doing Access unbound very often. I usually just use Access as the db. But as far as Access Front Ends go, I'll through in a form or report when I need it for small projects, but if I am going to be building a full blown access front end, I usually am making it unbound, mainly due to limitations on bound objects. Let me explain, most of the Access FE work is stuff I'm doing as side work. At the moment, I only have one person asking for that, and he can do a lot in Access already. So I get the projects that are a little more then 'cookie cutter' style. For instance, the last big one I built was an inventory system. Some of what they needed to do went beyond what bound can do naturally. So instead of trying to cram the bound 'mold' into what they wanted to do, I built the business logic into Class modules. Everything tied in together, so when something was update in one place, the events alerted every affected process. By it's very nature, this type of business layer has to be unbound (because a bound form leaves the business logic out). My point in this, is that it depends on the project goals. Of course, as we all know, our work is a lot like art. Everyone has their own styles and preferred tools. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:32 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 14:56:01 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 14:56:01 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: I think it was JWC. (oh look at that big stick over there, how did that get there?) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Reuben Cummings Sent: Thursday, July 05, 2007 12:44 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Damn, who brought up bound vs unbound again? They need taken out back and beatin. Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 05, 2007 1:32 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > > Drew, > > >But Access is just as well suited for unbound solutions too. > > Just as well suited as what? Access is NOT as well suited for > unbound as it > is for bound. Access just has TONS of features in it directly > dependent on > bound forms and controls. Unbounders throw all that stuff away; > To try and > implement that stuff in an unbound solution requires a LOT of custom code. > AFAICT most Access "unbounders" make no effort to recreate most of what > Access just "gives" us bounders. > > And Access is certainly NOT as well suited for unbound as VB.Net > (or even VB > 6), not that I am an expert in .Net yet. But you are talking a > whole nother > ball game when you talk .Net. > > So as much as I love ya, I have to disagree with that one. I > think you are > one of the "been doing Access unbound so long you forgot the pain" folk. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > Sent: Thursday, July 05, 2007 1:16 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Performance tips anyone? > > But Access is just as well suited for unbound solutions too. The only > exception to that rule is it's goofiness with callback routines. (Can't go > into debug if you have a callback routine ANYWHERE. Goes haywire). > > Drew > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, July 05, 2007 11:30 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > Jim, > > >You mentioning this will not cause near the stir as it did 10 years ago > as > most (all?) have now accepted the reality. ;-) > > LOL, no not quite. Access is a tool built from the ground up for bound. > To > even discuss unbound for Access NOW, when much more robust > unbound tools are > available is ... well... kinda silly. Unless of course you have > been doing > unbound with Access for the last 10 years in which case you have the > expertise to do so. Telling the average Access nubee to use > Access unbound > is IMHO a disservice to the nubee. He might as well just go learn VB.Net. > > As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am > not an Access nubee). > > The right tool for the job so to speak. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence > Sent: Thursday, July 05, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > Yes, Drew you have hit on the key to performance... 'unbound'. > > You mentioning this will not cause near the stir as it did 10 years ago as > most (all?) have now accepted the reality. ;-) > > Jim > > > -- > 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 14:57:45 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 14:57:45 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> Message-ID: Watch out, you've never tried my cookies..... they stay soft and gooey for days, a touch of extra molasses, with maple syrup in them (REAL maple syrup), and loaded with chocolate chunks. Faster isn't always better.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 1:54 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 15:02:52 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 15:02:52 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <006601c7bf36$c0cce0a0$8abea8c0@XPS> Message-ID: If the tabs in the database window stopped at forms, I would almost agree. However, access has a WONDERFUL reporting capability. I have written a handful of 'unbound' reports, but only a handful. Every other report I have written is as bound as they come. As I just explained in my last post, the advantage of creating an unbound interface is the control. With reporting, you are just allowing data to be viewed (nothing is being modified), so the need for control isn't there. Reports aside, however, there are other reasons to use Access unbound. The end users want the Access interface is a big one. Please keep in mind, this debate isn't about which is better. Building bound Access apps is great. Access excels at it. This debate is about the validity of creating unbound Access apps...which Access also does quite well with. Hard to prove it's not valid when several good examples have been given why it is valid. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 2:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From carbonnb at gmail.com Thu Jul 5 15:03:44 2007 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Thu, 5 Jul 2007 16:03:44 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> Message-ID: On 7/5/07, Drew Wutka wrote: > Watch out, you've never tried my cookies..... they stay soft and gooey You're right. I haven't. Hint. Hint. > Faster isn't always better.... ;) Yea, but waiting years...... C'Mon. I'm going to have to send my new address. Oops. this should be over on OT :) -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From cfoust at infostatsystems.com Thu Jul 5 15:03:11 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 13:03:11 -0700 Subject: [AccessD] Omission of Me In-Reply-To: <007601c7bf2e$1b00b320$1c32fad1@SusanOne> References: <000001c7be66$3ede82e0$06b62ad1@SusanOne> <007601c7bf2e$1b00b320$1c32fad1@SusanOne> Message-ID: I don't recall it being absolutely required in any of VBA versions, but I could be wrong about A95. In theory, there's a penalty for not using it because the application has to figure out whether you're referring to a control, a field or a variable on the fly, which means if you don't have option explicit set on, it will assume any misspelling is a new variable. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Thursday, July 05, 2007 10:59 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Omission of Me I always use Me because I don't know what version readers are using. It seems to me that its possible to drop Me in certain cases. If IsNull(cboSubject) Then MsgBox "Please select a subject", vbOKOnly, "Error" Exit Sub End If The above's the only thing I can come up with -- in older versions, wasn't the Me identifier required before the control, as in the following: If IsNull(Me.cboSubject) Then Or, am I just making stuff up again? Susan H. What do you mean by "dropped the need for"? The Me and the other forms of identifiers tell the database engine what it's dealing with so that intellisense is available and syntax checking knows enough to blow up on a misspelling or squawk if the Option Explicit is set on. Charlotte Foust -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From DWUTKA at Marlow.com Thu Jul 5 15:05:30 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 15:05:30 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705190634.6DE42BCB7@smtp-auth.no-ip.com> Message-ID: Huh? You've stepped backwards quite a bit on this ol' buddy. Bound and unbound handle data transfers the exact same way, they are using Jet. There is no need to put in extra locks. In fact, that's one of the main reasons I will go unbound with an app, is if I need to avoid some of the issues involved with a bound application. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 2:06 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? I never said anything about hard to use unbound, I said suited to unbound. It plainly is NOT. Access is designed from the ground for bound. It is like taking a Mercedes and yanking the engine out, taking a cutting torch to the frame and trying to stuff a Chevy v8 in it, then splice in all other systems. Yea, it can be done, but it is not "well suited" for that. ANY unbound is harder than bound (regardless of the engine), because you are doing all of the work that the built in "bound code" does for you automatically. You know that Charlotte, you just like to argue. I (bound) do not have to do any locking, etc. You do. And there are TONS of other things that come with the bounded-ness that you either do not provide, or code in all over again. In my personal opinion, it IS hard to use unbound for exactly those reasons. If I wanted to write code to replace the Access bound engine I would not use the Access bound engine!!! At least not if I were starting a project today, July 2007. And of course I do count you in with Drew. Those who have done it so long they forgot the pain. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From miscellany at mvps.org Thu Jul 5 15:05:46 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 06 Jul 2007 08:05:46 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: Message-ID: <468D4F1A.6050707@mvps.org> Annie, Some good information on this topic at http://www.granite.ab.ca/access/temptables.htm Regards Steve Annie Courchesne, CMA wrote: > > The temp tables are on the local machine also, but I never thought to have > those table put in a completely seperated db and to recreate them at start > up... I'll have to look this up. From cfoust at infostatsystems.com Thu Jul 5 15:04:17 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 13:04:17 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <006601c7bf36$c0cce0a0$8abea8c0@XPS> References: <20070705173226.C6086BF69@smtp-auth.no-ip.com> <006601c7bf36$c0cce0a0$8abea8c0@XPS> Message-ID: But there used to be no really good alternative, pre .Net days. Why wouldn't you have used it unbound? Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 12:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 DWUTKA at Marlow.com Thu Jul 5 15:07:59 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 15:07:59 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Well that's very true. A newbie developer is going to use bound concepts from the get go. I, for example, worked with Access for a few months before I was forced to use code to do a few things (that very first task was to hide the Access window...can't do it without code). I continued to use bound stuff until I got into classes and collections. That changed the whole spectrum. Hey, who was it, on this list, that I sent a copy of the Inventory Database I built. Whoever it was, pop in here and tell me if you could build those capabilities into a strictly bound application. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim Sent: Thursday, July 05, 2007 2:34 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? < You just have to write the same code you would have to write in *any* language to work with unbound objects.> That may be true but I have to side with John also. Many of the users who initially have the timidity to try Access haven't ever coded in *any* other language. The initial learning curve for power user newbies is hard enough without having to worry about unbound concepts. Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 2:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 15:09:01 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 15:09:01 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Believe it or not, I have not forgotten about that, Stephen shouldn't have offered his to Alan, that's why I've been dragging my feet. ;) Send me your new address offline, I'll sneak some too ya! Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bryan Carbonnell Sent: Thursday, July 05, 2007 3:04 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? On 7/5/07, Drew Wutka wrote: > Watch out, you've never tried my cookies..... they stay soft and gooey You're right. I haven't. Hint. Hint. > Faster isn't always better.... ;) Yea, but waiting years...... C'Mon. I'm going to have to send my new address. Oops. this should be over on OT :) -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From cfoust at infostatsystems.com Thu Jul 5 15:07:49 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 13:07:49 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705190634.6DE42BCB7@smtp-auth.no-ip.com> References: <20070705190634.6DE42BCB7@smtp-auth.no-ip.com> Message-ID: >> You know that Charlotte, you just like to argue. MOI?? Not true!! That's a case of the pot calling the kettle black! And what does "suited" mean anyhow? Once ADO came into the picture, Access was suited to unbound objects, including data objects. By your logic, all .Net forms and reports would use their built in connection strings to access data because it designed in. In fact, the flexibility of .Net lies in NOT using all the "built-in" stuff. Same like Access. ;-> Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:06 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? I never said anything about hard to use unbound, I said suited to unbound. It plainly is NOT. Access is designed from the ground for bound. It is like taking a Mercedes and yanking the engine out, taking a cutting torch to the frame and trying to stuff a Chevy v8 in it, then splice in all other systems. Yea, it can be done, but it is not "well suited" for that. ANY unbound is harder than bound (regardless of the engine), because you are doing all of the work that the built in "bound code" does for you automatically. You know that Charlotte, you just like to argue. I (bound) do not have to do any locking, etc. You do. And there are TONS of other things that come with the bounded-ness that you either do not provide, or code in all over again. In my personal opinion, it IS hard to use unbound for exactly those reasons. If I wanted to write code to replace the Access bound engine I would not use the Access bound engine!!! At least not if I were starting a project today, July 2007. And of course I do count you in with Drew. Those who have done it so long they forgot the pain. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 markamatte at hotmail.com Thu Jul 5 16:05:02 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 05 Jul 2007 21:05:02 +0000 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Actually...You 'kinda' brought it up Drew...but Jim L ran with it!!!...lol Mark Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew >From: "Drew Wutka" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 14:56:01 -0500 > >I think it was JWC. (oh look at that big stick over there, how did that >get there?) > >Drew > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Reuben >Cummings >Sent: Thursday, July 05, 2007 12:44 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Performance tips anyone? > >Damn, who brought up bound vs unbound again? They need taken out back >and >beatin. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > > Sent: Thursday, July 05, 2007 1:32 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > > > Drew, > > > > >But Access is just as well suited for unbound solutions too. > > > > Just as well suited as what? Access is NOT as well suited for > > unbound as it > > is for bound. Access just has TONS of features in it directly > > dependent on > > bound forms and controls. Unbounders throw all that stuff away; > > To try and > > implement that stuff in an unbound solution requires a LOT of custom >code. > > AFAICT most Access "unbounders" make no effort to recreate most of >what > > Access just "gives" us bounders. > > > > And Access is certainly NOT as well suited for unbound as VB.Net > > (or even VB > > 6), not that I am an expert in .Net yet. But you are talking a > > whole nother > > ball game when you talk .Net. > > > > So as much as I love ya, I have to disagree with that one. I > > think you are > > one of the "been doing Access unbound so long you forgot the pain" >folk. > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > > Sent: Thursday, July 05, 2007 1:16 PM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] Performance tips anyone? > > > > But Access is just as well suited for unbound solutions too. The only > > exception to that rule is it's goofiness with callback routines. >(Can't go > > into debug if you have a callback routine ANYWHERE. Goes haywire). > > > > Drew > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > > Sent: Thursday, July 05, 2007 11:30 AM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > Jim, > > > > >You mentioning this will not cause near the stir as it did 10 years >ago > > as > > most (all?) have now accepted the reality. ;-) > > > > LOL, no not quite. Access is a tool built from the ground up for >bound. > > To > > even discuss unbound for Access NOW, when much more robust > > unbound tools are > > available is ... well... kinda silly. Unless of course you have > > been doing > > unbound with Access for the last 10 years in which case you have the > > expertise to do so. Telling the average Access nubee to use > > Access unbound > > is IMHO a disservice to the nubee. He might as well just go learn >VB.Net. > > > > As for me, if I need unbound it will be in VB.Net, NOT in Access (and >I am > > not an Access nubee). > > > > The right tool for the job so to speak. > > > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim >Lawrence > > Sent: Thursday, July 05, 2007 12:13 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > Yes, Drew you have hit on the key to performance... 'unbound'. > > > > You mentioning this will not cause near the stir as it did 10 years >ago as > > most (all?) have now accepted the reality. ;-) > > > > Jim > > > > > > -- > > 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 >The information contained in this transmission is intended only for the >person or entity to which it is addressed and may contain II-VI Proprietary >and/or II-VI BusinessSensitve material. If you are not the intended >recipient, please contact the sender immediately and destroy the material >in its entirety, whether electronic or hard copy. You are notified that any >review, retransmission, copying, disclosure, dissemination, or other use >of, or taking of any action in reliance upon this information by persons or >entities other than the intended recipient is prohibited. > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01 From DWUTKA at Marlow.com Thu Jul 5 16:24:50 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 16:24:50 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Oh my, where did that stick go, it was just there a minute ago!!! Your honor, I would like to plead the 5th! And while we're at it, I have a constitutional right to face my accuser, so since this is an email list, you'll have to come to Dallas if you want to charge me with inciting another bound/unbound debate, or, more grammatically correct, for slamming on the cookie cutting bounders. ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Thursday, July 05, 2007 4:05 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? Actually...You 'kinda' brought it up Drew...but Jim L ran with it!!!...lol Mark Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew >From: "Drew Wutka" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 14:56:01 -0500 > >I think it was JWC. (oh look at that big stick over there, how did that >get there?) > >Drew > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Reuben >Cummings >Sent: Thursday, July 05, 2007 12:44 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Performance tips anyone? > >Damn, who brought up bound vs unbound again? They need taken out back >and >beatin. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > > Sent: Thursday, July 05, 2007 1:32 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > > > Drew, > > > > >But Access is just as well suited for unbound solutions too. > > > > Just as well suited as what? Access is NOT as well suited for > > unbound as it > > is for bound. Access just has TONS of features in it directly > > dependent on > > bound forms and controls. Unbounders throw all that stuff away; > > To try and > > implement that stuff in an unbound solution requires a LOT of custom >code. > > AFAICT most Access "unbounders" make no effort to recreate most of >what > > Access just "gives" us bounders. > > > > And Access is certainly NOT as well suited for unbound as VB.Net > > (or even VB > > 6), not that I am an expert in .Net yet. But you are talking a > > whole nother > > ball game when you talk .Net. > > > > So as much as I love ya, I have to disagree with that one. I > > think you are > > one of the "been doing Access unbound so long you forgot the pain" >folk. > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > > Sent: Thursday, July 05, 2007 1:16 PM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] Performance tips anyone? > > > > But Access is just as well suited for unbound solutions too. The only > > exception to that rule is it's goofiness with callback routines. >(Can't go > > into debug if you have a callback routine ANYWHERE. Goes haywire). > > > > Drew > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > > Sent: Thursday, July 05, 2007 11:30 AM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > Jim, > > > > >You mentioning this will not cause near the stir as it did 10 years >ago > > as > > most (all?) have now accepted the reality. ;-) > > > > LOL, no not quite. Access is a tool built from the ground up for >bound. > > To > > even discuss unbound for Access NOW, when much more robust > > unbound tools are > > available is ... well... kinda silly. Unless of course you have > > been doing > > unbound with Access for the last 10 years in which case you have the > > expertise to do so. Telling the average Access nubee to use > > Access unbound > > is IMHO a disservice to the nubee. He might as well just go learn >VB.Net. > > > > As for me, if I need unbound it will be in VB.Net, NOT in Access (and >I am > > not an Access nubee). > > > > The right tool for the job so to speak. > > > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim >Lawrence > > Sent: Thursday, July 05, 2007 12:13 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > Yes, Drew you have hit on the key to performance... 'unbound'. > > > > You mentioning this will not cause near the stir as it did 10 years >ago as > > most (all?) have now accepted the reality. ;-) > > > > Jim > > > > > > -- > > 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 >The information contained in this transmission is intended only for the >person or entity to which it is addressed and may contain II-VI Proprietary >and/or II-VI BusinessSensitve material. If you are not the intended >recipient, please contact the sender immediately and destroy the material >in its entirety, whether electronic or hard copy. You are notified that any >review, retransmission, copying, disclosure, dissemination, or other use >of, or taking of any action in reliance upon this information by persons or >entities other than the intended recipient is prohibited. > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From miscellany at mvps.org Thu Jul 5 17:01:56 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 06 Jul 2007 10:01:56 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: <001401c7bf20$89329240$0764a8c0@ULTRADNT> References: <002201c7be90$215364f0$6800a8c0@anniec> <000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> <468C7AB0.8090900@mvps.org> <001401c7bf20$89329240$0764a8c0@ULTRADNT> Message-ID: <468D6A54.206@mvps.org> That's cool, Steve. Can you think of anything else you might have changed at the same time? Regards Steve Steve Conklin wrote: > Steve: > I have made this change in production apps, and have seen the time drop from > minutes to seconds. > From martyconnelly at shaw.ca Thu Jul 5 20:02:11 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 05 Jul 2007 18:02:11 -0700 Subject: [AccessD] Manipulate AC95 mdb files without converting In-Reply-To: <00ef01c7bc70$b3da5da0$6600a8c0@TheWaddles> References: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> <00ef01c7bc70$b3da5da0$6600a8c0@TheWaddles> Message-ID: <468D9493.5000309@shaw.ca> You can also open an Excel Spreadsheet using the JET OLE DB Provider to read into a Access table, removing the header record , just set a reference to ADO, should work with 95. You could modify this to use individual sheets or ranges. You might get away with using linking an xls file through the Link Manager as a table, never tried it with access 95 I skipped that version. ADO version oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _ "Data Source=c:\somepath\mySpreadsheet.xls;" & _ "Extended Properties=""Excel 8.0;HDR=Yes""" Where "HDR=Yes" means that there is a header row in the cell range (or named range), so the provider will not include the first row of the selection into the recordset. If "HDR=No", then the provider will include the first row of the cell range (or named ranged) into the recordset. ExcelADO demonstrates how to use ADO to read and write data in Excel workbooks http://support.microsoft.com/default.aspx?scid=kb;en-us;278973 Then write table back to excel with ADO into specific Cells. Careful this is Excel based. Import data from Access to Excel (ADO) single worksheet http://erlandsendata.no/english/index.php?d=envbadacimportado Kevin Waddle wrote: >Anita, > >I'm sorry I didn't make it clear what I am trying to do. > >But your suggestion pointed me in the right direction. > >I am trying to import data from an Excel file into the AC95 db. > >What I ended up doing is creating an Access Object within Excel and running >a RunSQL command on each line in the Excel Sheet. > >Thank you, >Kevin > > >355/113 - Not the famous number Pi, but a great simulation! > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith >Sent: Sunday, July 01, 2007 10:26 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Manipulate AC95 mdb files without converting > >Kevin >You should be able to simply open the database with any later versions of >Access and enter data directly into it. >Anita Smith >Australia > > > > >>Access Guru's, >> >>I have a client that uses a VB application that creates and uses an >>Access >>95 mdb. >> >>He would like to add data directly to the mdb from Access 2002 or Excel. >> >>Is it possible, directly or through an add-in, to manipulate data in >>an Access 95 file? >> >>Thank you, >>Kevin >> >> >> > > -- Marty Connelly Victoria, B.C. Canada From accessd at shaw.ca Thu Jul 5 21:58:25 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 19:58:25 -0700 Subject: [AccessD] Isolating matching and related records In-Reply-To: <468D9493.5000309@shaw.ca> Message-ID: <0JKQ003S9LDENDD5@l-daemon> Hi All: The following question seems like a simple SQL question but I just can not find the appropriate answer at this minute... too many long nights. Given: 1. A table of many records, with each record having a couple fields called {section] and [code]. 2. The content of field [section] has only three possible entries of "A1","B1" and "C1". The contents of field [code] can be any of a variety of codes. 3. There will always be records for group "A1" and "C1" but not always for "B1" What SQL code would find the group where there are no matching "B1" records and delete all the records in the "C1" group An example of data could be; 5 records of [section] = "A1", [code] = "TTR" 4 records of [section] = "B1", [code] = "TTR" 30 records of [section] = "C1", [code] = "TTR" 3 records of [section] = "A1", [code] = "CYR" 47 records of [section] = "C1", [code] = "CYR" 5 records of [section] = "A1", [code] = "PIJ" 4 records of [section] = "B1", [code] = "PIJ" 30 records of [section] = "C1", [code] = "PIJ" After the SQL code was run all 47 records with [section] = "C1' and [code] = "CYR" would be gone. It does not seem like a difficult process but... MTIA Jim From jmhecht at earthlink.net Thu Jul 5 22:03:35 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Thu, 5 Jul 2007 20:03:35 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> References: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> Message-ID: <000501c7bf7a$3ec87b70$6701a8c0@ACER2G> Looking at my bleeding hands.... That was the problem, I was holding the cookie cutter wrong and that's why my mdbs were never as good. : ( Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 accessd at shaw.ca Thu Jul 5 22:11:04 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 20:11:04 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> Message-ID: <0JKQ002GJLYHG560@l-daemon> Of course you could always make an 'unbound' framework for those applications that have more than 10 users. Think of it John; Framework-Lite ('bound') for 1 to 10 users, Framework-Pro ('unbound') for 11 to 250 users and finally Framework-Web (written in ASP.Net) for unlimited. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 jwcolby at colbyconsulting.com Fri Jul 6 00:12:51 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 6 Jul 2007 01:12:51 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <0JKQ002GJLYHG560@l-daemon> Message-ID: <20070706051310.779F1BCC5@smtp-auth.no-ip.com> LOL. I am using framework-pro (.net 2.0) for anything that needs more than Access bound can give me. And framework-lite (bound) is routinely handling 25 users, every day. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 11:11 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Of course you could always make an 'unbound' framework for those applications that have more than 10 users. Think of it John; Framework-Lite ('bound') for 1 to 10 users, Framework-Pro ('unbound') for 11 to 250 users and finally Framework-Web (written in ASP.Net) for unlimited. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com From adtejpal at gmail.com Fri Jul 6 02:51:13 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Fri, 6 Jul 2007 13:21:13 +0530 Subject: [AccessD] Isolating matching and related records References: <0JKQ003S9LDENDD5@l-daemon> Message-ID: <001101c7bfa2$883106b0$0957a27a@pcadt> Jim, Delete query as given below, should get you the desired results. Best wishes, A.D.Tejpal --------------- ======================================== DELETE * FROM T_Codes WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 WHERE T1.Section = "B1"),0,1),0) > 0; ======================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Friday, July 06, 2007 08:28 Subject: [AccessD] Isolating matching and related records Hi All: The following question seems like a simple SQL question but I just can not find the appropriate answer at this minute... too many long nights. Given: 1. A table of many records, with each record having a couple fields called {section] and [code]. 2. The content of field [section] has only three possible entries of "A1","B1" and "C1". The contents of field [code] can be any of a variety of codes. 3. There will always be records for group "A1" and "C1" but not always for "B1" What SQL code would find the group where there are no matching "B1" records and delete all the records in the "C1" group An example of data could be; 5 records of [section] = "A1", [code] = "TTR" 4 records of [section] = "B1", [code] = "TTR" 30 records of [section] = "C1", [code] = "TTR" 3 records of [section] = "A1", [code] = "CYR" 47 records of [section] = "C1", [code] = "CYR" 5 records of [section] = "A1", [code] = "PIJ" 4 records of [section] = "B1", [code] = "PIJ" 30 records of [section] = "C1", [code] = "PIJ" After the SQL code was run all 47 records with [section] = "C1' and [code] = "CYR" would be gone. It does not seem like a difficult process but... MTIA Jim From miscellany at mvps.org Fri Jul 6 03:50:22 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 06 Jul 2007 20:50:22 +1200 Subject: [AccessD] OpenForm parameters Message-ID: <468E024E.60506@mvps.org> In the recent discussion here in the thread "Performance tips anyone?", it was suggested that explicitly entering the arguments in an OpenForm call will improve the performance of the form opening. Just for fun, I have done an admittedly crude test, on the basis of which unfortunately this idea was not supported. I had some code to open and close a bound form 1000 times, and record the time in seconds. 3 trials. The results when the form was opened like this: DoCmd.OpenForm "MyForm" ... were: 19 23 23 The results when the form was opened like this: DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit, acWindowNormal ... were: 24 20 25 So, if these results are an indication, in fact the reverse may be true. Which would make sense, when you think about it, that pre-compiled default values may be a bit quicker than having to evaluate code at runtime. Oh well... Regards Steve From accessd666 at yahoo.com Fri Jul 6 05:09:12 2007 From: accessd666 at yahoo.com (Sad Der) Date: Fri, 6 Jul 2007 03:09:12 -0700 (PDT) Subject: [AccessD] Disable left-shift Message-ID: <925380.90087.qm@web31613.mail.mud.yahoo.com> Hi, Just had a very nice moment :-). "Hi Access guru: (people disgust Access around here) Please test the new and improved 250 hour costly SQL Server security modification and see if you can hack it." While they were laughing and smiling I browsed in the explorer to the adp. Opened it using left shift. Selected a table and deleted all records and smiled back. The look on their faces....awsome!!!!!! The user that was implemented in the connection setting was dbo_owner whoehahaha. So the fun is over, does anybody have the 'disable left shift' key code lying around. I can't find it 1-2-3. Thanks in Advance! Regards, Sander ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ From hkotsch at arcor.de Fri Jul 6 05:44:55 2007 From: hkotsch at arcor.de (Helmut Kotsch) Date: Fri, 6 Jul 2007 12:44:55 +0200 Subject: [AccessD] Disable left-shift In-Reply-To: <925380.90087.qm@web31613.mail.mud.yahoo.com> Message-ID: Function faq_DisableShiftKeyBypass() As Boolean 'The next time the database is opened ' after this function has been run, ' the autoexec macro will not be bypassed, ' even if the shift key is pressed. On Error GoTo errDisableShift Dim db As Database Dim prop As Property Const conPropNotFound = 3270 Set db = CurrentDb() db.Properties("AllowByPassKey") = False faq_DisableShiftKeyBypass = True exitDisableShift: Exit Function errDisableShift: 'The AllowBypassKey property is a user-defined ' property of the database that must be created ' before it can be set. This error code will execute ' the first time this function is run in a database. If Err = conPropNotFound Then Set prop = db.CreateProperty("AllowByPassKey", _ dbBoolean, False) db.Properties.Append prop Resume Next Else MsgBox "Function DisableShiftKeyBypass did" & _ " not complete successfully." faq_DisableShiftKeyBypass = False GoTo exitDisableShift End If End Function HTH Helmut -----Ursprungliche Nachricht----- Von: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]Im Auftrag von Sad Der Gesendet: Freitag, 6. Juli 2007 12:09 An: Acces User Group Betreff: [AccessD] Disable left-shift Hi, Just had a very nice moment :-). "Hi Access guru: (people disgust Access around here) Please test the new and improved 250 hour costly SQL Server security modification and see if you can hack it." While they were laughing and smiling I browsed in the explorer to the adp. Opened it using left shift. Selected a table and deleted all records and smiled back. The look on their faces....awsome!!!!!! The user that was implemented in the connection setting was dbo_owner whoehahaha. So the fun is over, does anybody have the 'disable left shift' key code lying around. I can't find it 1-2-3. Thanks in Advance! Regards, Sander ____________________________________________________________________________ ________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Fri Jul 6 07:20:23 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 08:20:23 -0400 Subject: [AccessD] Disable left-shift In-Reply-To: <925380.90087.qm@web31613.mail.mud.yahoo.com> References: <925380.90087.qm@web31613.mail.mud.yahoo.com> Message-ID: <002701c7bfc8$1b6ed040$d1b82ad1@SusanOne> Just goes to show that God really does have a sense of humor, and a soft spot for Access developers.;) Nicely done! Susan H. Hi, Just had a very nice moment :-). "Hi Access guru: (people disgust Access around here) Please test the new and improved 250 hour costly SQL Server security modification and see if you can hack it." From markamatte at hotmail.com Fri Jul 6 07:49:32 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 06 Jul 2007 12:49:32 +0000 Subject: [AccessD] Isolating matching and related records In-Reply-To: <0JKQ003S9LDENDD5@l-daemon> Message-ID: Hey Jim, I sent a response to the SQL list. Thanks, Mark >From: Jim Lawrence >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: [AccessD] Isolating matching and related records >Date: Thu, 05 Jul 2007 19:58:25 -0700 > >Hi All: > >The following question seems like a simple SQL question but I just can not >find the appropriate answer at this minute... too many long nights. > >Given: > >1. A table of many records, with each record having a couple fields called >{section] and [code]. > >2. The content of field [section] has only three possible entries of >"A1","B1" and "C1". The contents of field [code] can be any of a variety of >codes. > >3. There will always be records for group "A1" and "C1" but not always for >"B1" > >What SQL code would find the group where there are no matching "B1" records >and delete all the records in the "C1" group > >An example of data could be; > >5 records of [section] = "A1", [code] = "TTR" >4 records of [section] = "B1", [code] = "TTR" >30 records of [section] = "C1", [code] = "TTR" >3 records of [section] = "A1", [code] = "CYR" >47 records of [section] = "C1", [code] = "CYR" >5 records of [section] = "A1", [code] = "PIJ" >4 records of [section] = "B1", [code] = "PIJ" >30 records of [section] = "C1", [code] = "PIJ" > >After the SQL code was run all 47 records with [section] = "C1' and [code] >= >"CYR" would be gone. > >It does not seem like a difficult process but... > >MTIA > >Jim > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From ssharkins at setel.com Fri Jul 6 08:21:36 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 09:21:36 -0400 Subject: [AccessD] Isolating matching and related records In-Reply-To: References: <0JKQ003S9LDENDD5@l-daemon> Message-ID: <005f01c7bfd0$9560a470$d1b82ad1@SusanOne> Don't forget about the Find Unmatched Query Wizard -- it might not give you the exact results that you need, but it can be a good place to start, especially if you're not an expert at Jet SQL. Susan H. Hey Jim, I sent a response to the SQL list. Thanks, Mark > >The following question seems like a simple SQL question but I just can >not find the appropriate answer at this minute... too many long nights. > From fuller.artful at gmail.com Fri Jul 6 10:14:45 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 6 Jul 2007 11:14:45 -0400 Subject: [AccessD] Search within a subform Message-ID: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> I've forgotten how to do this. There's a combo on the master form, but it relates to the subform (the master is unbound). So I need to tell it to search the subform's recordset. TIA, Arthur From John.Clark at niagaracounty.com Fri Jul 6 10:38:27 2007 From: John.Clark at niagaracounty.com (John Clark) Date: Fri, 06 Jul 2007 11:38:27 -0400 Subject: [AccessD] MDE will not open In-Reply-To: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> References: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> Message-ID: <468E29B1.167F.006B.0@niagaracounty.com> I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? John W. Clark Computer Programmer Niagara County Central Data Processing \\ ^ ^ // From robert at webedb.com Fri Jul 6 11:32:23 2007 From: robert at webedb.com (Robert L. Stewart) Date: Fri, 06 Jul 2007 11:32:23 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: Message-ID: <200707061638.l66GcIgV017744@databaseadvisors.com> Framework-Web = Codesmith Tools + .netTiers template Would also work for a Framework-WinForm. Robert At 05:09 AM 7/6/2007, you wrote: >Date: Thu, 05 Jul 2007 20:11:04 -0700 >From: Jim Lawrence >Subject: Re: [AccessD] Performance tips anyone? >To: "'Access Developers discussion and problem solving'" > >Message-ID: <0JKQ002GJLYHG560 at l-daemon> >Content-Type: text/plain; charset=us-ascii > > >Of course you could always make an 'unbound' framework for those >applications that have more than 10 users. > >Think of it John; Framework-Lite ('bound') for 1 to 10 users, Framework-Pro >('unbound') for 11 to 250 users and finally Framework-Web (written in >ASP.Net) for unlimited. :-) > >Jim From ssharkins at setel.com Fri Jul 6 13:09:21 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 14:09:21 -0400 Subject: [AccessD] Syntax for referencing subform in a subform Message-ID: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> I just wrote a quick entry on referencing subforms and a reader wants to know how to reference a subform in a subform. Frankly, I don't think I've ever tried -- I can't remember one single time when I've created a subform in another subform. Since a subform is a control in the form, what's a subform in another subform -- can a control have dependent controls? Susan H. From erbachs at gmail.com Fri Jul 6 13:10:36 2007 From: erbachs at gmail.com (Steve Erbach) Date: Fri, 6 Jul 2007 13:10:36 -0500 Subject: [AccessD] Search within a subform In-Reply-To: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> References: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> Message-ID: <39cb22f30707061110w7bb4d54excb5707d314777b33@mail.gmail.com> Arthur, Are you talking about something like: set rst = Forms("MasterForm")("SubForm").RecordsetClone rst.FindFirst "[KeyField]=123" Steve Erbach On 7/6/07, Arthur Fuller wrote: > I've forgotten how to do this. There's a combo on the master form, but it > relates to the subform (the master is unbound). So I need to tell it to > search the subform's recordset. > > TIA, > Arthur From accessd at shaw.ca Fri Jul 6 13:30:21 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Fri, 06 Jul 2007 11:30:21 -0700 Subject: [AccessD] Isolating matching and related records In-Reply-To: <001101c7bfa2$883106b0$0957a27a@pcadt> Message-ID: <0JKR006D2SIKWQS2@l-daemon> Hi A.D. Tejpal: Your code looks very good but some adjustments would have to be made to make it work in my particular context. I worked backwards, first in MS SQL where SubQueries are available and then translated the result into Access's compound query system. Below is the result for the record: First one record of each match group is created in queries 1 and 2. Then any missing matches are isolated in query 3 and query 4 deletes those matches. I am sure this code could be greatly refined but the results were needed fast. query1: SELECT DISTINCT tblRosterReportTemplate.SectionCode, tblRosterReportTemplate.JobCode FROM tblRosterReportTemplate WHERE (tblRosterReportTemplate.SectionCode="C1") query2: SELECT DISTINCT tblRosterReportTemplate.SectionCode, tblRosterReportTemplate.JobCode FROM tblRosterReportTemplate WHERE (tblRosterReportTemplate.SectionCode="B1") query3: SELECT query1.SectionCode, query1.JobCode FROM query1 LEFT JOIN query2 ON query1.JobCode = query2.JobCode WHERE query2.SectionCode Is Null; query4: DELETE * FROM tblRosterReportTemplate WHERE SectionCode = query3.SectionCode' AND JobCode = query3.JobCode; Thank you so much for your help Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Friday, July 06, 2007 12:51 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Isolating matching and related records Jim, Delete query as given below, should get you the desired results. Best wishes, A.D.Tejpal --------------- ======================================== DELETE * FROM T_Codes WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 WHERE T1.Section = "B1"),0,1),0) > 0; ======================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Friday, July 06, 2007 08:28 Subject: [AccessD] Isolating matching and related records Hi All: The following question seems like a simple SQL question but I just can not find the appropriate answer at this minute... too many long nights. Given: 1. A table of many records, with each record having a couple fields called {section] and [code]. 2. The content of field [section] has only three possible entries of "A1","B1" and "C1". The contents of field [code] can be any of a variety of codes. 3. There will always be records for group "A1" and "C1" but not always for "B1" What SQL code would find the group where there are no matching "B1" records and delete all the records in the "C1" group An example of data could be; 5 records of [section] = "A1", [code] = "TTR" 4 records of [section] = "B1", [code] = "TTR" 30 records of [section] = "C1", [code] = "TTR" 3 records of [section] = "A1", [code] = "CYR" 47 records of [section] = "C1", [code] = "CYR" 5 records of [section] = "A1", [code] = "PIJ" 4 records of [section] = "B1", [code] = "PIJ" 30 records of [section] = "C1", [code] = "PIJ" After the SQL code was run all 47 records with [section] = "C1' and [code] = "CYR" would be gone. It does not seem like a difficult process but... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Fri Jul 6 13:46:30 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 14:46:30 -0400 Subject: [AccessD] Search within a subform In-Reply-To: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> References: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> Message-ID: <009e01c7bffd$f868b030$d1b82ad1@SusanOne> Set the subform's Link Child Fields and Link Master Fields properties? Susan H. I've forgotten how to do this. There's a combo on the master form, but it relates to the subform (the master is unbound). So I need to tell it to search the subform's recordset. From lembit.dbamail at t-online.de Fri Jul 6 13:49:01 2007 From: lembit.dbamail at t-online.de (Lembit Soobik) Date: Fri, 6 Jul 2007 20:49:01 +0200 Subject: [AccessD] Syntax for referencing subform in a subform References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> Message-ID: <001401c7bffe$523e9520$1800a8c0@s1800> Susan, there is a nice document by William Hindman on our website: If you are on ... and want to reference ... Lembit ----- Original Message ----- From: "Susan Harkins" To: "'Access Developers discussion and problem solving'" Sent: Friday, July 06, 2007 8:09 PM Subject: [AccessD] Syntax for referencing subform in a subform >I just wrote a quick entry on referencing subforms and a reader wants to > know how to reference a subform in a subform. Frankly, I don't think I've > ever tried -- I can't remember one single time when I've created a subform > in another subform. > > Since a subform is a control in the form, what's a subform in another > subform -- can a control have dependent controls? > > Susan H. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.1/888 - Release Date: 06.07.2007 > 06:36 > > From adtp at airtelbroadband.in Fri Jul 6 13:50:40 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sat, 7 Jul 2007 00:20:40 +0530 Subject: [AccessD] Search within a subform References: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> Message-ID: <029801c7bffe$9cd26120$c257a27a@pcadt> Arthur, Two of my sample db's as mentioned below, might be of interest to you: (a) Form_Search (b) Form_SearchByYearMonthRange These are available at Rogers Access Library (other developers library). Link - http://www.rogersaccesslibrary.com/OtherLibraries.asp#Tejpal,A.D. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Arthur Fuller To: Access Developers discussion and problem solving Sent: Friday, July 06, 2007 20:44 Subject: [AccessD] Search within a subform I've forgotten how to do this. There's a combo on the master form, but it relates to the subform (the master is unbound). So I need to tell it to search the subform's recordset. TIA, Arthur From adtp at airtelbroadband.in Fri Jul 6 14:10:05 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sat, 7 Jul 2007 00:40:05 +0530 Subject: [AccessD] Syntax for referencing subform in a subform References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> Message-ID: <064601c7c001$586c6eb0$c257a27a@pcadt> Susan, My sample db named FormsSubformsReference might be of interest to you. It is available at Rogers Access Library (other developers library). Link - http://www.rogersaccesslibrary.com/OtherLibraries.asp#Tejpal,A.D. The db covers all likely combinations of origin & destination controls located on the parent as well as subforms representing different levels of nesting. Nesting upto three levels deep is represented. It presents a visual ready reckoner as well. On selection of origin & destination controls, corresponding VBA code gets displayed simultaneously - at the bottom. Apart from showing the required syntax for (a) referring to controls of one group of nested subforms from another group of nested subforms and (b) referring to subroutines (contained in form's modules) across various levels of nested subforms, the sample db demonstrates the syntax for referring controls on forms / nested subforms in SQL statements. Dbl clicking any text box on main parent form or various nested subforms at left, causes its value to be picked up by the query, results of which, are displayed in the innermost nested subform at right. Simultaneously, the SQL used in source query, gets displayed at bottom. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Susan Harkins To: 'Access Developers discussion and problem solving' Sent: Friday, July 06, 2007 23:39 Subject: [AccessD] Syntax for referencing subform in a subform I just wrote a quick entry on referencing subforms and a reader wants to know how to reference a subform in a subform. Frankly, I don't think I've ever tried -- I can't remember one single time when I've created a subform in another subform. Since a subform is a control in the form, what's a subform in another subform -- can a control have dependent controls? Susan H. From Patricia.O'Connor at otda.state.ny.us Fri Jul 6 14:11:22 2007 From: Patricia.O'Connor at otda.state.ny.us (O'Connor, Patricia (OTDA)) Date: Fri, 6 Jul 2007 15:11:22 -0400 Subject: [AccessD] Default table value In-Reply-To: References: Message-ID: <01DBAB52E30A9A4AB3D94EF8029EDBE8021BAEF4@EXCNYSM0A1AI.nysemail.nyenet> I have two fields in several tables which use ENVIRON("USERNAME") or ENVIRON("COMPUTERNAME") I tried saving the table after adding two more fields and it will not allow me to because of the ENVIRON I know about M$ stupid blocking of ENVIRON and CURDIR per http://office.microsoft.com/en-us/access/HA011225981033.aspx#050 I added the two functions to the backend MDB hoping it would allow me to save it -- NOPE. Why wouldn't that look at the function while a query would? Is there some other way to have the DEFAULT value for a table field be ENVIRON("USERNAME") or equal to it? I went in and updated my registry to have the value for Sandbox be a 2 instead of 3 which didn't work. I haven't changed the registry to stop it all together yet. I probably will just so I can add fields. Is there some other way without having to mess with the registry? Other people might not have permission to change their registry. Thank you have a great weekend Patti ************************************************** * Patricia O'Connor * Associate Computer Programmer Analyst * OTDA - BDMA * (W) mailto:Patricia.O'Connor at otda.state.ny.us * (w) mailto:aa1160 at nysemail.state.ny.us ************************************************** -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. From ssharkins at setel.com Fri Jul 6 14:20:43 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 15:20:43 -0400 Subject: [AccessD] Syntax for referencing subform in a subform In-Reply-To: <001401c7bffe$523e9520$1800a8c0@s1800> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> <001401c7bffe$523e9520$1800a8c0@s1800> Message-ID: <00ac01c7c002$c0021ce0$d1b82ad1@SusanOne> Thanks Lembit, I was unable to find it though. I'm sure it's there, I just didn't find it. Susan H. Susan, there is a nice document by William Hindman on our website: If you are on ... and want to reference ... From adtp at airtelbroadband.in Fri Jul 6 14:24:52 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sat, 7 Jul 2007 00:54:52 +0530 Subject: [AccessD] Isolating matching and related records References: <0JKR006D2SIKWQS2@l-daemon> Message-ID: <068101c7c003$5fd68e40$c257a27a@pcadt> You are most welcome Jim! The delete query suggested in my post was developed & tested successfully on Access 2003 desktop. A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Saturday, July 07, 2007 00:00 Subject: Re: [AccessD] Isolating matching and related records Hi A.D. Tejpal: Your code looks very good but some adjustments would have to be made to make it work in my particular context. I worked backwards, first in MS SQL where SubQueries are available and then translated the result into Access's compound query system. Below is the result for the record: First one record of each match group is created in queries 1 and 2. Then any missing matches are isolated in query 3 and query 4 deletes those matches. I am sure this code could be greatly refined but the results were needed fast. query1: SELECT DISTINCT tblRosterReportTemplate.SectionCode, tblRosterReportTemplate.JobCode FROM tblRosterReportTemplate WHERE (tblRosterReportTemplate.SectionCode="C1") query2: SELECT DISTINCT tblRosterReportTemplate.SectionCode, tblRosterReportTemplate.JobCode FROM tblRosterReportTemplate WHERE (tblRosterReportTemplate.SectionCode="B1") query3: SELECT query1.SectionCode, query1.JobCode FROM query1 LEFT JOIN query2 ON query1.JobCode = query2.JobCode WHERE query2.SectionCode Is Null; query4: DELETE * FROM tblRosterReportTemplate WHERE SectionCode = query3.SectionCode' AND JobCode = query3.JobCode; Thank you so much for your help Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Friday, July 06, 2007 12:51 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Isolating matching and related records Jim, Delete query as given below, should get you the desired results. Best wishes, A.D.Tejpal --------------- ======================================== DELETE * FROM T_Codes WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 WHERE T1.Section = "B1"),0,1),0) > 0; ======================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Friday, July 06, 2007 08:28 Subject: [AccessD] Isolating matching and related records Hi All: The following question seems like a simple SQL question but I just can not find the appropriate answer at this minute... too many long nights. Given: 1. A table of many records, with each record having a couple fields called {section] and [code]. 2. The content of field [section] has only three possible entries of "A1","B1" and "C1". The contents of field [code] can be any of a variety of codes. 3. There will always be records for group "A1" and "C1" but not always for "B1" What SQL code would find the group where there are no matching "B1" records and delete all the records in the "C1" group An example of data could be; 5 records of [section] = "A1", [code] = "TTR" 4 records of [section] = "B1", [code] = "TTR" 30 records of [section] = "C1", [code] = "TTR" 3 records of [section] = "A1", [code] = "CYR" 47 records of [section] = "C1", [code] = "CYR" 5 records of [section] = "A1", [code] = "PIJ" 4 records of [section] = "B1", [code] = "PIJ" 30 records of [section] = "C1", [code] = "PIJ" After the SQL code was run all 47 records with [section] = "C1' and [code] = "CYR" would be gone. It does not seem like a difficult process but... MTIA Jim From markamatte at hotmail.com Fri Jul 6 15:13:41 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 06 Jul 2007 20:13:41 +0000 Subject: [AccessD] Isolating matching and related records In-Reply-To: <0JKR006D2SIKWQS2@l-daemon> Message-ID: Jim, I went back and read my post since I didn't see a reference. Apparently I didn't include the SQL. Would a single delete statement with a subquery accomplish this? ************SQL************** DELETE tblTest.Section, tblTest.code FROM tblTest WHERE (((tblTest.Section)="C1") AND ((tblTest.code) Not In (SELECT tblTest1.code FROM tblTest AS tblTest1 GROUP BY tblTest1.Section, tblTest1.code HAVING (((tblTest1.Section)="B1"));))); ************SQL************** >From: Jim Lawrence >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Isolating matching and related records >Date: Fri, 06 Jul 2007 11:30:21 -0700 > >Hi A.D. Tejpal: > >Your code looks very good but some adjustments would have to be made to >make >it work in my particular context. I worked backwards, first in MS SQL where >SubQueries are available and then translated the result into Access's >compound query system. Below is the result for the record: > >First one record of each match group is created in queries 1 and 2. Then >any >missing matches are isolated in query 3 and query 4 deletes those matches. >I >am sure this code could be greatly refined but the results were needed >fast. > >query1: >SELECT DISTINCT tblRosterReportTemplate.SectionCode, >tblRosterReportTemplate.JobCode >FROM tblRosterReportTemplate >WHERE (tblRosterReportTemplate.SectionCode="C1") > >query2: >SELECT DISTINCT tblRosterReportTemplate.SectionCode, >tblRosterReportTemplate.JobCode >FROM tblRosterReportTemplate >WHERE (tblRosterReportTemplate.SectionCode="B1") > >query3: >SELECT query1.SectionCode, query1.JobCode >FROM query1 LEFT JOIN query2 >ON query1.JobCode = query2.JobCode >WHERE query2.SectionCode Is Null; > >query4: >DELETE * FROM tblRosterReportTemplate >WHERE SectionCode = query3.SectionCode' >AND JobCode = query3.JobCode; > >Thank you so much for your help > >Jim > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL >Sent: Friday, July 06, 2007 12:51 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Isolating matching and related records > >Jim, > > Delete query as given below, should get you the desired results. > >Best wishes, >A.D.Tejpal >--------------- > >======================================== >DELETE * >FROM T_Codes >WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 >WHERE T1.Section = "B1"),0,1),0) > 0; >======================================== > > ----- Original Message ----- > From: Jim Lawrence > To: 'Access Developers discussion and problem solving' > Sent: Friday, July 06, 2007 08:28 > Subject: [AccessD] Isolating matching and related records > > > Hi All: > > The following question seems like a simple SQL question but I just can >not >find the appropriate answer at this minute... too many long nights. > > Given: > > 1. A table of many records, with each record having a couple fields >called >{section] and [code]. > > 2. The content of field [section] has only three possible entries of > "A1","B1" and "C1". The contents of field [code] can be any of a variety >of codes. > > 3. There will always be records for group "A1" and "C1" but not always >for >"B1" > > What SQL code would find the group where there are no matching "B1" >records and delete all the records in the "C1" group > > An example of data could be; > > 5 records of [section] = "A1", [code] = "TTR" > 4 records of [section] = "B1", [code] = "TTR" > 30 records of [section] = "C1", [code] = "TTR" > 3 records of [section] = "A1", [code] = "CYR" > 47 records of [section] = "C1", [code] = "CYR" > 5 records of [section] = "A1", [code] = "PIJ" > 4 records of [section] = "B1", [code] = "PIJ" > 30 records of [section] = "C1", [code] = "PIJ" > > After the SQL code was run all 47 records with [section] = "C1' and >[code] >= "CYR" would be gone. > > It does not seem like a difficult process but... > > MTIA > > Jim >-- >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 _________________________________________________________________ http://liveearth.msn.com From jwcolby at colbyconsulting.com Fri Jul 6 15:23:39 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 6 Jul 2007 16:23:39 -0400 Subject: [AccessD] Syntax for referencing subform in a subform In-Reply-To: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> Message-ID: <20070706202359.525B5BD34@smtp-auth.no-ip.com> There is a subform control in the parent subform. Thus Me!ctlSubform.form!ctlSubSubForm.Form The ! Refers to a control, the . Refers to a property (the form property of the subform control). And I have done it, in fact the disability insurance call center software has a subform on a tab of the main form. Inside of that subform is another tab control EACH of which has a subform. Every subform is loaded JIT and unloaded as the user clicks off the tab the subform is on. Thus the subform on the tab on the parent form doesn't load unless the user clicks on that tab. If they click on that tab, a subform loads with a tab control on it. On the default tab is a subform that loads immediately. But if the user clicks off onto any of the other tabs in the subform, then the subform on the tab losing the focus (clicked off of) unloads. The main form is a claim. The claim form has about 18 tabs that may or may not be visible, depending on the insurance product line. On one of those tabs is all the stuff having to do with benefits for specific months. My client only issues checks for particular insurance products that they service (their clients), so if a claim is selected which does not get paid directly by my client, then the benefit tab is hidden. The Benefit tab has one big subform which has a tab control. That subform's tab control has a tab (and subform) for benefit history (months already paid). The next tab has a subform for entering new benefit records (current and future months). The next tab has a subform for displaying checks paid. The text tab has a subform for entering offsets against the claim specific to that claim (Social Security deductions, tax deductions, child support and such things). There are a handful of other subforms on tabs as well (about 7 or 8 tabs total). ALL of this stuff is specific to particular lines of insurance for which my client actually issues the checks to the claimant. Since all products are not paid by my client (the insurer issues the checks directly) the entire benefit tab is hidden / unhidden as needed for the product that a claim is paid against. In fact this form has 4 levels of subforms Claim Claimant Policy etc. Benefits tab subform Benefit History Offsets against the benefit Benefits New and future Offsets against the Benefit Payments (checks paid) Possible offsets against the claim etc etc BTW, this is the form discussed in a previous thread that takes 1.25 seconds to load on fast hardware, and 5-6 seconds to load on 4-5 year old hardware. Using a tab metaphor with JIT subforms allows the user to have the entire claim and all the relevant pieces at their fingertips but keep the load speed reasonable. Believe it or not, this whole thing fits on an 800 x 600 screen, though I keep banging on them to move everyone up to at LEAST 17" monitors so I can move to a 1024 x 768 screen and open things up a bit. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 06, 2007 2:09 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Syntax for referencing subform in a subform I just wrote a quick entry on referencing subforms and a reader wants to know how to reference a subform in a subform. Frankly, I don't think I've ever tried -- I can't remember one single time when I've created a subform in another subform. Since a subform is a control in the form, what's a subform in another subform -- can a control have dependent controls? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From lembit.dbamail at t-online.de Fri Jul 6 15:52:04 2007 From: lembit.dbamail at t-online.de (Lembit Soobik) Date: Fri, 6 Jul 2007 22:52:04 +0200 Subject: [AccessD] Syntax for referencing subform in a subform References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne><001401c7bffe$523e9520$1800a8c0@s1800> <00ac01c7c002$c0021ce0$d1b82ad1@SusanOne> Message-ID: <000c01c7c00f$823d8220$1800a8c0@s1800> I searched it too, but seems that it is in revision, and I cannot find my copy. maybe Jim L has it available? Lembit ----- Original Message ----- From: "Susan Harkins" To: "'Access Developers discussion and problem solving'" Sent: Friday, July 06, 2007 9:20 PM Subject: Re: [AccessD] Syntax for referencing subform in a subform > Thanks Lembit, I was unable to find it though. I'm sure it's there, I just > didn't find it. > > Susan H. > > Susan, > there is a nice document by William Hindman on our website: If you are on > ... and want to reference ... > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.1/888 - Release Date: 06.07.2007 > 06:36 > > From ssharkins at setel.com Fri Jul 6 19:27:43 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 20:27:43 -0400 Subject: [AccessD] Syntax for referencing subform in a subform In-Reply-To: <000c01c7c00f$823d8220$1800a8c0@s1800> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne><001401c7bffe$523e9520$1800a8c0@s1800><00ac01c7c002$c0021ce0$d1b82ad1@SusanOne> <000c01c7c00f$823d8220$1800a8c0@s1800> Message-ID: <001e01c7c02d$a36f7340$c2b82ad1@SusanOne> It's Okay -- I found what I needed. Thank you. Susan H. I searched it too, but seems that it is in revision, and I cannot find my copy. maybe Jim L has it available? From ssharkins at setel.com Fri Jul 6 19:27:43 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 20:27:43 -0400 Subject: [AccessD] Syntax for referencing subform in a subform In-Reply-To: <20070706202359.525B5BD34@smtp-auth.no-ip.com> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> <20070706202359.525B5BD34@smtp-auth.no-ip.com> Message-ID: <002201c7c02d$a740eda0$c2b82ad1@SusanOne> There is a subform control in the parent subform. Thus Me!ctlSubform.form!ctlSubSubForm.Form =======I wondered if that would be the case. Susan H. From accessd at shaw.ca Sat Jul 7 02:53:17 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 00:53:17 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <009e01c7bffd$f868b030$d1b82ad1@SusanOne> Message-ID: <0JKS002C7TOOG3T1@l-daemon> Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim From miscellany at mvps.org Sat Jul 7 03:41:14 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 07 Jul 2007 20:41:14 +1200 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <0JKS002C7TOOG3T1@l-daemon> References: <0JKS002C7TOOG3T1@l-daemon> Message-ID: <468F51AA.7070203@mvps.org> Jim, In report design, go to the File|Page Setup menu. On the Columns tab, you can set the number and size of columns, and set the Column Layout to "Across then Down". See if that gets you in the right direction. Regads Steve Jim Lawrence wrote: > Hi All: > > Is there a way to print across the page within an Access report? Like in the > following example: > > Record01 record02 record03 record4 record5 > Record06 record07 record08 record9 record10 > record11 record12 record13 record14 record15 > record16 record17 record18 record19 record20 > etc......... > > MTIA > Jim > From rockysmolin at bchacc.com Sat Jul 7 08:28:07 2007 From: rockysmolin at bchacc.com (rockysmolin at bchacc.com) Date: Sat, 7 Jul 2007 09:28:07 -0400 Subject: [AccessD] Access Reports rinting accross Message-ID: <380-2200776713287938@M2W026.mail2web.com> Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- myhosting.com - Premium Microsoft? Windows? and Linux web and application hosting - http://link.myhosting.com/myhosting From bbruen at unwired.com.au Sat Jul 7 09:13:55 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Sun, 8 Jul 2007 00:13:55 +1000 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <468F51AA.7070203@mvps.org> References: <0JKS002C7TOOG3T1@l-daemon> <468F51AA.7070203@mvps.org> Message-ID: <200707080013.55781.bbruen@unwired.com.au> > Jim Lawrence wrote: > > Hi All: > > > > Is there a way to print across the page within an Access report? Like in > > the following example: > > > > Record01 record02 record03 record4 record5 > > Record06 record07 record08 record9 record10 > > record11 record12 record13 record14 record15 > > record16 record17 record18 record19 record20 > > etc......... > > > > MTIA > > Jim Just for the sake of the stupid question... why? -- regards Bruce From accessd at shaw.ca Sat Jul 7 10:04:56 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 08:04:56 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <200707080013.55781.bbruen@unwired.com.au> Message-ID: <0JKT006CUDO2WP93@l-daemon> Hi Bruce: The client is always right and there are so many records in some sections of the report that it streams on for pages with just only two columns of information. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Saturday, July 07, 2007 7:14 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Access Reports rinting accross > Jim Lawrence wrote: > > Hi All: > > > > Is there a way to print across the page within an Access report? Like in > > the following example: > > > > Record01 record02 record03 record4 record5 > > Record06 record07 record08 record9 record10 > > record11 record12 record13 record14 record15 > > record16 record17 record18 record19 record20 > > etc......... > > > > MTIA > > Jim Just for the sake of the stupid question... why? -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sat Jul 7 11:01:37 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 09:01:37 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <380-2200776713287938@M2W026.mail2web.com> Message-ID: <0JKT002VPGAIKM40@l-daemon> Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- myhosting.com - Premium MicrosoftR WindowsR and Linux web and application hosting - http://link.myhosting.com/myhosting -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sat Jul 7 11:06:19 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 09:06:19 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <468F51AA.7070203@mvps.org> Message-ID: <0JKT0084LGIDB410@l-daemon> Hi Steve: I will investigate that option but there are some additional requirements that will make that not so simple. Check out the response to Rocky's email and see what you think. Thanks for help Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 07, 2007 1:41 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Access Reports rinting accross Jim, In report design, go to the File|Page Setup menu. On the Columns tab, you can set the number and size of columns, and set the Column Layout to "Across then Down". See if that gets you in the right direction. Regads Steve Jim Lawrence wrote: > Hi All: > > Is there a way to print across the page within an Access report? Like in the > following example: > > Record01 record02 record03 record4 record5 > Record06 record07 record08 record9 record10 > record11 record12 record13 record14 record15 > record16 record17 record18 record19 record20 > etc......... > > MTIA > Jim > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sat Jul 7 11:09:30 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 09:09:30 -0700 Subject: [AccessD] Isolating matching and related records In-Reply-To: Message-ID: <0JKT003UFGNOPC20@l-daemon> Hi Mark: That looks like the solution. Brilliant, Thanks you very much. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Friday, July 06, 2007 1:14 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Isolating matching and related records Jim, I went back and read my post since I didn't see a reference. Apparently I didn't include the SQL. Would a single delete statement with a subquery accomplish this? ************SQL************** DELETE tblTest.Section, tblTest.code FROM tblTest WHERE (((tblTest.Section)="C1") AND ((tblTest.code) Not In (SELECT tblTest1.code FROM tblTest AS tblTest1 GROUP BY tblTest1.Section, tblTest1.code HAVING (((tblTest1.Section)="B1"));))); ************SQL************** >From: Jim Lawrence >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Isolating matching and related records >Date: Fri, 06 Jul 2007 11:30:21 -0700 > >Hi A.D. Tejpal: > >Your code looks very good but some adjustments would have to be made to >make >it work in my particular context. I worked backwards, first in MS SQL where >SubQueries are available and then translated the result into Access's >compound query system. Below is the result for the record: > >First one record of each match group is created in queries 1 and 2. Then >any >missing matches are isolated in query 3 and query 4 deletes those matches. >I >am sure this code could be greatly refined but the results were needed >fast. > >query1: >SELECT DISTINCT tblRosterReportTemplate.SectionCode, >tblRosterReportTemplate.JobCode >FROM tblRosterReportTemplate >WHERE (tblRosterReportTemplate.SectionCode="C1") > >query2: >SELECT DISTINCT tblRosterReportTemplate.SectionCode, >tblRosterReportTemplate.JobCode >FROM tblRosterReportTemplate >WHERE (tblRosterReportTemplate.SectionCode="B1") > >query3: >SELECT query1.SectionCode, query1.JobCode >FROM query1 LEFT JOIN query2 >ON query1.JobCode = query2.JobCode >WHERE query2.SectionCode Is Null; > >query4: >DELETE * FROM tblRosterReportTemplate >WHERE SectionCode = query3.SectionCode' >AND JobCode = query3.JobCode; > >Thank you so much for your help > >Jim > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL >Sent: Friday, July 06, 2007 12:51 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Isolating matching and related records > >Jim, > > Delete query as given below, should get you the desired results. > >Best wishes, >A.D.Tejpal >--------------- > >======================================== >DELETE * >FROM T_Codes >WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 >WHERE T1.Section = "B1"),0,1),0) > 0; >======================================== > > ----- Original Message ----- > From: Jim Lawrence > To: 'Access Developers discussion and problem solving' > Sent: Friday, July 06, 2007 08:28 > Subject: [AccessD] Isolating matching and related records > > > Hi All: > > The following question seems like a simple SQL question but I just can >not >find the appropriate answer at this minute... too many long nights. > > Given: > > 1. A table of many records, with each record having a couple fields >called >{section] and [code]. > > 2. The content of field [section] has only three possible entries of > "A1","B1" and "C1". The contents of field [code] can be any of a variety >of codes. > > 3. There will always be records for group "A1" and "C1" but not always >for >"B1" > > What SQL code would find the group where there are no matching "B1" >records and delete all the records in the "C1" group > > An example of data could be; > > 5 records of [section] = "A1", [code] = "TTR" > 4 records of [section] = "B1", [code] = "TTR" > 30 records of [section] = "C1", [code] = "TTR" > 3 records of [section] = "A1", [code] = "CYR" > 47 records of [section] = "C1", [code] = "CYR" > 5 records of [section] = "A1", [code] = "PIJ" > 4 records of [section] = "B1", [code] = "PIJ" > 30 records of [section] = "C1", [code] = "PIJ" > > After the SQL code was run all 47 records with [section] = "C1' and >[code] >= "CYR" would be gone. > > It does not seem like a difficult process but... > > MTIA > > Jim >-- >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 _________________________________________________________________ http://liveearth.msn.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From adtp at airtelbroadband.in Sat Jul 7 15:19:53 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sun, 8 Jul 2007 01:49:53 +0530 Subject: [AccessD] Access Reports rinting accross References: <0JKT002VPGAIKM40@l-daemon> Message-ID: <003901c7c0d4$aa756ad0$7757a27a@pcadt> Jim, If there is no objection to the use of multi-column subreport for Section C, that should be most convenient. However, if there are compelling reasons to explore selective printing of multiple records across each row, it can be done by manipulating the Left property of relevant text boxes, simultaneously with report's MoveLayout property. Sample code in report's module, as given below, will ensure printing of three records on each row. The report has a group header as per field named Account. Detail section has two controls named RefNum & ClientName respectively. (Use of # within the names of fields/controls is not preferred). When the report is opened, printing proceeds normally, till the value "Referral" is detected in the group header. Thereafter, it starts printing three records across each row. If another group value different from "Referral" comes up, the printing will again revert back to normal style (i.e. one record per row). Best wishes, A.D.Tejpal --------------- Code in report's module ==================================== ' Declaration Section Dim RecNum As Long Private RefLeft1 As Long, RefLeft2 As Long Private RefLeft3 As Long, ClientLeft1 As Long Private ClientLeft2 As Long, ClientLeft3 As Long --------------------------------------------------------------- Private Sub Detail_Format(Cancel As Integer, _ FormatCount As Integer) Dim Cnt As Long If Me.Account <> "Referral" Then Exit Sub End If If RecNum > 0 Then Cnt = RecNum Mod 3 Select Case Cnt Case 0 Me.RefNum.Left = RefLeft3 Me.ClientName.Left = ClientLeft3 Case 2 Me.RefNum.Left = RefLeft2 Me.ClientName.Left = ClientLeft2 Case Else Me.RefNum.Left = RefLeft1 Me.ClientName.Left = ClientLeft1 End Select Else Me.RefNum.Left = RefLeft1 Me.ClientName.Left = ClientLeft1 End If End Sub --------------------------------------------------------------- Private Sub Detail_Print(Cancel As Integer, _ PrintCount As Integer) Dim Cnt As Long If Me.Account <> "Referral" Then Me.MoveLayout = True Exit Sub End If If RecNum > 0 Then Cnt = RecNum Mod 3 If Cnt = 0 Then Me.MoveLayout = True Else Me.MoveLayout = False End If Else Me.MoveLayout = True End If RecNum = RecNum + 1 End Sub --------------------------------------------------------------- Private Sub GroupHeader0_Format(Cancel _ As Integer, FormatCount As Integer) ' Start the record counter with commencement ' of Referral account ( Set it only once. This is ' to guard against unwanted re-setting if repeat ' section property of hroup header is set to Yes) If Me.Account = "Referral" Then RecNum = IIf(RecNum > 0, RecNum, 1) End If End Sub --------------------------------------------------------------- Private Sub ReportHeader_Format(Cancel _ As Integer, FormatCount As Integer) RefLeft1 = Me.RefNum.Left ClientLeft1 = Me.ClientName.Left RefLeft2 = ClientLeft1 + Me.ClientName.Width + 50 ClientLeft2 = ClientLeft1 + (RefLeft2 - RefLeft1) RefLeft3 = ClientLeft2 + Me.ClientName.Width + 50 ClientLeft3 = ClientLeft2 + (RefLeft3 - RefLeft2) End Sub ==================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Saturday, July 07, 2007 21:31 Subject: Re: [AccessD] Access Reports rinting accross Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim From rockysmolin at bchacc.com Sat Jul 7 19:20:18 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Sat, 7 Jul 2007 17:20:18 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <0JKT002VPGAIKM40@l-daemon> Message-ID: <005c01c7c0f5$c3f25e70$0301a8c0@HAL9005> Jim: How about section C is one text box with width = width of the report, and Can Grow=True. Are sections A, B, and C sub-reports? Or do you create their controls on the fly? In any event, in the Open event of the report I'd still create a temp table - this time 2 fields, one would be the PK = whatever field it is that ties section C to sections A and B, second field would be the Ref#/Client Name concatenations. Create a temp table record for each section A/B and use that temp table data for section C. Maybe make section C a sub report with the temp table as its record source and linked to the main report through the PK? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Saturday, July 07, 2007 9:02 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Access Reports rinting accross Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- myhosting.com - Premium MicrosoftR WindowsR and Linux web and application hosting - http://link.myhosting.com/myhosting -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/890 - Release Date: 7/7/2007 3:26 PM From accessd at shaw.ca Sun Jul 8 14:13:24 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 08 Jul 2007 12:13:24 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <003901c7c0d4$aa756ad0$7757a27a@pcadt> Message-ID: <0JKV00CB8JU1S4G9@l-daemon> Hi A. D. Tejal: A very eloquent solution. :-) A subreport of course can be used and I have not ruled out that option yet... One day Access reporting may provide the ability to set columns per Group Heading. Until then this will have to be the appropriate solution. Thanks you Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Saturday, July 07, 2007 1:20 PM To: Access Developers discussion and problem solving Cc: A.D.TEJPAL Subject: Re: [AccessD] Access Reports rinting accross Jim, If there is no objection to the use of multi-column subreport for Section C, that should be most convenient. However, if there are compelling reasons to explore selective printing of multiple records across each row, it can be done by manipulating the Left property of relevant text boxes, simultaneously with report's MoveLayout property. Sample code in report's module, as given below, will ensure printing of three records on each row. The report has a group header as per field named Account. Detail section has two controls named RefNum & ClientName respectively. (Use of # within the names of fields/controls is not preferred). When the report is opened, printing proceeds normally, till the value "Referral" is detected in the group header. Thereafter, it starts printing three records across each row. If another group value different from "Referral" comes up, the printing will again revert back to normal style (i.e. one record per row). Best wishes, A.D.Tejpal --------------- Code in report's module ==================================== ' Declaration Section Dim RecNum As Long Private RefLeft1 As Long, RefLeft2 As Long Private RefLeft3 As Long, ClientLeft1 As Long Private ClientLeft2 As Long, ClientLeft3 As Long --------------------------------------------------------------- Private Sub Detail_Format(Cancel As Integer, _ FormatCount As Integer) Dim Cnt As Long If Me.Account <> "Referral" Then Exit Sub End If If RecNum > 0 Then Cnt = RecNum Mod 3 Select Case Cnt Case 0 Me.RefNum.Left = RefLeft3 Me.ClientName.Left = ClientLeft3 Case 2 Me.RefNum.Left = RefLeft2 Me.ClientName.Left = ClientLeft2 Case Else Me.RefNum.Left = RefLeft1 Me.ClientName.Left = ClientLeft1 End Select Else Me.RefNum.Left = RefLeft1 Me.ClientName.Left = ClientLeft1 End If End Sub --------------------------------------------------------------- Private Sub Detail_Print(Cancel As Integer, _ PrintCount As Integer) Dim Cnt As Long If Me.Account <> "Referral" Then Me.MoveLayout = True Exit Sub End If If RecNum > 0 Then Cnt = RecNum Mod 3 If Cnt = 0 Then Me.MoveLayout = True Else Me.MoveLayout = False End If Else Me.MoveLayout = True End If RecNum = RecNum + 1 End Sub --------------------------------------------------------------- Private Sub GroupHeader0_Format(Cancel _ As Integer, FormatCount As Integer) ' Start the record counter with commencement ' of Referral account ( Set it only once. This is ' to guard against unwanted re-setting if repeat ' section property of hroup header is set to Yes) If Me.Account = "Referral" Then RecNum = IIf(RecNum > 0, RecNum, 1) End If End Sub --------------------------------------------------------------- Private Sub ReportHeader_Format(Cancel _ As Integer, FormatCount As Integer) RefLeft1 = Me.RefNum.Left ClientLeft1 = Me.ClientName.Left RefLeft2 = ClientLeft1 + Me.ClientName.Width + 50 ClientLeft2 = ClientLeft1 + (RefLeft2 - RefLeft1) RefLeft3 = ClientLeft2 + Me.ClientName.Width + 50 ClientLeft3 = ClientLeft2 + (RefLeft3 - RefLeft2) End Sub ==================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Saturday, July 07, 2007 21:31 Subject: Re: [AccessD] Access Reports rinting accross Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sun Jul 8 14:32:15 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 08 Jul 2007 12:32:15 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <005c01c7c0f5$c3f25e70$0301a8c0@HAL9005> Message-ID: <0JKV00E41KPHISX8@l-daemon> Hi Rocky: I may go the route of a subreport or use A.D. Tejal's eloquent solution. All the data is assembled on the fly and can basically be grouped in any method. As previously stated, why doesn't MS Access report allow columns to be controlled per Group? Thanks for the suggesting so now I know all of the options available. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Saturday, July 07, 2007 5:20 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Access Reports rinting accross Jim: How about section C is one text box with width = width of the report, and Can Grow=True. Are sections A, B, and C sub-reports? Or do you create their controls on the fly? In any event, in the Open event of the report I'd still create a temp table - this time 2 fields, one would be the PK = whatever field it is that ties section C to sections A and B, second field would be the Ref#/Client Name concatenations. Create a temp table record for each section A/B and use that temp table data for section C. Maybe make section C a sub report with the temp table as its record source and linked to the main report through the PK? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Saturday, July 07, 2007 9:02 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Access Reports rinting accross Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- myhosting.com - Premium MicrosoftR WindowsR and Linux web and application hosting - http://link.myhosting.com/myhosting -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/890 - Release Date: 7/7/2007 3:26 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Sun Jul 8 16:14:12 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 8 Jul 2007 17:14:12 -0400 Subject: [AccessD] Syntax for loading a specific version of Access Message-ID: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, Arthur From miscellany at mvps.org Sun Jul 8 16:37:15 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 09 Jul 2007 09:37:15 +1200 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: <4691590B.4000000@mvps.org> Arthur, You mean a desktop shortcut? I think you can just specify which installation of Msaccess.exe you want to use. I.e. in the Target setting of the shortcut's Properties, something like this... "C:\Program Files\Microsoft Office\Office9\Msaccess.exe" "C:\YourFolder\YourApp.mdb" Regards Steve Arthur Fuller wrote: > I scouted the archives but didn't locate what I want, which is to create a > shortcut that knows that I want to load this particular MDB | ADP using > Access 2000, not Access 2003 or Access 2007. > > TIA, > Arthur From bill_patten at earthlink.net Sun Jul 8 16:39:05 2007 From: bill_patten at earthlink.net (Bill Patten) Date: Sun, 8 Jul 2007 14:39:05 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: Arthur, You need to know where Access 2K is located on the PC and put it in the path, like this "C:\Program Files (x86)\Microsoft Office XP\Office10\MSACCESS.EXE" "c:\program files\Mysoftware\mysoftware.MDB" If there are any spaces each must be in quotations marks. Bill ----- Original Message ----- From: "Arthur Fuller" To: "Access Developers discussion and problem solving" Sent: Sunday, July 08, 2007 2:14 PM Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From rusty.hammond at cpiqpc.com Sun Jul 8 16:50:46 2007 From: rusty.hammond at cpiqpc.com (rusty.hammond at cpiqpc.com) Date: Sun, 8 Jul 2007 16:50:46 -0500 Subject: [AccessD] Syntax for loading a specific version of Access Message-ID: <8301C8A868251E4C8ECD3D4FFEA40F8A2584BC3F@cpixchng-1.cpiqpc.net> Arthur, As long as they installed the version of office in the same folder across machines, or if you are putting the app on a single machine, adding the path to the desired exe file will work just fine. If you need a bit more dynamic approach FMS has a solution called Total Access Startup (www.fmsinc.com). I know the FMS products can be pricey but they work and I'm sure there are other programs out there that do the same thing. HTH, Rusty -----Original Message----- From: Bill Patten [mailto:bill_patten at earthlink.net] Sent: Sunday, July 08, 2007 4:39 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access Arthur, You need to know where Access 2K is located on the PC and put it in the path, like this "C:\Program Files (x86)\Microsoft Office XP\Office10\MSACCESS.EXE" "c:\program files\Mysoftware\mysoftware.MDB" If there are any spaces each must be in quotations marks. Bill ----- Original Message ----- From: "Arthur Fuller" To: "Access Developers discussion and problem solving" Sent: Sunday, July 08, 2007 2:14 PM Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, 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 ********************************************************************** WARNING: All e-mail sent to and from this address will be received, scanned or otherwise recorded by the CPI Qualified Plan Consultants, Inc. corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. ********************************************************************** From accessd at shaw.ca Sun Jul 8 17:18:53 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 08 Jul 2007 15:18:53 -0700 Subject: [AccessD] Access DB onlt read In-Reply-To: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: <0JKV003EVSF5NH58@l-daemon> Hi All: Sent a database to a client and now when they attempt to run certain code it displays the following message ''Run Time error 30267', cannot update database or object is read-only'. Within the problem module there are a number of tables created, cleared and re-populated within the code. The DB works just fine here. What could be wrong? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 08, 2007 2:14 PM To: Access Developers discussion and problem solving Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From joeo at appoli.com Sun Jul 8 17:23:45 2007 From: joeo at appoli.com (Joe O'Connell) Date: Sun, 8 Jul 2007 18:23:45 -0400 Subject: [AccessD] Access DB onlt read References: <0JKV003EVSF5NH58@l-daemon> Message-ID: If you sent it on a CD, it will be read only. Have the client change the file's protection. Right click on the file in Windows Explorer, select Properties. Uncheck the Attribute "Read-only". Joe O'Connell -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Sunday, July 08, 2007 6:19 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Access DB onlt read Hi All: Sent a database to a client and now when they attempt to run certain code it displays the following message ''Run Time error 30267', cannot update database or object is read-only'. Within the problem module there are a number of tables created, cleared and re-populated within the code. The DB works just fine here. What could be wrong? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 08, 2007 2:14 PM To: Access Developers discussion and problem solving Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, 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 accessd at shaw.ca Sun Jul 8 20:18:03 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 08 Jul 2007 18:18:03 -0700 Subject: [AccessD] Access DB onlt read In-Reply-To: Message-ID: <0JKW0062H0PRWVR3@l-daemon> Hi Joe: The file was sent by email but zipped. I have sent the client a list of things to try and your suggestion was the first option on the list. Nothing has come back yet... Thanks Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe O'Connell Sent: Sunday, July 08, 2007 3:24 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Access DB onlt read If you sent it on a CD, it will be read only. Have the client change the file's protection. Right click on the file in Windows Explorer, select Properties. Uncheck the Attribute "Read-only". Joe O'Connell -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Sunday, July 08, 2007 6:19 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Access DB onlt read Hi All: Sent a database to a client and now when they attempt to run certain code it displays the following message ''Run Time error 30267', cannot update database or object is read-only'. Within the problem module there are a number of tables created, cleared and re-populated within the code. The DB works just fine here. What could be wrong? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 08, 2007 2:14 PM To: Access Developers discussion and problem solving Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, 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 accessd666 at yahoo.com Mon Jul 9 01:54:54 2007 From: accessd666 at yahoo.com (Sad Der) Date: Sun, 8 Jul 2007 23:54:54 -0700 (PDT) Subject: [AccessD] Disable left-shift In-Reply-To: <002701c7bfc8$1b6ed040$d1b82ad1@SusanOne> Message-ID: <460215.12971.qm@web31605.mail.mud.yahoo.com> Yes, it was a blast haha. A nice suit alone can do it at the exec table...not for code ;-) --- Susan Harkins wrote: > Just goes to show that God really does have a sense > of humor, and a soft > spot for Access developers.;) > > Nicely done! > > Susan H. > > Hi, > > Just had a very nice moment :-). > "Hi Access guru: (people disgust Access around here) > Please test the new and > improved 250 hour costly SQL Server security > modification and see if you > can hack it." > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 From fuller.artful at gmail.com Mon Jul 9 09:08:02 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 9 Jul 2007 10:08:02 -0400 Subject: [AccessD] Current recordset and such Message-ID: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> Hi all, I am writing an Access app designed to replace a commercial app that the client now despises. I am trying to emulate all the cool features that she likes. Among them are a bunch of filter buttons on the form header (such as Age, Status, Balance, Skill Level and so on). All this works nicely. The datasheet form begins by showing all persons (in this case horse-riders). Then filters may be applied to the existing recordset. This is done with code that writes something into Me.Filter and sets FilterOn to True. There is also an option group whose options include Mark All, Find Marked and Unmark all. At the moment the first and third options use a stored procedure, but it addresses the whole table, not the filtered set. That's what I need to address. Perhaps a stored procedure is not the correct way, since a WHERE clause is tough to pass in. So perhaps an alternative is to use the RecordSet object, but I'm not quite sure how. Let's walk through a scenario. 1. Form displays all Riders. 2. User filters the list to include only Riders who are 12 years old. (List drops from 1000 to about 300.) 3. User clicks "Mark All". At the moment, because I'm firing a sproc against the table, all 1000 get marked (there is a column called Marked) rather than the 300 currently selected. I know what I need to do, I'm just shaky on how to manipulate the current recordset. What I need to do is something like this: Dim rs as ADODB.RecordSet bla bla bla Update rs SET Marked = True SET rs = Nothing Me.Requery It's the bla bla bla part that I'm unsure how to code. Next question: At the moment, exerting any of the filter options erases any previous filter. There is a button that clears all filters, but ideally I would like the filter mechanism to be additive. As described above, all I do currently is supply a string to the Filter property (such as "Age = 12" or "Status = 'Active'). I'm thinking that it would be much more powerful if I AND these filter strings. So that if the current filter is "Age = 12" and then I select the Status filter and set it to "Active", the resulting filter will be "Age = 12 and Status = 'Active'. OR is going to be a problem, however, but I can live without it. So, is this simply a case of appending the new filter spec to the old one with an AND in betwixt? I think so, but I thought I'd run it past you experts before coding it. Next question: Does there exist somewhere a list of the commands that appear on the Access menu? I have more than one reason for wanting such a list, but in the immediate context I want to create a button that does "Filter by Form". TIA, Arthur From rockysmolin at bchacc.com Mon Jul 9 09:29:12 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 9 Jul 2007 07:29:12 -0700 Subject: [AccessD] Current recordset and such In-Reply-To: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> Message-ID: <001901c7c235$8563bd70$0301a8c0@HAL9005> Since it's a bound set how about db.Execute "UPDATE....." etc.? I'm assuming the 'selected' check box on the form is bound to a 'selected' field in the bound recordset. I've done this for a custom app. I usually gen these update queries in the QBE grid, then copy the SQL from the SQL view. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 7:08 AM To: Access Developers discussion and problem solving Subject: [AccessD] Current recordset and such Hi all, I am writing an Access app designed to replace a commercial app that the client now despises. I am trying to emulate all the cool features that she likes. Among them are a bunch of filter buttons on the form header (such as Age, Status, Balance, Skill Level and so on). All this works nicely. The datasheet form begins by showing all persons (in this case horse-riders). Then filters may be applied to the existing recordset. This is done with code that writes something into Me.Filter and sets FilterOn to True. There is also an option group whose options include Mark All, Find Marked and Unmark all. At the moment the first and third options use a stored procedure, but it addresses the whole table, not the filtered set. That's what I need to address. Perhaps a stored procedure is not the correct way, since a WHERE clause is tough to pass in. So perhaps an alternative is to use the RecordSet object, but I'm not quite sure how. Let's walk through a scenario. 1. Form displays all Riders. 2. User filters the list to include only Riders who are 12 years old. (List drops from 1000 to about 300.) 3. User clicks "Mark All". At the moment, because I'm firing a sproc against the table, all 1000 get marked (there is a column called Marked) rather than the 300 currently selected. I know what I need to do, I'm just shaky on how to manipulate the current recordset. What I need to do is something like this: Dim rs as ADODB.RecordSet bla bla bla Update rs SET Marked = True SET rs = Nothing Me.Requery It's the bla bla bla part that I'm unsure how to code. Next question: At the moment, exerting any of the filter options erases any previous filter. There is a button that clears all filters, but ideally I would like the filter mechanism to be additive. As described above, all I do currently is supply a string to the Filter property (such as "Age = 12" or "Status = 'Active'). I'm thinking that it would be much more powerful if I AND these filter strings. So that if the current filter is "Age = 12" and then I select the Status filter and set it to "Active", the resulting filter will be "Age = 12 and Status = 'Active'. OR is going to be a problem, however, but I can live without it. So, is this simply a case of appending the new filter spec to the old one with an AND in betwixt? I think so, but I thought I'd run it past you experts before coding it. Next question: Does there exist somewhere a list of the commands that appear on the Access menu? I have more than one reason for wanting such a list, but in the immediate context I want to create a button that does "Filter by Form". TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM From Jim.Hale at FleetPride.com Mon Jul 9 09:51:11 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Mon, 9 Jul 2007 09:51:11 -0500 Subject: [AccessD] Current recordset and such In-Reply-To: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> References: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> Message-ID: How about using a pass through query that sends the built sql string to be executed? Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 9:08 AM To: Access Developers discussion and problem solving Subject: [AccessD] Current recordset and such Hi all, I am writing an Access app designed to replace a commercial app that the client now despises. I am trying to emulate all the cool features that she likes. Among them are a bunch of filter buttons on the form header (such as Age, Status, Balance, Skill Level and so on). All this works nicely. The datasheet form begins by showing all persons (in this case horse-riders). Then filters may be applied to the existing recordset. This is done with code that writes something into Me.Filter and sets FilterOn to True. There is also an option group whose options include Mark All, Find Marked and Unmark all. At the moment the first and third options use a stored procedure, but it addresses the whole table, not the filtered set. That's what I need to address. Perhaps a stored procedure is not the correct way, since a WHERE clause is tough to pass in. So perhaps an alternative is to use the RecordSet object, but I'm not quite sure how. Let's walk through a scenario. 1. Form displays all Riders. 2. User filters the list to include only Riders who are 12 years old. (List drops from 1000 to about 300.) 3. User clicks "Mark All". At the moment, because I'm firing a sproc against the table, all 1000 get marked (there is a column called Marked) rather than the 300 currently selected. I know what I need to do, I'm just shaky on how to manipulate the current recordset. What I need to do is something like this: Dim rs as ADODB.RecordSet bla bla bla Update rs SET Marked = True SET rs = Nothing Me.Requery It's the bla bla bla part that I'm unsure how to code. Next question: At the moment, exerting any of the filter options erases any previous filter. There is a button that clears all filters, but ideally I would like the filter mechanism to be additive. As described above, all I do currently is supply a string to the Filter property (such as "Age = 12" or "Status = 'Active'). I'm thinking that it would be much more powerful if I AND these filter strings. So that if the current filter is "Age = 12" and then I select the Status filter and set it to "Active", the resulting filter will be "Age = 12 and Status = 'Active'. OR is going to be a problem, however, but I can live without it. So, is this simply a case of appending the new filter spec to the old one with an AND in betwixt? I think so, but I thought I'd run it past you experts before coding it. Next question: Does there exist somewhere a list of the commands that appear on the Access menu? I have more than one reason for wanting such a list, but in the immediate context I want to create a button that does "Filter by Form". TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From cfoust at infostatsystems.com Mon Jul 9 09:53:00 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 07:53:00 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <0JKS002C7TOOG3T1@l-daemon> References: <009e01c7bffd$f868b030$d1b82ad1@SusanOne> <0JKS002C7TOOG3T1@l-daemon> Message-ID: Check out snaking columns, across then down, and see if that would work for you. If the "record" is a single item, like a name, that would work. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Saturday, July 07, 2007 12:53 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon Jul 9 09:54:28 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 07:54:28 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: Are you talking about a "send to" or "open with" shortcut, Arthur? Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 08, 2007 2:14 PM To: Access Developers discussion and problem solving Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, Arthur -- 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 Jul 9 10:04:31 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 9 Jul 2007 11:04:31 -0400 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> Open with. Things keep screwing up when I run the app on my box, which has every version of Access loaded since O97, but the default seems to be to load the latest. I want to tell the shortcut to load A2K and then the specific MDB|ADP in question. A. On 7/9/07, Charlotte Foust wrote: > > Are you talking about a "send to" or "open with" shortcut, Arthur? > > Charlotte Foust > From rockysmolin at bchacc.com Mon Jul 9 10:57:54 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 9 Jul 2007 08:57:54 -0700 Subject: [AccessD] Converting to MySql Message-ID: <003201c7c241$e9619de0$0301a8c0@HAL9005> Dear List: I have a request to make my manufacturing package compatible with MySql. I use some bound forms, and a lot of DAO. The app is split FE/BE with linked tables pointing to the BE. I also allow the user to select the BE they want so they can run multiple BEs if desired. What would be involved in doing this? Would it be enough of a rewrite that it would require a separate product? Or can the current product be made 'switchable' between an Access BE and a MySql BE? MTIA Rocky From cfoust at infostatsystems.com Mon Jul 9 11:07:48 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 09:07:48 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> Message-ID: Then I haven't a clue. I use the Send To shortcuts on my machines, so I can specify the precise version of Access to use. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 8:05 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access Open with. Things keep screwing up when I run the app on my box, which has every version of Access loaded since O97, but the default seems to be to load the latest. I want to tell the shortcut to load A2K and then the specific MDB|ADP in question. A. On 7/9/07, Charlotte Foust wrote: > > Are you talking about a "send to" or "open with" shortcut, Arthur? > > Charlotte Foust > -- 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 Jul 9 11:16:01 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 9 Jul 2007 12:16:01 -0400 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> Message-ID: <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so I > can specify the precise version of Access to use. > > Charlotte Foust > From cfoust at infostatsystems.com Mon Jul 9 11:47:58 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 09:47:58 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com><29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> Message-ID: Unless someone else has it at their fingertips, I'll check my laptop tonight. I never bothered to put it on this office machine, since I'm working with a single version of Access here. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 9:16 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so > I can specify the precise version of Access to use. > > Charlotte Foust > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon Jul 9 12:02:32 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 10:02:32 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com><29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com><29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> Message-ID: OK, digging into my memory banks, locate the Send To folder on your machine. It's in different places in different Windows versions, so I can't tell you where. In XP its in the user profile in Documents and Settings and it's a hidden folder. Just add a shortcut with a replaceable parameter for each version of Access you run. Here's an old example: "D:\Program Files\Office2K\Office\MSACCESS.EXE" "%1" Rename each shortcut to indicate the version and they'll show up in your shortcut menus after that. There used to be a registry hack too, but I've lost track of that one. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 09, 2007 9:48 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access Unless someone else has it at their fingertips, I'll check my laptop tonight. I never bothered to put it on this office machine, since I'm working with a single version of Access here. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 9:16 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so > I can specify the precise version of Access to use. > > Charlotte Foust > -- 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 Mon Jul 9 12:17:06 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 09 Jul 2007 19:17:06 +0200 Subject: [AccessD] Current recordset and such Message-ID: Hi Arthur This is where DAO would come in as your speedy and extremely simple tool for your bound updatable form. Skip the stored procedure as well as reloading/requering the form by running code like this: Dim rst As DAO.Recordset Set rst = Forms!frmYourForm.RecordsetClone Debug.Print rst.RecordCount ' Apply your filter. rst.Filter = "Include = True" Set rst = rst.OpenRecordset rst.MoveLast Debug.Print rst.RecordCount With rst .MoveFirst While Not .EOF .Edit !YourField.Value = .Update .MoveNext Wend .Close End With Set rst = Nothing /gustav >>> fuller.artful at gmail.com 09-07-2007 16:08 >>> Hi all, I am writing an Access app designed to replace a commercial app that the client now despises. I am trying to emulate all the cool features that she likes. Among them are a bunch of filter buttons on the form header (such as Age, Status, Balance, Skill Level and so on). All this works nicely. The datasheet form begins by showing all persons (in this case horse-riders). Then filters may be applied to the existing recordset. This is done with code that writes something into Me.Filter and sets FilterOn to True. There is also an option group whose options include Mark All, Find Marked and Unmark all. At the moment the first and third options use a stored procedure, but it addresses the whole table, not the filtered set. That's what I need to address. Perhaps a stored procedure is not the correct way, since a WHERE clause is tough to pass in. So perhaps an alternative is to use the RecordSet object, but I'm not quite sure how. Let's walk through a scenario. 1. Form displays all Riders. 2. User filters the list to include only Riders who are 12 years old. (List drops from 1000 to about 300.) 3. User clicks "Mark All". At the moment, because I'm firing a sproc against the table, all 1000 get marked (there is a column called Marked) rather than the 300 currently selected. I know what I need to do, I'm just shaky on how to manipulate the current recordset. What I need to do is something like this: Dim rs as ADODB.RecordSet bla bla bla Update rs SET Marked = True SET rs = Nothing Me.Requery It's the bla bla bla part that I'm unsure how to code. Next question: At the moment, exerting any of the filter options erases any previous filter. There is a button that clears all filters, but ideally I would like the filter mechanism to be additive. As described above, all I do currently is supply a string to the Filter property (such as "Age = 12" or "Status = 'Active'). I'm thinking that it would be much more powerful if I AND these filter strings. So that if the current filter is "Age = 12" and then I select the Status filter and set it to "Active", the resulting filter will be "Age = 12 and Status = 'Active'. OR is going to be a problem, however, but I can live without it. So, is this simply a case of appending the new filter spec to the old one with an AND in betwixt? I think so, but I thought I'd run it past you experts before coding it. Next question: Does there exist somewhere a list of the commands that appear on the Access menu? I have more than one reason for wanting such a list, but in the immediate context I want to create a button that does "Filter by Form". TIA, Arthur -- From martyconnelly at shaw.ca Mon Jul 9 14:33:05 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Mon, 09 Jul 2007 12:33:05 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> Message-ID: <46928D71.8000101@shaw.ca> Here is how to setup the Open With. 1. Start Windows Explorer, 2. Select Tools and then Folder Options... 3. Click on the File Types Tab 4. Find the MDB file type 5. Click Advanced 6. Chances are there are 2 options. Open in bold font (denoting default) and New. You can pretty much add what you want here. For decompile, 7. Click New 8. Under action type Decompile 9. Under Application used to perform action type the equivalent for your install: "C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" /decompile "%1" 10 Click OK and exit out And wallah! You now right click an mdb and have the context option of decompiling it. But it doesn't stop there. For those of us juggling multiple versions of Access you can setup a right click option to open in each. Eg Open in 97 Open in 2000 Open in XP And make sure the path points to the correct version of access. Look up the paths first and store in notepad you are going to cut and paste them in the New edit Also I hope they have changed the Access 2007 icon otherwise it may look like the Access 2003 icon. Arthur Fuller wrote: >That might do, Charlotte. Tell me how to do that and I'll try it out. > >A. > > >On 7/9/07, Charlotte Foust wrote: > > >>Then I haven't a clue. I use the Send To shortcuts on my machines, so I >>can specify the precise version of Access to use. >> >>Charlotte Foust >> >> >> -- Marty Connelly Victoria, B.C. Canada From miscellany at mvps.org Mon Jul 9 15:16:18 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 10 Jul 2007 08:16:18 +1200 Subject: [AccessD] Converting to MySql In-Reply-To: <003201c7c241$e9619de0$0301a8c0@HAL9005> References: <003201c7c241$e9619de0$0301a8c0@HAL9005> Message-ID: <46929792.5040101@mvps.org> Rocky, I have not done this from the point of view of MySQL database as either/or to Jet database. But I have a couple of apps that link to MySQL tables *and* Jet tables, and transfer data one to the other via Update queries or Append queries etc. The link to the MySQL database is via ODBC, so you need the appropriate MySQL ODBC driver installed, and the creation of a DSN (well, I think you can do it dsn-less as well). So I imagine what you are trying would be reasonably easy. If the user chooses the MySQL BE, then delete the linked Jet tables, and create the links to the MySQL tables. Here is a sample of the code I have used to link to MySQL talbes: Dim dbs As DAO.Database Dim tdf As DAO.TableDef Dim tblName As String Dim srcTblName As String Dim Conn As String Set dbs = CurrentDb tblName = "NameYouWantTheTableToHaveLocally" srcTblName = "NameOfTheMySQLTableToLinkTo" Conn = "ODBC;DATABASE=NameOfMySQLDatabase;DESCRIPTION=description;DSN=NameOfDSN;OPTION=0;PORT=3306;SERVER=NameOfServer;;TABLE=NameOfTheMySQLTableToLinkTo" Set tdf = dbs.CreateTableDef(tblName) tdf.SourceTableName = srcTblName tdf.Connect = Conn dbs.TableDefs.Append tdf dbs.TableDefs.Refresh I guess one potential hiccup could be the use of non-corresponding data types. Regards Steve Rocky Smolin at Beach Access Software wrote: > Dear List: > > I have a request to make my manufacturing package compatible with MySql. I > use some bound forms, and a lot of DAO. The app is split FE/BE with linked > tables pointing to the BE. I also allow the user to select the BE they want > so they can run multiple BEs if desired. > > What would be involved in doing this? Would it be enough of a rewrite that > it would require a separate product? Or can the current product be made > 'switchable' between an Access BE and a MySql BE? From rockysmolin at bchacc.com Mon Jul 9 18:18:57 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 9 Jul 2007 16:18:57 -0700 Subject: [AccessD] Converting to MySql In-Reply-To: <46929792.5040101@mvps.org> Message-ID: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> Steve: Thanks for the snip. Raises a few more questions than it answers. Like how does the user know the Server Name. San with the DNS. And I suppose I'd have to prompt for those values. Most of my users are not very adept with computers, although in a company using MySql would I expect to find a DBA on staff? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Monday, July 09, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Converting to MySql Rocky, I have not done this from the point of view of MySQL database as either/or to Jet database. But I have a couple of apps that link to MySQL tables *and* Jet tables, and transfer data one to the other via Update queries or Append queries etc. The link to the MySQL database is via ODBC, so you need the appropriate MySQL ODBC driver installed, and the creation of a DSN (well, I think you can do it dsn-less as well). So I imagine what you are trying would be reasonably easy. If the user chooses the MySQL BE, then delete the linked Jet tables, and create the links to the MySQL tables. Here is a sample of the code I have used to link to MySQL talbes: Dim dbs As DAO.Database Dim tdf As DAO.TableDef Dim tblName As String Dim srcTblName As String Dim Conn As String Set dbs = CurrentDb tblName = "NameYouWantTheTableToHaveLocally" srcTblName = "NameOfTheMySQLTableToLinkTo" Conn = "ODBC;DATABASE=NameOfMySQLDatabase;DESCRIPTION=description;DSN=NameOfDSN;OPT ION=0;PORT=3306;SERVER=NameOfServer;;TABLE=NameOfTheMySQLTableToLinkTo" Set tdf = dbs.CreateTableDef(tblName) tdf.SourceTableName = srcTblName tdf.Connect = Conn dbs.TableDefs.Append tdf dbs.TableDefs.Refresh I guess one potential hiccup could be the use of non-corresponding data types. Regards Steve Rocky Smolin at Beach Access Software wrote: > Dear List: > > I have a request to make my manufacturing package compatible with > MySql. I use some bound forms, and a lot of DAO. The app is split > FE/BE with linked tables pointing to the BE. I also allow the user to > select the BE they want so they can run multiple BEs if desired. > > What would be involved in doing this? Would it be enough of a rewrite > that it would require a separate product? Or can the current product > be made 'switchable' between an Access BE and a MySql BE? -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM From greg at worthey.com Mon Jul 9 18:49:20 2007 From: greg at worthey.com (Greg Worthey) Date: Mon, 9 Jul 2007 16:49:20 -0700 Subject: [AccessD] MS Sql In-Reply-To: Message-ID: <000001c7c283$c95eb540$1701a8c0@fb2a618> Rocky, I've worked with mysql. Just use myodbc driver to connect to backend, like you would link to ms sql server. Pretty easy to set up. To make it switchable, I haven't tried that, but I think that wouldn't be too hard. Greg Worthey Worthey Solutions www.worthey.com -----Original Message----- Message: 17 Date: Mon, 9 Jul 2007 08:57:54 -0700 From: "Rocky Smolin at Beach Access Software" Subject: [AccessD] Converting to MySql To: "'Access Developers discussion and problem solving'" Message-ID: <003201c7c241$e9619de0$0301a8c0 at HAL9005> Content-Type: text/plain; charset="US-ASCII" Dear List: I have a request to make my manufacturing package compatible with MySql. I use some bound forms, and a lot of DAO. The app is split FE/BE with linked tables pointing to the BE. I also allow the user to select the BE they want so they can run multiple BEs if desired. What would be involved in doing this? Would it be enough of a rewrite that it would require a separate product? Or can the current product be made 'switchable' between an Access BE and a MySql BE? MTIA Rocky ------------------------------ Message: 18 Date: Mon, 9 Jul 2007 09:07:48 -0700 From: "Charlotte Foust" Subject: Re: [AccessD] Syntax for loading a specific version of Access To: "Access Developers discussion and problem solving" Message-ID: Content-Type: text/plain; charset="us-ascii" Then I haven't a clue. I use the Send To shortcuts on my machines, so I can specify the precise version of Access to use. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 8:05 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access Open with. Things keep screwing up when I run the app on my box, which has every version of Access loaded since O97, but the default seems to be to load the latest. I want to tell the shortcut to load A2K and then the specific MDB|ADP in question. A. On 7/9/07, Charlotte Foust wrote: > > Are you talking about a "send to" or "open with" shortcut, Arthur? > > Charlotte Foust > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com ------------------------------ Message: 19 Date: Mon, 9 Jul 2007 12:16:01 -0400 From: "Arthur Fuller" Subject: Re: [AccessD] Syntax for loading a specific version of Access To: "Access Developers discussion and problem solving" Message-ID: <29f585dd0707090916y50b52de2t4182ec63e4541912 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so I > can specify the precise version of Access to use. > > Charlotte Foust > ------------------------------ Message: 20 Date: Mon, 9 Jul 2007 09:47:58 -0700 From: "Charlotte Foust" Subject: Re: [AccessD] Syntax for loading a specific version of Access To: "Access Developers discussion and problem solving" Message-ID: Content-Type: text/plain; charset="us-ascii" Unless someone else has it at their fingertips, I'll check my laptop tonight. I never bothered to put it on this office machine, since I'm working with a single version of Access here. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 9:16 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so > I can specify the precise version of Access to use. > > Charlotte Foust > -- 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 End of AccessD Digest, Vol 53, Issue 15 *************************************** From miscellany at mvps.org Mon Jul 9 18:53:22 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 10 Jul 2007 11:53:22 +1200 Subject: [AccessD] Converting to MySql In-Reply-To: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> References: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> Message-ID: <4692CA72.2000300@mvps.org> Hi Rocky, I can't advise on doing this without a DSN, as I have never tried it. If you use a DSN, is has to be created on the PC. You would get the MySQL ODBC driver, and install it on the PC. This driver is free, and easily found on the internet. On a Windows XP PC, you create the DSN via: Start Control Panel Administrative Tools Data Sources (ODBC) (tab) System DSN Add... MySQL ODBC 3.51 Driver I would say that yes, this would probably need to be done by an admin, or on advice by someone who knows what to do. You need the name of the server. In my case, the MySQL databases are on hosted web servers, and I got the details of server name, user, password, and database name, from the web hosting service. Your situation may be different, in which case I am unable to advise, I've only done this a couple of times, it was easy and works sweet. Regards Steve Rocky Smolin at Beach Access Software wrote: > Steve: > > Thanks for the snip. Raises a few more questions than it answers. Like how > does the user know the Server Name. San with the DNS. And I suppose I'd > have to prompt for those values. > > Most of my users are not very adept with computers, although in a company > using MySql would I expect to find a DBA on staff? > From miscellany at mvps.org Mon Jul 9 18:56:06 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 10 Jul 2007 11:56:06 +1200 Subject: [AccessD] Converting to MySql In-Reply-To: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> References: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> Message-ID: <4692CB16.6070808@mvps.org> Rocky, Rocky Smolin at Beach Access Software wrote: > ... I suppose I'd > have to prompt for those values. No, once you have the DSN set up, you can hard-wire these values into your code. Regards Steve From rockysmolin at bchacc.com Mon Jul 9 19:14:44 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 9 Jul 2007 17:14:44 -0700 Subject: [AccessD] Converting to MySql In-Reply-To: <4692CB16.6070808@mvps.org> Message-ID: <005501c7c287$51b3cd60$0301a8c0@HAL9005> This is a distributable product. Do you think it would be better to force the end user to use my hard-wired DSN or allow them to create their own and prompt? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Monday, July 09, 2007 4:56 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Converting to MySql Rocky, Rocky Smolin at Beach Access Software wrote: > ... I suppose I'd > have to prompt for those values. No, once you have the DSN set up, you can hard-wire these values into your code. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM From bhjohnson at verizon.net Mon Jul 9 19:18:51 2007 From: bhjohnson at verizon.net (Bruce H. Johnson) Date: Mon, 09 Jul 2007 17:18:51 -0700 Subject: [AccessD] Converting to MySql In-Reply-To: <4692CA72.2000300@mvps.org> References: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> <4692CA72.2000300@mvps.org> Message-ID: <001b01c7c287$e4cbbf40$0201a8c0@HALSR> If you do an install on the client's PC for the front end, you can easily make the DNS entries as part of it. Most of it is registry entries; take a working one and duplicate it. I did a set of DSNs for a local Access database, an AS400 and an SQL server and was able to change the SQL and AS400 DSNs on the fly to flip between production and testing databases. Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Monday, July 09, 2007 4:53 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Converting to MySql Hi Rocky, I can't advise on doing this without a DSN, as I have never tried it. If you use a DSN, is has to be created on the PC. You would get the MySQL ODBC driver, and install it on the PC. This driver is free, and easily found on the internet. On a Windows XP PC, you create the DSN via: Start Control Panel Administrative Tools Data Sources (ODBC) (tab) System DSN Add... MySQL ODBC 3.51 Driver I would say that yes, this would probably need to be done by an admin, or on advice by someone who knows what to do. You need the name of the server. In my case, the MySQL databases are on hosted web servers, and I got the details of server name, user, password, and database name, from the web hosting service. Your situation may be different, in which case I am unable to advise, I've only done this a couple of times, it was easy and works sweet. Regards Steve Rocky Smolin at Beach Access Software wrote: > Steve: > > Thanks for the snip. Raises a few more questions than it answers. Like how > does the user know the Server Name. San with the DNS. And I suppose I'd > have to prompt for those values. > > Most of my users are not very adept with computers, although in a company > using MySql would I expect to find a DBA on staff? > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM From jwelz at hotmail.com Mon Jul 9 19:25:38 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Mon, 09 Jul 2007 18:25:38 -0600 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: I don't understand the comment about 'goofiness' with callbacks and debug I use callbacks more often than not and have never had a problem with breaking into code. I've said before what I say again below, and it needs to be repeated. My concern with unbound forms is the scenario where two users open the same record and each performs an edit. Generally, unbound edits are written when the form closed or unloads. In such a case, the last user to close 'wins' and the first user's eits are lost without notice. In the environments where I have worked, we frequently have multiple users working in a single record. User 'A' will open the record to update an address. User 'B' will open the record to update a contract value field. User 'B' will close the record and his edit is writen to the table. User 'A' answers the phone and closes the record a moment later and the database is updated with the current unbound form data. The record has the updated address but the change to the contract value is lost and no one is warned. Sure you can write code to handle the situation. For example, you could update only edited fields and the overwrite will only happen if two users concurrently edit the same field to different values. Or you could add an edit flag and update it anytime a user has a pending edit and clear it when the record closes. But I believe Drew said earlier that since it's a Jet BE, there is no difference bound or unbound in regard to locking. With a bound form, you can get a notification that another user has edited the record and gives 'A' the option to abandon the edit. My users see this message with a degree of regularity and they have been taught always to drop their edits, reopen the record and then redo any required edits. I have seen many unbound databases created by reasonably competent Access developers who blithely ignore this issue. They don't mention the additional things that need to be done in order to ensure data integrity. I am not adverse to unbound forms and use them where appropriate. If a person is in a web driven database where a user may have a personal shopping cart and need to log in to access his cart, no problem with unbound. If you take appropriate steps to ensure the integirty of the data, no problem. My primary reason for working unbound has been the formatting limitations of bound controls in continuous forms and my environment has never permitted 3rd party controls. I've heard reference to 'boundaries' or limitations of bound forms but still manage to use them without compromising the user interface. You can even populate a bound form with a series of values that did not exist in any table. Some people assume that a bound form contains as many records as some table to which a form is bound, but all of my parent forms are populated by a single record determined by a primary key parameter. The recordset is determined in the open event and the recordsource property is empty. It is just as fast as unbound, and faster than unbound that includes the setting of edit flags. I have 47 concurrent users today and among the only unbound forms I use today are a few that allow drag and drop of categories of employees (4 categories, 4 colours in 4 columns, each its own subform) onto and from a list of projects, and the dragged employees drop in to a subform of projects containing sublists of employees that retain their formatting where dropped. I counln't figure out how to intersperse the types of records with their various colours in a bound form. And of course forms for search, report selection, navigation, calculations, calendars and such ancilliary forms that do not need to update their own values. 47 users, Access 2003, Access 2000 format, nearly entirely bound and no reports of data conflicts that shouldn't be reported. I anticipate more users in the coming months and see no difference between the bound and unbound approach in terms of locked data pages, indexes or corruptions because my recordsets are tiny compared to the tables and rarely, but occasionally, involve concurrent edits. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Drew Wutka" > >But Access is just as well suited for unbound solutions too. The only >exception to that rule is it's goofiness with callback routines. (Can't >go into debug if you have a callback routine ANYWHERE. Goes haywire). > >Drew _________________________________________________________________ http://liveearth.msn.com From DWUTKA at Marlow.com Mon Jul 9 20:26:18 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 9 Jul 2007 20:26:18 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: A little clarification on the 'callback' issue. I am NOT referring to the callback capabilities of Access list and combo boxes. What I am referring too is API call backs. For example, if you want to enumerate all of the windows on your machine, you call the EnumWindows API, and in that call, you give it the address of your callback routine, using AddressOf. In 97, there was not a native AddressOf function, there was one available on the web that worked great. In 2000 and later (with VBA being a subset of VB 6, instead of VB 5), AddressOf became available as a native function. However, if you have a function that uses this, and it has run (doesn't need to still be running), if you go into the code in debug mode.....zap, everything locks up. I know that was the case in 2000, and I'm 99% sure it does the same thing in 2003 (never had 2002). As for what you posted about simultaneous data 'editing', here's my take on this. I know there are times when an application may run into this, but with good developing, this situation can be very easily avoided. I can't think of a single application I have written that would have two people updating the same record. First, I normalize out the data. So, in your example, one person may be changing an address, while another edits a 'contract value' field, in both cases, the users would be using different tables. Also, when I have a class structure built, if I am even remotely worried that two people can edit a record at the same time, I have the class only update the fields that have been changed. That is something you can't do with a bound found. So if one person changes someone's first name, and one person changes someone's last name, my class will only change the first name for the first person, and last name for the second person. Smooth as silk. In that same process, data integrity can be checked, so if there is a clash on the exact same field, it can warn the user. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Monday, July 09, 2007 7:26 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? I don't understand the comment about 'goofiness' with callbacks and debug I use callbacks more often than not and have never had a problem with breaking into code. I've said before what I say again below, and it needs to be repeated. My concern with unbound forms is the scenario where two users open the same record and each performs an edit. Generally, unbound edits are written when the form closed or unloads. In such a case, the last user to close 'wins' and the first user's eits are lost without notice. In the environments where I have worked, we frequently have multiple users working in a single record. User 'A' will open the record to update an address. User 'B' will open the record to update a contract value field. User 'B' will close the record and his edit is writen to the table. User 'A' answers the phone and closes the record a moment later and the database is updated with the current unbound form data. The record has the updated address but the change to the contract value is lost and no one is warned. Sure you can write code to handle the situation. For example, you could update only edited fields and the overwrite will only happen if two users concurrently edit the same field to different values. Or you could add an edit flag and update it anytime a user has a pending edit and clear it when the record closes. But I believe Drew said earlier that since it's a Jet BE, there is no difference bound or unbound in regard to locking. With a bound form, you can get a notification that another user has edited the record and gives 'A' the option to abandon the edit. My users see this message with a degree of regularity and they have been taught always to drop their edits, reopen the record and then redo any required edits. I have seen many unbound databases created by reasonably competent Access developers who blithely ignore this issue. They don't mention the additional things that need to be done in order to ensure data integrity. I am not adverse to unbound forms and use them where appropriate. If a person is in a web driven database where a user may have a personal shopping cart and need to log in to access his cart, no problem with unbound. If you take appropriate steps to ensure the integirty of the data, no problem. My primary reason for working unbound has been the formatting limitations of bound controls in continuous forms and my environment has never permitted 3rd party controls. I've heard reference to 'boundaries' or limitations of bound forms but still manage to use them without compromising the user interface. You can even populate a bound form with a series of values that did not exist in any table. Some people assume that a bound form contains as many records as some table to which a form is bound, but all of my parent forms are populated by a single record determined by a primary key parameter. The recordset is determined in the open event and the recordsource property is empty. It is just as fast as unbound, and faster than unbound that includes the setting of edit flags. I have 47 concurrent users today and among the only unbound forms I use today are a few that allow drag and drop of categories of employees (4 categories, 4 colours in 4 columns, each its own subform) onto and from a list of projects, and the dragged employees drop in to a subform of projects containing sublists of employees that retain their formatting where dropped. I counln't figure out how to intersperse the types of records with their various colours in a bound form. And of course forms for search, report selection, navigation, calculations, calendars and such ancilliary forms that do not need to update their own values. 47 users, Access 2003, Access 2000 format, nearly entirely bound and no reports of data conflicts that shouldn't be reported. I anticipate more users in the coming months and see no difference between the bound and unbound approach in terms of locked data pages, indexes or corruptions because my recordsets are tiny compared to the tables and rarely, but occasionally, involve concurrent edits. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Drew Wutka" > >But Access is just as well suited for unbound solutions too. The only >exception to that rule is it's goofiness with callback routines. (Can't >go into debug if you have a callback routine ANYWHERE. Goes haywire). > >Drew _________________________________________________________________ http://liveearth.msn.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwelz at hotmail.com Mon Jul 9 22:02:03 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Mon, 09 Jul 2007 21:02:03 -0600 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Drew: I'm familiar with the 'use at your own risk' 'AddressOf' function since the days of Access97 at 'The Access Web' of Dev Ashish, but this is not the sense in which most Access programmers ordinarily are familiar with callback functions. Of couse the whole callback thing has little bearing on the initial question about performance tips or on the question of bound or unbound. I still haven't seen an explanation of how unbound is inherently faster than bound. I've heard discussion about being able to do certain kinds of things unbound that can't be done bound and have given a couple examples myslef. I still don't see how it provides additional performance so don't understand in what sense proposing it is an answer to the question. There is also little sense in making the assumption that everyone is a good developer and is aware of the issues that may come with losing record locking. It is irresponsible to say that jet looks after record locking, no difference, bound or unbound. You can't advocate something that will undoubtedly hurt people if you don't mention the caveats. What constitutes 'good developing' depends on a number of factors. In terms of performance, a degree of denormalization may be good thing as it can cut down the number of joins to be processed. In the database from which I drew the contract value/address example, we never had identical addresses for multiple projects. Sure we have addresses for various kinds of entities and they could be stored in a single table, but placing all the addresses in a separate table would have resulted in a table with a much larger number of records that would have to be hit to populate a record fore each kind of entity. Querying for any kind of related record by address, that would be possible by normalizing, was of no advantage in this database. Worse yet, the physical address of a project never changes, but if you join that address to a company and some bright bulb changes the address of the company when it moves rather than adding a new address and 'deactivating' or date ranging the validity of the address, the edit to the address changes the AddressOf (pun intended) the project. In the example I gave, both the contract value and the addresses were appropriate characteristics of the project. I've also gotten performance gains out of mapping data to bit flags; another normalization no no. Callback functions are very useful to me in cases where I do use foreign keys as I frequently fill a combo or list from an array and avoid a hit on the database. In addition to what Colby calls JIT sub forms, together with limiting the data to only needed data, you can do the same thing with combos, displaying a text value in a delimited list and converting to an SQL rowsource on GotFocus provided you store the text value in the table together with the FK. One of the slower built in functions in Access is the CurrentDb function and it can crawl when called in a loop. I use a function that keeps a static variable that points to a database object and returns a reference to that object. The database for which this question was asked is large in terms of numbers of objects. CurrentDb forces a refresh of all the database objects so I use an optional parameter that allows me to specify should I need to refresh the collection. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Drew Wutka" > >A little clarification on the 'callback' issue. I am NOT referring to the >callback capabilities of Access list and combo boxes. What I am referring >too is API call backs. For example, if you want to enumerate all of the >windows on your machine, you call the EnumWindows API, and in that call, >you give it the address of your callback routine, using AddressOf. In 97, >there was not a native AddressOf function, there was one available on the >web that worked great. In 2000 and later (with VBA being a subset of VB 6, >instead of VB 5), AddressOf became available as a native function. > >However, if you have a function that uses this, and it has run (doesn't >need to still be running), if you go into the code in debug mode.....zap, >everything locks up. I know that was the case in 2000, and I'm 99% sure it >does the same thing in 2003 (never had 2002). > >As for what you posted about simultaneous data 'editing', here's my take on >this. I know there are times when an application may run into this, but >with good developing, this situation can be very easily avoided. I can't >think of a single application I have written that would have two people >updating the same record. First, I normalize out the data. So, in your >example, one person may be changing an address, while another edits a >'contract value' field, in both cases, the users would be using different >tables. Also, when I have a class structure built, if I am even remotely >worried that two people can edit a record at the same time, I have the >class only update the fields that have been changed. That is something you >can't do with a bound found. So if one person changes someone's first >name, and one person changes someone's last name, my class will only change >the first name for the first person, and last name for the second person. >Smooth as silk. In that same process, data integrity can be checked, so if >there is a clash on the exact same field, it can warn the user. > >Drew > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Monday, July 09, 2007 7:26 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Performance tips anyone? > >I don't understand the comment about 'goofiness' with callbacks and debug >I >use callbacks more often than not and have never had a problem with >breaking >into code. > >I've said before what I say again below, and it needs to be repeated. > >My concern with unbound forms is the scenario where two users open the same >record and each performs an edit. Generally, unbound edits are written >when >the form closed or unloads. In such a case, the last user to close 'wins' >and the first user's eits are lost without notice. In the environments >where I have worked, we frequently have multiple users working in a single >record. User 'A' will open the record to update an address. User 'B' will >open the record to update a contract value field. User 'B' will close the >record and his edit is writen to the table. User 'A' answers the phone and >closes the record a moment later and the database is updated with the >current unbound form data. The record has the updated address but the >change to the contract value is lost and no one is warned. > >Sure you can write code to handle the situation. For example, you could >update only edited fields and the overwrite will only happen if two users >concurrently edit the same field to different values. Or you could add an >edit flag and update it anytime a user has a pending edit and clear it when >the record closes. But I believe Drew said earlier that since it's a Jet >BE, there is no difference bound or unbound in regard to locking. With a >bound form, you can get a notification that another user has edited the >record and gives 'A' the option to abandon the edit. My users see this >message with a degree of regularity and they have been taught always to >drop >their edits, reopen the record and then redo any required edits. > >I have seen many unbound databases created by reasonably competent Access >developers who blithely ignore this issue. They don't mention the >additional things that need to be done in order to ensure data integrity. >I >am not adverse to unbound forms and use them where appropriate. If a >person >is in a web driven database where a user may have a personal shopping cart >and need to log in to access his cart, no problem with unbound. If you >take >appropriate steps to ensure the integirty of the data, no problem. > >My primary reason for working unbound has been the formatting limitations >of >bound controls in continuous forms and my environment has never permitted >3rd party controls. I've heard reference to 'boundaries' or limitations of >bound forms but still manage to use them without compromising the user >interface. You can even populate a bound form with a series of values that >did not exist in any table. > >Some people assume that a bound form contains as many records as some table >to which a form is bound, but all of my parent forms are populated by a >single record determined by a primary key parameter. The recordset is >determined in the open event and the recordsource property is empty. It is >just as fast as unbound, and faster than unbound that includes the setting >of edit flags. I have 47 concurrent users today and among the only unbound >forms I use today are a few that allow drag and drop of categories of >employees (4 categories, 4 colours in 4 columns, each its own subform) onto >and from a list of projects, and the dragged employees drop in to a subform >of projects containing sublists of employees that retain their formatting >where dropped. I counln't figure out how to intersperse the types of >records with their various colours in a bound form. And of course forms >for >search, report selection, navigation, calculations, calendars and such >ancilliary forms that do not need to update their own values. > >47 users, Access 2003, Access 2000 format, nearly entirely bound and no >reports of data conflicts that shouldn't be reported. I anticipate more >users in the coming months and see no difference between the bound and >unbound approach in terms of locked data pages, indexes or corruptions >because my recordsets are tiny compared to the tables and rarely, but >occasionally, involve concurrent edits. > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > > > > > > >From: "Drew Wutka" > > > >But Access is just as well suited for unbound solutions too. The only > >exception to that rule is it's goofiness with callback routines. (Can't > >go into debug if you have a callback routine ANYWHERE. Goes haywire). > > > >Drew _________________________________________________________________ New Windows Live Hotmail is here. Upgrade for free and get a better look. www.newhotmail.ca?icid=WLHMENCA150 From jwcolby at colbyconsulting.com Mon Jul 9 23:18:44 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 10 Jul 2007 00:18:44 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070710041911.A6797BE11@smtp-auth.no-ip.com> Hey Jurgen, long time no see. Welcome back. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Monday, July 09, 2007 8:26 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? I don't understand the comment about 'goofiness' with callbacks and debug I use callbacks more often than not and have never had a problem with breaking into code. I've said before what I say again below, and it needs to be repeated. My concern with unbound forms is the scenario where two users open the same record and each performs an edit. Generally, unbound edits are written when the form closed or unloads. In such a case, the last user to close 'wins' and the first user's eits are lost without notice. In the environments where I have worked, we frequently have multiple users working in a single record. User 'A' will open the record to update an address. User 'B' will open the record to update a contract value field. User 'B' will close the record and his edit is writen to the table. User 'A' answers the phone and closes the record a moment later and the database is updated with the current unbound form data. The record has the updated address but the change to the contract value is lost and no one is warned. Sure you can write code to handle the situation. For example, you could update only edited fields and the overwrite will only happen if two users concurrently edit the same field to different values. Or you could add an edit flag and update it anytime a user has a pending edit and clear it when the record closes. But I believe Drew said earlier that since it's a Jet BE, there is no difference bound or unbound in regard to locking. With a bound form, you can get a notification that another user has edited the record and gives 'A' the option to abandon the edit. My users see this message with a degree of regularity and they have been taught always to drop their edits, reopen the record and then redo any required edits. I have seen many unbound databases created by reasonably competent Access developers who blithely ignore this issue. They don't mention the additional things that need to be done in order to ensure data integrity. I am not adverse to unbound forms and use them where appropriate. If a person is in a web driven database where a user may have a personal shopping cart and need to log in to access his cart, no problem with unbound. If you take appropriate steps to ensure the integirty of the data, no problem. My primary reason for working unbound has been the formatting limitations of bound controls in continuous forms and my environment has never permitted 3rd party controls. I've heard reference to 'boundaries' or limitations of bound forms but still manage to use them without compromising the user interface. You can even populate a bound form with a series of values that did not exist in any table. Some people assume that a bound form contains as many records as some table to which a form is bound, but all of my parent forms are populated by a single record determined by a primary key parameter. The recordset is determined in the open event and the recordsource property is empty. It is just as fast as unbound, and faster than unbound that includes the setting of edit flags. I have 47 concurrent users today and among the only unbound forms I use today are a few that allow drag and drop of categories of employees (4 categories, 4 colours in 4 columns, each its own subform) onto and from a list of projects, and the dragged employees drop in to a subform of projects containing sublists of employees that retain their formatting where dropped. I counln't figure out how to intersperse the types of records with their various colours in a bound form. And of course forms for search, report selection, navigation, calculations, calendars and such ancilliary forms that do not need to update their own values. 47 users, Access 2003, Access 2000 format, nearly entirely bound and no reports of data conflicts that shouldn't be reported. I anticipate more users in the coming months and see no difference between the bound and unbound approach in terms of locked data pages, indexes or corruptions because my recordsets are tiny compared to the tables and rarely, but occasionally, involve concurrent edits. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Drew Wutka" > >But Access is just as well suited for unbound solutions too. The only >exception to that rule is it's goofiness with callback routines. (Can't >go into debug if you have a callback routine ANYWHERE. Goes haywire). > >Drew _________________________________________________________________ http://liveearth.msn.com From miscellany at mvps.org Mon Jul 9 23:44:43 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 10 Jul 2007 16:44:43 +1200 Subject: [AccessD] Converting to MySql In-Reply-To: <005501c7c287$51b3cd60$0301a8c0@HAL9005> References: <005501c7c287$51b3cd60$0301a8c0@HAL9005> Message-ID: <46930EBB.3030303@mvps.org> Rocky, I don't think prompting them for the DSN parameters would be too good. It sounds like Bruce has got some clues about creating a DSN as part of your application installation. You would also have to include the installation of the ODBC driver as part of your installation as well. So perhaps you could explore further down that track, and maybe Bruce can provide some more specifics. Otherwise, you would have to give instructions to them to set up the DSN themselves - and those instructions would include them giving the same name etc to the DSN as the one you used. But then, I suppose the location of the MySQL database would be different for each user, so maybe you would have to set up a process for them to enter this in (server, password), and store it in a table, and get your code to refer to this. Sorry, I didn't realise it was a distributed application. This seems such a specific requirement, so I assumed it was part of a customised solution for a particular user. Regards Steve Rocky Smolin at Beach Access Software wrote: > This is a distributable product. Do you think it would be better to force > the end user to use my hard-wired DSN or allow them to create their own and > prompt? From adtp at airtelbroadband.in Mon Jul 9 23:04:54 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Tue, 10 Jul 2007 09:34:54 +0530 Subject: [AccessD] Access Reports rinting accross References: <0JKV00CB8JU1S4G9@l-daemon> Message-ID: <01d701c7c2b2$1b1fbae0$5357a27a@pcadt> You are most welcome Jim! A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Monday, July 09, 2007 00:43 Subject: Re: [AccessD] Access Reports rinting accross Hi A. D. Tejal: A very eloquent solution. :-) A subreport of course can be used and I have not ruled out that option yet... One day Access reporting may provide the ability to set columns per Group Heading. Until then this will have to be the appropriate solution. Thanks you Jim << SNIPPED >> From fuller.artful at gmail.com Tue Jul 10 04:34:57 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 10 Jul 2007 05:34:57 -0400 Subject: [AccessD] Update the current recordset Message-ID: <29f585dd0707100234m5712b530u8c899514ff19d6b4@mail.gmail.com> I have continuous form that is a subform. On the parent form's header are some buttons and combo boxes that are used to filter the continuous subform. This all works fine. There's an option group that contains "Mark All", "Find Marked" and "Unmark All" options. When I first wrote it, "Mark All" applied to all the records in the table but I want it to be smarter than that. To wit, when you filter, say, by age, and select 20 as the age, then only a small subset of the total rows are shown. I want "Mark all" to apply to the subset not the whole table. The Marking is done using a column in the table called Marked. The first version invokes a stored procedure to mark and unmark all the records and it is amazingly quick. I thought that if I used the recordsetclone it would present only the filtered subset, but apparently that doesn't work. Here's the code I wrote: Sub MarkAllRecords() Dim rst As ADODB.Recordset With Me Set rst = .Riders_Browser_fsub.Form.RecordsetClone Do While Not rst.EOF rst.Fields("Marked") = -1 rst.Update Debug.Print rst("RiderID"), rst("Marked") rst.MoveNext Loop Debug.Print rst.RecordCount & " rows changed." rst.Close Set rst = Nothing End With End Sub This marks all the records in the table, not the filtered subset. How do I get a handle on just the subset? I suppose that I could use a SQL statement that specifies the current filter, which I shall try now, but I'm wondering why the code above doesn't work -- or rather, how to make it work. TIA, Arthur From Gustav at cactus.dk Tue Jul 10 05:48:30 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Tue, 10 Jul 2007 12:48:30 +0200 Subject: [AccessD] Update the current recordset Message-ID: Hi Arthur > This marks all the records in the table, not the filtered subset. > How do I get a handle on just the subset? Didn't you study the gems of my previous posting? The code included does exactly that: Set rst = Forms!frmYourForm.RecordsetClone Debug.Print rst.RecordCount ' Apply your filter. rst.Filter = "Include = True" Set rst = rst.OpenRecordset rst.MoveLast Debug.Print rst.RecordCount /gustav >>> fuller.artful at gmail.com 10-07-2007 11:34 >>> I have continuous form that is a subform. On the parent form's header are some buttons and combo boxes that are used to filter the continuous subform. This all works fine. There's an option group that contains "Mark All", "Find Marked" and "Unmark All" options. When I first wrote it, "Mark All" applied to all the records in the table but I want it to be smarter than that. To wit, when you filter, say, by age, and select 20 as the age, then only a small subset of the total rows are shown. I want "Mark all" to apply to the subset not the whole table. The Marking is done using a column in the table called Marked. The first version invokes a stored procedure to mark and unmark all the records and it is amazingly quick. I thought that if I used the recordsetclone it would present only the filtered subset, but apparently that doesn't work. Here's the code I wrote: Sub MarkAllRecords() Dim rst As ADODB.Recordset With Me Set rst = .Riders_Browser_fsub.Form.RecordsetClone Do While Not rst.EOF rst.Fields("Marked") = -1 rst.Update Debug.Print rst("RiderID"), rst("Marked") rst.MoveNext Loop Debug.Print rst.RecordCount & " rows changed." rst.Close Set rst = Nothing End With End Sub This marks all the records in the table, not the filtered subset. How do I get a handle on just the subset? I suppose that I could use a SQL statement that specifies the current filter, which I shall try now, but I'm wondering why the code above doesn't work -- or rather, how to make it work. TIA, Arthur From accessd666 at yahoo.com Tue Jul 10 06:37:42 2007 From: accessd666 at yahoo.com (Sad Der) Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) Subject: [AccessD] Upsize wizard => Queries Message-ID: <460545.53873.qm@web31611.mail.mud.yahoo.com> Hi group, Using the upgrade wizard I can migrate the tables and data in a couple of minutes to SQL Server. (Action) Queries are not migrated. Does anybody know of a tool that migrates queries to sql server views and/or sp's? TIA!!!! Regards, Sander ____________________________________________________________________________________ Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php From fuller.artful at gmail.com Tue Jul 10 07:26:00 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 10 Jul 2007 08:26:00 -0400 Subject: [AccessD] Writing to the Access status bar Message-ID: <29f585dd0707100526p316620b7i7e7dece2f48a9266@mail.gmail.com> Can someone point me in the right direction to write a message to the status bar? I've done it before but forgotten how. I know that it has something to do with acSysCmdSetStatus but that's all I can remember. TIA, Arthur From jwcolby at colbyconsulting.com Tue Jul 10 07:36:22 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 10 Jul 2007 08:36:22 -0400 Subject: [AccessD] Update the current recordset In-Reply-To: <29f585dd0707100234m5712b530u8c899514ff19d6b4@mail.gmail.com> Message-ID: <20070710123624.52451BDAE@smtp-auth.no-ip.com> First of all, using a field called "Marked" may cause multi-user issues. It definitely will in a bound form, because the records are live linked back to the table. If another user clears the marked flag for a record the current user is looking at... John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, July 10, 2007 5:35 AM To: Access Developers discussion and problem solving Subject: [AccessD] Update the current recordset I have continuous form that is a subform. On the parent form's header are some buttons and combo boxes that are used to filter the continuous subform. This all works fine. There's an option group that contains "Mark All", "Find Marked" and "Unmark All" options. When I first wrote it, "Mark All" applied to all the records in the table but I want it to be smarter than that. To wit, when you filter, say, by age, and select 20 as the age, then only a small subset of the total rows are shown. I want "Mark all" to apply to the subset not the whole table. The Marking is done using a column in the table called Marked. The first version invokes a stored procedure to mark and unmark all the records and it is amazingly quick. I thought that if I used the recordsetclone it would present only the filtered subset, but apparently that doesn't work. Here's the code I wrote: Sub MarkAllRecords() Dim rst As ADODB.Recordset With Me Set rst = .Riders_Browser_fsub.Form.RecordsetClone Do While Not rst.EOF rst.Fields("Marked") = -1 rst.Update Debug.Print rst("RiderID"), rst("Marked") rst.MoveNext Loop Debug.Print rst.RecordCount & " rows changed." rst.Close Set rst = Nothing End With End Sub This marks all the records in the table, not the filtered subset. How do I get a handle on just the subset? I suppose that I could use a SQL statement that specifies the current filter, which I shall try now, but I'm wondering why the code above doesn't work -- or rather, how to make it work. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd666 at yahoo.com Tue Jul 10 08:05:18 2007 From: accessd666 at yahoo.com (Sad Der) Date: Tue, 10 Jul 2007 06:05:18 -0700 (PDT) Subject: [AccessD] Writing to the Access status bar In-Reply-To: <29f585dd0707100526p316620b7i7e7dece2f48a9266@mail.gmail.com> Message-ID: <671421.18251.qm@web31606.mail.mud.yahoo.com> Hi Arthur, SysCmd acSysCmdSetStatus, "Elapsed Time: " & _ lngMin \ 60 & Format(lngMin Mod 60, "\:00") HTH Sander --- Arthur Fuller wrote: > Can someone point me in the right direction to write > a message to the status > bar? I've done it before but forgotten how. I know > that it has something to > do with acSysCmdSetStatus but that's all I can > remember. > > TIA, > Arthur > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From robert at webedb.com Tue Jul 10 08:21:35 2007 From: robert at webedb.com (Robert L. Stewart) Date: Tue, 10 Jul 2007 08:21:35 -0500 Subject: [AccessD] Upsize wizard => Queries In-Reply-To: References: Message-ID: <200707101325.l6ADPVPa023938@databaseadvisors.com> The syntax for the queries is too different to be migrated. You had to do that yourself. Or, you can change your default to be SQL-92 (I think) compliant. Then you can simply copy and paste the SQL between them. But, either way, you still have to do it yourself. Robert At 07:26 AM 7/10/2007, you wrote: >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) >From: Sad Der >Subject: [AccessD] Upsize wizard => Queries >To: Acces User Group >Message-ID: <460545.53873.qm at web31611.mail.mud.yahoo.com> >Content-Type: text/plain; charset=iso-8859-1 > >Hi group, > >Using the upgrade wizard I can migrate the tables and >data in a couple of minutes to SQL Server. > >(Action) Queries are not migrated. > >Does anybody know of a tool that migrates queries to >sql server views and/or sp's? > >TIA!!!! > >Regards, > >Sander From phpons at gmail.com Tue Jul 10 08:48:51 2007 From: phpons at gmail.com (philippe pons) Date: Tue, 10 Jul 2007 15:48:51 +0200 Subject: [AccessD] How to print a report? Message-ID: <57144ced0707100648v170b79fbvebb7d3af3a978506@mail.gmail.com> Hi all, I tried to print a report, but unsuccessfully till now! I need to print the report but prior to this I set it'sFilter property: Report_BULLETIN.Filter = "COLL_ID=" & Me.cboSelColl.Value Report_BULLETIN.FilterOn = True I discover I have to open the report and then set the Filter and FilterOn property. All is ok, I can see my filtered report. Now I want to print it. I user DoCmd.OpenReport "BULLETIN", acViewPreview Report_BULLETIN.Filter = "COLL_ID=" & Me.cboSelColl.Value Report_BULLETIN.FilterOn = True DoCmd.OpenReport sNomEtat, acViewNormal The report is printed with the correct number of records, but it remains open in design view!! What is the correct way of doing that? Regards, Philippe From DWUTKA at Marlow.com Tue Jul 10 09:24:29 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Tue, 10 Jul 2007 09:24:29 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: This is starting to degrade into a full blown bound/unbound debate. There's no point. There is a time and a place for both. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Monday, July 09, 2007 10:02 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? Drew: I'm familiar with the 'use at your own risk' 'AddressOf' function since the days of Access97 at 'The Access Web' of Dev Ashish, but this is not the sense in which most Access programmers ordinarily are familiar with callback functions. Of couse the whole callback thing has little bearing on the initial question about performance tips or on the question of bound or unbound. I still haven't seen an explanation of how unbound is inherently faster than bound. I've heard discussion about being able to do certain kinds of things unbound that can't be done bound and have given a couple examples myslef. I still don't see how it provides additional performance so don't understand in what sense proposing it is an answer to the question. There is also little sense in making the assumption that everyone is a good developer and is aware of the issues that may come with losing record locking. It is irresponsible to say that jet looks after record locking, no difference, bound or unbound. You can't advocate something that will undoubtedly hurt people if you don't mention the caveats. What constitutes 'good developing' depends on a number of factors. In terms of performance, a degree of denormalization may be good thing as it can cut down the number of joins to be processed. In the database from which I drew the contract value/address example, we never had identical addresses for multiple projects. Sure we have addresses for various kinds of entities and they could be stored in a single table, but placing all the addresses in a separate table would have resulted in a table with a much larger number of records that would have to be hit to populate a record fore each kind of entity. Querying for any kind of related record by address, that would be possible by normalizing, was of no advantage in this database. Worse yet, the physical address of a project never changes, but if you join that address to a company and some bright bulb changes the address of the company when it moves rather than adding a new address and 'deactivating' or date ranging the validity of the address, the edit to the address changes the AddressOf (pun intended) the project. In the example I gave, both the contract value and the addresses were appropriate characteristics of the project. I've also gotten performance gains out of mapping data to bit flags; another normalization no no. Callback functions are very useful to me in cases where I do use foreign keys as I frequently fill a combo or list from an array and avoid a hit on the database. In addition to what Colby calls JIT sub forms, together with limiting the data to only needed data, you can do the same thing with combos, displaying a text value in a delimited list and converting to an SQL rowsource on GotFocus provided you store the text value in the table together with the FK. One of the slower built in functions in Access is the CurrentDb function and it can crawl when called in a loop. I use a function that keeps a static variable that points to a database object and returns a reference to that object. The database for which this question was asked is large in terms of numbers of objects. CurrentDb forces a refresh of all the database objects so I use an optional parameter that allows me to specify should I need to refresh the collection. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From fuller.artful at gmail.com Tue Jul 10 09:42:50 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 10 Jul 2007 10:42:50 -0400 Subject: [AccessD] Writing to the Access status bar In-Reply-To: <671421.18251.qm@web31606.mail.mud.yahoo.com> References: <29f585dd0707100526p316620b7i7e7dece2f48a9266@mail.gmail.com> <671421.18251.qm@web31606.mail.mud.yahoo.com> Message-ID: <29f585dd0707100742x755cb1aepe84f03f43cf40034@mail.gmail.com> That's what I thought, but the behabiour (or lack thereof) puzzles me. What I see instead is "calculating" and then "form" on the status line. On 7/10/07, Sad Der wrote: > > Hi Arthur, > > SysCmd acSysCmdSetStatus, "Elapsed Time: " & _ > lngMin \ 60 & Format(lngMin Mod 60, "\:00") > > HTH > > Sander > --- Arthur Fuller wrote: > > > Can someone point me in the right direction to write > > a message to the status > > bar? I've done it before but forgotten how. I know > > that it has something to > > do with acSysCmdSetStatus but that's all I can > > remember. > > > > TIA, > > Arthur > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > ____________________________________________________________________________________ > Shape Yahoo! in your own image. Join our Network Research Panel today! > http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From John.Clark at niagaracounty.com Tue Jul 10 09:47:46 2007 From: John.Clark at niagaracounty.com (John Clark) Date: Tue, 10 Jul 2007 10:47:46 -0400 Subject: [AccessD] MDE Will not open (resent?) In-Reply-To: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> Message-ID: <469363D1.167F.006B.0@niagaracounty.com> I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? I did not write this thing...I'm not getting a good answer on who exactly did...so I don't know much about it's origins. From jwelz at hotmail.com Tue Jul 10 09:59:48 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Tue, 10 Jul 2007 08:59:48 -0600 Subject: [AccessD] Update the current recordset In-Reply-To: <20070710123624.52451BDAE@smtp-auth.no-ip.com> Message-ID: If you use a long for the 'Marked' field, you can assign 32 users a bit position within the long. I've done this to flag users in our office for appointments and meetings. Alternatively you could use a text field with delimited User IDs and query with 'Like *" & UserID & "*', though querying on the bit is more efficient. Hence this needn't necessarily be a bound limitation. In terms of marking a field based on a filtered recordset, I'd be inclined to run a dbExecute rather than iterating a recordset: "Update tblDivision Set Marked = True Where " & Forms("frmDivision").Filter or you could write the Where clause based on the buttons and combos. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "jwcolby" > >First of all, using a field called "Marked" may cause multi-user issues. >It >definitely will in a bound form, because the records are live linked back >to >the table. If another user clears the marked flag for a record the current >user is looking at... > > >John W. Colby >Colby Consulting > >I have continuous form that is a subform. On the parent form's header are >some buttons and combo boxes that are used to filter the continuous >subform. >This all works fine. There's an option group that contains "Mark All", >"Find >Marked" and "Unmark All" options. When I first wrote it, "Mark All" applied >to all the records in the table but I want it to be smarter than that. To >wit, when you filter, say, by age, and select 20 as the age, then only a >small subset of the total rows are shown. I want "Mark all" to apply to the >subset not the whole table. > >The Marking is done using a column in the table called Marked. The first >version invokes a stored procedure to mark and unmark all the records and >it >is amazingly quick. > >I thought that if I used the recordsetclone it would present only the >filtered subset, but apparently that doesn't work. Here's the code I wrote: > > >Sub MarkAllRecords() > Dim rst As ADODB.Recordset > With Me > Set rst = .Riders_Browser_fsub.Form.RecordsetClone > > Do While Not rst.EOF > rst.Fields("Marked") = -1 > rst.Update > Debug.Print rst("RiderID"), rst("Marked") > rst.MoveNext > Loop > Debug.Print rst.RecordCount & " rows changed." > rst.Close > Set rst = Nothing > End With >End Sub > > >This marks all the records in the table, not the filtered subset. How do I >get a handle on just the subset? I suppose that I could use a SQL statement >that specifies the current filter, which I shall try now, but I'm wondering >why the code above doesn't work -- or rather, how to make it work. > >TIA, >Arthur _________________________________________________________________ New Windows Live Hotmail is here. Upgrade for free and get a better look. www.newhotmail.ca?icid=WLHMENCA150 From garykjos at gmail.com Tue Jul 10 10:02:12 2007 From: garykjos at gmail.com (Gary Kjos) Date: Tue, 10 Jul 2007 10:02:12 -0500 Subject: [AccessD] MDE Will not open (resent?) In-Reply-To: <469363D1.167F.006B.0@niagaracounty.com> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> <469363D1.167F.006B.0@niagaracounty.com> Message-ID: Are your users using multiple versions of Access? This is a bad thing. Does each user open their own copy? If not this is a problem too. Is it split into front end back end? Is it actually a A2K3 database? Or is is maybe a A2K database? Are their multiple users in it at once? Sorry I don't have any answers. Only questions. GK On 7/10/07, John Clark wrote: > I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? > > I did not write this thing...I'm not getting a good answer on who exactly did...so I don't know much about it's origins. > > > -- > 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 jwcolby at colbyconsulting.com Tue Jul 10 10:03:05 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 10 Jul 2007 11:03:05 -0400 Subject: [AccessD] MDE Will not open (resent?) In-Reply-To: <469363D1.167F.006B.0@niagaracounty.com> Message-ID: <20070710150307.849DCBC80@smtp-auth.no-ip.com> Sounds like an opportunity... To write them a new application. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Clark Sent: Tuesday, July 10, 2007 10:48 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] MDE Will not open (resent?) I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? I did not write this thing...I'm not getting a good answer on who exactly did...so I don't know much about it's origins. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue Jul 10 10:21:29 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 10 Jul 2007 08:21:29 -0700 Subject: [AccessD] Writing to the Access status bar In-Reply-To: <29f585dd0707100742x755cb1aepe84f03f43cf40034@mail.gmail.com> References: <29f585dd0707100526p316620b7i7e7dece2f48a9266@mail.gmail.com><671421.18251.qm@web31606.mail.mud.yahoo.com> <29f585dd0707100742x755cb1aepe84f03f43cf40034@mail.gmail.com> Message-ID: The problem is that if you're running a query or have some other operations being performed, their messages show up in the same place in the status bar (i.e. "Calculating ..."). Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, July 10, 2007 7:43 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Writing to the Access status bar That's what I thought, but the behabiour (or lack thereof) puzzles me. What I see instead is "calculating" and then "form" on the status line. On 7/10/07, Sad Der wrote: > > Hi Arthur, > > SysCmd acSysCmdSetStatus, "Elapsed Time: " & _ lngMin \ 60 & > Format(lngMin Mod 60, "\:00") > > HTH > > Sander > --- Arthur Fuller wrote: > > > Can someone point me in the right direction to write a message to > > the status bar? I've done it before but forgotten how. I know that > > it has something to do with acSysCmdSetStatus but that's all I can > > remember. > > > > TIA, > > Arthur > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > ______________________________________________________________________ > ______________ Shape Yahoo! in your own image. Join our Network > Research Panel today! > http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > -- > 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 accessd at shaw.ca Tue Jul 10 10:40:17 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 10 Jul 2007 08:40:17 -0700 Subject: [AccessD] Compile errors In-Reply-To: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> Message-ID: <0JKY0051NZANZUQ0@l-daemon> Hi All: Has anyone had a similar error: "compile error: User defined type not defined" I can not duplicate the error on my system and the client can not resolve the error on their system. They have the complete application, to the letter, running on their site. What could be causing this error as it appears they have virtually the same MS Access version that I do? TIA Jim From Gustav at cactus.dk Tue Jul 10 10:53:36 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Tue, 10 Jul 2007 17:53:36 +0200 Subject: [AccessD] Compile errors Message-ID: Hi Jim This sounds like one of our all time classics. Broken References in Runtime AXP and A97: http://databaseadvisors.com/mailman/htdig/accessd/2003-July/011034.html The issue is caused by the two installations being not fully identical even though it may appear so. /gustav >>> accessd at shaw.ca 10-07-2007 17:40 >>> Hi All: Has anyone had a similar error: "compile error: User defined type not defined" I can not duplicate the error on my system and the client can not resolve the error on their system. They have the complete application, to the letter, running on their site. What could be causing this error as it appears they have virtually the same MS Access version that I do? TIA Jim From carbonnb at gmail.com Tue Jul 10 11:08:48 2007 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Tue, 10 Jul 2007 12:08:48 -0400 Subject: [AccessD] Compile errors In-Reply-To: <0JKY0051NZANZUQ0@l-daemon> References: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> <0JKY0051NZANZUQ0@l-daemon> Message-ID: On 7/10/07, Jim Lawrence wrote: > Has anyone had a similar error: "compile error: User defined type not > defined" I can not duplicate the error on my system and the client can not > resolve the error on their system. They have the complete application, to > the letter, running on their site. > > What could be causing this error as it appears they have virtually the same > MS Access version that I do? Jet SP levels is what I have found causes these errors. I had this error once because I had Jet SP6 and the users workstations had Jet SP3. Once I upgraded the workstations to Jet SP6 the error went away. MS has a tool, MDAC Utility: Component Checker, to see what versions and SP level the install is at. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From miscellany at mvps.org Tue Jul 10 14:35:15 2007 From: miscellany at mvps.org (Steve Schapel) Date: Wed, 11 Jul 2007 07:35:15 +1200 Subject: [AccessD] How to print a report? In-Reply-To: <57144ced0707100648v170b79fbvebb7d3af3a978506@mail.gmail.com> References: <57144ced0707100648v170b79fbvebb7d3af3a978506@mail.gmail.com> Message-ID: <4693DF73.2010704@mvps.org> Philippe, I think it would be neater to use the Where Condition argument of the OpenReport method, rather than Filter. That way you would only need the one line of code, like this... DoCmd.OpenReport "BULLETIN", , , "COLL_ID=" & Me.cboSelColl Regards Steve philippe pons wrote: > Hi all, > > I tried to print a report, but unsuccessfully till now! > > I need to print the report but prior to this I set it'sFilter property: > Report_BULLETIN.Filter = "COLL_ID=" & Me.cboSelColl.Value > Report_BULLETIN.FilterOn = True > > I discover I have to open the report and then set the Filter and FilterOn > property. > All is ok, I can see my filtered report. > > Now I want to print it. > I user > DoCmd.OpenReport "BULLETIN", acViewPreview > Report_BULLETIN.Filter = "COLL_ID=" & Me.cboSelColl.Value > Report_BULLETIN.FilterOn = True > DoCmd.OpenReport sNomEtat, acViewNormal > > The report is printed with the correct number of records, but it remains > open in design view!! > > What is the correct way of doing that? > > Regards, Philippe From martyconnelly at shaw.ca Tue Jul 10 15:12:54 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Tue, 10 Jul 2007 13:12:54 -0700 Subject: [AccessD] MDE Will not open (resent?) In-Reply-To: <469363D1.167F.006B.0@niagaracounty.com> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> <469363D1.167F.006B.0@niagaracounty.com> Message-ID: <4693E846.2020808@shaw.ca> You could try JetComp.exe on a copy of the MDE http://support.microsoft.com/kb/295334/en-us John Clark wrote: >I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? > >I did not write this thing...I'm not getting a good answer on who exactly did...so I don't know much about it's origins. > > > > -- Marty Connelly Victoria, B.C. Canada From accessd666 at yahoo.com Wed Jul 11 01:45:03 2007 From: accessd666 at yahoo.com (Sad Der) Date: Tue, 10 Jul 2007 23:45:03 -0700 (PDT) Subject: [AccessD] Upsize wizard => Queries In-Reply-To: <200707101325.l6ADPVPa023938@databaseadvisors.com> Message-ID: <505071.24605.qm@web31605.mail.mud.yahoo.com> Ok, was afraid of that. Is there a way to retrieve the SQL text of the query in a automated way? Regards, Sander --- "Robert L. Stewart" wrote: > The syntax for the queries is too different to be > migrated. You had to do that yourself. > > Or, you can change your default to be SQL-92 (I > think) > compliant. Then you can simply copy and paste the > SQL > between them. But, either way, you still have to do > it > yourself. > > Robert > > At 07:26 AM 7/10/2007, you wrote: > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > >From: Sad Der > >Subject: [AccessD] Upsize wizard => Queries > >To: Acces User Group > >Message-ID: > <460545.53873.qm at web31611.mail.mud.yahoo.com> > >Content-Type: text/plain; charset=iso-8859-1 > > > >Hi group, > > > >Using the upgrade wizard I can migrate the tables > and > >data in a couple of minutes to SQL Server. > > > >(Action) Queries are not migrated. > > > >Does anybody know of a tool that migrates queries > to > >sql server views and/or sp's? > > > >TIA!!!! > > > >Regards, > > > >Sander > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 From paul.hartland at fsmail.net Wed Jul 11 08:44:24 2007 From: paul.hartland at fsmail.net (paul.hartland at fsmail.net) Date: Wed, 11 Jul 2007 15:44:24 +0200 (CEST) Subject: [AccessD] Interfacing with CardScan Executive 800 Message-ID: <12402995.165111184161464092.JavaMail.www@wwinf3205> To all, Just a shot in the dark here, but we have purchased a CardScan 800 & would like to put our own front-end on either Access or VB to make it easy for a couple of our employees so they basically only have to put the photo into the scanner, click a button type a payroll number then it automatically saves to a certain directory (possibly after automatically sizing the image) Anyone done this or anything similar ? Thanks in advance for any help on this.... Paul Hartland paul.hartland at fsmail.net 07730 523179 From Lambert.Heenan at AIG.com Wed Jul 11 08:54:11 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Wed, 11 Jul 2007 09:54:11 -0400 Subject: [AccessD] Upsize wizard => Queries Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6BD3@xlivmbx35.aig.com> Sure. Dim qd as QueryDef Dim strSQL as String For Each qd in QueryDefs strSQL = qd.SQL ' Save the sql somewhere Next qd Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der Sent: Wednesday, July 11, 2007 2:45 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Upsize wizard => Queries Ok, was afraid of that. Is there a way to retrieve the SQL text of the query in a automated way? Regards, Sander --- "Robert L. Stewart" wrote: > The syntax for the queries is too different to be > migrated. You had to do that yourself. > > Or, you can change your default to be SQL-92 (I > think) > compliant. Then you can simply copy and paste the > SQL > between them. But, either way, you still have to do > it > yourself. > > Robert > > At 07:26 AM 7/10/2007, you wrote: > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > >From: Sad Der > >Subject: [AccessD] Upsize wizard => Queries > >To: Acces User Group > >Message-ID: > <460545.53873.qm at web31611.mail.mud.yahoo.com> > >Content-Type: text/plain; charset=iso-8859-1 > > > >Hi group, > > > >Using the upgrade wizard I can migrate the tables > and > >data in a couple of minutes to SQL Server. > > > >(Action) Queries are not migrated. > > > >Does anybody know of a tool that migrates queries > to > >sql server views and/or sp's? > > > >TIA!!!! > > > >Regards, > > > >Sander > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ____________________________________________________________________________ ________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 11 09:19:36 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 10:19:36 -0400 Subject: [AccessD] Visual studio help Message-ID: <20070711141940.0F966BE2C@smtp-auth.no-ip.com> I am still locked in to the SQL Server help when inside of visual Studio. If I hit F1 at any time, anywhere, with anything selected, help opens but it is SQL Server 2005 help. I need it to be VB.Net help, at least as the default. I cannot for the life of me determine where I can select a different default help file to open when I press F1. Does anyone out there have a clue? John W. Colby Colby Consulting www.ColbyConsulting.com From jwcolby at colbyconsulting.com Wed Jul 11 10:51:28 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 11:51:28 -0400 Subject: [AccessD] [dba-VB] Visual studio help In-Reply-To: Message-ID: <20070711155131.9F8C9BE74@smtp-auth.no-ip.com> Yes, but if you hit F1 then it opens a help file of some sort. I can say whether it is going to use the local help or the internet help first etc. As for books online, well... I only know that term in terms of SQL Server. 1) Go into code. 2) Select some something, keyword, whatever. 3) Hit F1. What do you see? I see a help window. On the top blue bar it says "Microsoft Visual Studio 2005 Documentation". That is a good sign. However on the left hand side there is a Pane (or PAIN depending on your point of view), which has a "filter by" combo. The ONLY CHOICES (for me) are: SQL Server 2005 SQL Server Analysis Service SQL Server... SQL Server... SQL Server... Etc etc. I am locked in to filtering on SQL Server help. I DON'T WANT SQL SERVER HELP, I WANT VB HELP. Actually I want to be able to select VB, C#, Java, SQL Server and whatever else is appropriate in the context I am using. I am flying Visual Studio blind, unless all I am interested in is SQL Server help in which case I am ducky. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 11, 2007 11:14 AM To: dba-vb at databaseadvisors.com Subject: Re: [dba-VB] Visual studio help By SQL Server Help, do you mean BOL, John? I don't find the F1 especially usefull in VS 2005 except as a way to open the help window. I usually wind up doing a search once the help window has come up because it never seems to locate what I'm looking for otherwise. Charlotte Foust -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 11, 2007 7:20 AM To: 'Access Developers discussion and problem solving'; dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com Subject: [dba-VB] Visual studio help I am still locked in to the SQL Server help when inside of visual Studio. If I hit F1 at any time, anywhere, with anything selected, help opens but it is SQL Server 2005 help. I need it to be VB.Net help, at least as the default. I cannot for the life of me determine where I can select a different default help file to open when I press F1. Does anyone out there have a clue? John W. Colby Colby Consulting www.ColbyConsulting.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com From iggy at nanaimo.ark.com Wed Jul 11 11:13:35 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Wed, 11 Jul 2007 09:13:35 -0700 Subject: [AccessD] Visual Studio Message-ID: <469501AF.6000501@nanaimo.ark.com> Hey All Sorry this may sound like a dumb question. I have just had a local computer store order me a copy of Office 2003. I asked them about ordering Visual Studio 2005 Tools for the Microsoft Office System They cannot seem to find it. Does this package have to be ordered through Microsoft? I live in Nanaimo, B.C. Canada. Anyone know of anyone local on the island or Vancouver that may carry the product? Thank you From jwcolby at colbyconsulting.com Wed Jul 11 11:29:03 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 12:29:03 -0400 Subject: [AccessD] [dba-SQLServer] Visual studio help In-Reply-To: <200707111605.l6BG50a6018086@databaseadvisors.com> Message-ID: <20070711162907.4016CBE1D@smtp-auth.no-ip.com> Robert, Yep, a reinstall of MSDN fixed the problem. Thanks for the heads up John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert Sent: Wednesday, July 11, 2007 12:00 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Visual studio help John, The help files for Visual Studio are not installed automatically. You have to run the install on the MSDN disk(s) that came with it to get help of any kind. Robert At 10:51 AM 7/11/2007, you wrote: >Date: Wed, 11 Jul 2007 11:51:28 -0400 >From: "jwcolby" >Subject: Re: [dba-SQLServer] [dba-VB] Visual studio help >To: , > , "'Access Developers discussion and > problem solving'" >Message-ID: <20070711155131.9F8C9BE74 at smtp-auth.no-ip.com> >Content-Type: text/plain; charset="us-ascii" > >Yes, but if you hit F1 then it opens a help file of some sort. I can >say whether it is going to use the local help or the internet help first etc. >As for books online, well... I only know that term in terms of SQL Server. > >1) Go into code. >2) Select some something, keyword, whatever. >3) Hit F1. > >What do you see? > >I see a help window. On the top blue bar it says "Microsoft Visual >Studio >2005 Documentation". That is a good sign. > >However on the left hand side there is a Pane (or PAIN depending on >your point of view), which has a "filter by" combo. The ONLY CHOICES >(for me) >are: > >SQL Server 2005 >SQL Server Analysis Service >SQL Server... >SQL Server... >SQL Server... >Etc etc. > >I am locked in to filtering on SQL Server help. I DON'T WANT SQL >SERVER HELP, I WANT VB HELP. > >Actually I want to be able to select VB, C#, Java, SQL Server and >whatever else is appropriate in the context I am using. I am flying >Visual Studio blind, unless all I am interested in is SQL Server help >in which case I am ducky. > >John W. Colby _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 11 12:28:45 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 11 Jul 2007 10:28:45 -0700 Subject: [AccessD] Visual Studio In-Reply-To: <469501AF.6000501@nanaimo.ark.com> References: <469501AF.6000501@nanaimo.ark.com> Message-ID: For 2003, you need the VSTO for 2003. The tools for 2007 were briefly available for download but I think were then pulled for problems. To my knowledge, there is no VSTO 2005, since there was no Office 2005. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Tony Septav Sent: Wednesday, July 11, 2007 9:14 AM To: Access Developers discussion and problem solving Subject: [AccessD] Visual Studio Hey All Sorry this may sound like a dumb question. I have just had a local computer store order me a copy of Office 2003. I asked them about ordering Visual Studio 2005 Tools for the Microsoft Office System They cannot seem to find it. Does this package have to be ordered through Microsoft? I live in Nanaimo, B.C. Canada. Anyone know of anyone local on the island or Vancouver that may carry the product? Thank you -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Wed Jul 11 14:20:34 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 11 Jul 2007 15:20:34 -0400 Subject: [AccessD] Upsize wizard => Queries In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6BD3@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6BD3@xlivmbx35.aig.com> Message-ID: <29f585dd0707111220if71501fxcc4a3c35e43c6783@mail.gmail.com> The biggest single thing you can do to get from Here to There is check all your recordsouces and rowsources for instances that begin with "SELECT". Before you migrate, visit every instance and turn it into a named query. Failure to do this results in a) a bunch of views/sprocs with names similar to "~#;flkjh", which may be meaningful to you but certainly are not to me. Following this simple rule results in error messages that precisely identify the queries that wouldn't port. These failures can occur for several reasons, among which are: 1. use of a built-in Access function that doesn't exist in SQL. 2. (the one that got me many times) use of static functions that I wrote that don't exist in SQL. 3. differences in syntax (they're aren't a lot but there are more than a dozen). So. My recommendation is, if you're not already too deep in the puddle to retreat, back up and start again. Somewhere around I have code that walks all the rowsources and recordsources looking for the word SELECT as the first part of the string, then dumps all those and their consumers to a file. I haven't needed it for a while, so it may take a bit of time to dig it up. Alternatively, if you have Rick Fisher's FR or Speed Ferret you can narrow the search scope and quickly locate these errant bits of code. My second recommendation is, even if you think you're going to work in Access to your twilight days, STOP planting SELECT statements in the code and control properties. It's asinine. Create named queries. In case my point wasn't clear, Create Named Queries! (With respect, your air code misses most of the problems that arise. QueryDefs are easily identified and fixed or rewritten. It's the embedded SELECTs that kill ya.) Arthur On 7/11/07, Heenan, Lambert wrote: > > Sure. > > > > Dim qd as QueryDef > Dim strSQL as String > > For Each qd in QueryDefs > strSQL = qd.SQL > ' Save the sql somewhere > Next qd > > > > Lambert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der > Sent: Wednesday, July 11, 2007 2:45 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Upsize wizard => Queries > > > Ok, was afraid of that. Is there a way to retrieve the > SQL text of the query in a automated way? > > Regards, > > Sander > > > > --- "Robert L. Stewart" wrote: > > > The syntax for the queries is too different to be > > migrated. You had to do that yourself. > > > > Or, you can change your default to be SQL-92 (I > > think) > > compliant. Then you can simply copy and paste the > > SQL > > between them. But, either way, you still have to do > > it > > yourself. > > > > Robert > > > > At 07:26 AM 7/10/2007, you wrote: > > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > > >From: Sad Der > > >Subject: [AccessD] Upsize wizard => Queries > > >To: Acces User Group > > >Message-ID: > > <460545.53873.qm at web31611.mail.mud.yahoo.com> > > >Content-Type: text/plain; charset=iso-8859-1 > > > > > >Hi group, > > > > > >Using the upgrade wizard I can migrate the tables > > and > > >data in a couple of minutes to SQL Server. > > > > > >(Action) Queries are not migrated. > > > > > >Does anybody know of a tool that migrates queries > > to > > >sql server views and/or sp's? > > > > > >TIA!!!! > > > > > >Regards, > > > > > >Sander > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > > ____________________________________________________________________________ > ________ > Be a PS3 game guru. > Get your game face on with the latest PS3 news and previews at Yahoo! > Games. > http://videogames.yahoo.com/platform?platform=120121 > -- > 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 Wed Jul 11 14:26:16 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Wed, 11 Jul 2007 14:26:16 -0500 Subject: [AccessD] Upsize wizard => Queries Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6BDB@xlivmbx35.aig.com> With respect, at no point did I see the term "embedded SELECTs" or anything like it. The questioner was asking about "Queries", which are of course QueryDefs in code land. That said, you're quite right. SQL code in modules come back to bight because of their poor maintainability. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 11, 2007 3:21 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Upsize wizard => Queries The biggest single thing you can do to get from Here to There is check all your recordsouces and rowsources for instances that begin with "SELECT". Before you migrate, visit every instance and turn it into a named query. Failure to do this results in a) a bunch of views/sprocs with names similar to "~#;flkjh", which may be meaningful to you but certainly are not to me. Following this simple rule results in error messages that precisely identify the queries that wouldn't port. These failures can occur for several reasons, among which are: 1. use of a built-in Access function that doesn't exist in SQL. 2. (the one that got me many times) use of static functions that I wrote that don't exist in SQL. 3. differences in syntax (they're aren't a lot but there are more than a dozen). So. My recommendation is, if you're not already too deep in the puddle to retreat, back up and start again. Somewhere around I have code that walks all the rowsources and recordsources looking for the word SELECT as the first part of the string, then dumps all those and their consumers to a file. I haven't needed it for a while, so it may take a bit of time to dig it up. Alternatively, if you have Rick Fisher's FR or Speed Ferret you can narrow the search scope and quickly locate these errant bits of code. My second recommendation is, even if you think you're going to work in Access to your twilight days, STOP planting SELECT statements in the code and control properties. It's asinine. Create named queries. In case my point wasn't clear, Create Named Queries! (With respect, your air code misses most of the problems that arise. QueryDefs are easily identified and fixed or rewritten. It's the embedded SELECTs that kill ya.) Arthur On 7/11/07, Heenan, Lambert wrote: > > Sure. > > > > Dim qd as QueryDef > Dim strSQL as String > > For Each qd in QueryDefs > strSQL = qd.SQL > ' Save the sql somewhere > Next qd > > > > Lambert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der > Sent: Wednesday, July 11, 2007 2:45 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Upsize wizard => Queries > > > Ok, was afraid of that. Is there a way to retrieve the > SQL text of the query in a automated way? > > Regards, > > Sander > > > > --- "Robert L. Stewart" wrote: > > > The syntax for the queries is too different to be > > migrated. You had to do that yourself. > > > > Or, you can change your default to be SQL-92 (I > > think) > > compliant. Then you can simply copy and paste the > > SQL > > between them. But, either way, you still have to do > > it > > yourself. > > > > Robert > > > > At 07:26 AM 7/10/2007, you wrote: > > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > > >From: Sad Der > > >Subject: [AccessD] Upsize wizard => Queries > > >To: Acces User Group > > >Message-ID: > > <460545.53873.qm at web31611.mail.mud.yahoo.com> > > >Content-Type: text/plain; charset=iso-8859-1 > > > > > >Hi group, > > > > > >Using the upgrade wizard I can migrate the tables > > and > > >data in a couple of minutes to SQL Server. > > > > > >(Action) Queries are not migrated. > > > > > >Does anybody know of a tool that migrates queries > > to > > >sql server views and/or sp's? > > > > > >TIA!!!! > > > > > >Regards, > > > > > >Sander > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > > ______________________________________________________________________ > ______ > ________ > Be a PS3 game guru. > Get your game face on with the latest PS3 news and previews at Yahoo! > Games. > http://videogames.yahoo.com/platform?platform=120121 > -- > 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 jwcolby at colbyconsulting.com Wed Jul 11 14:38:20 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 15:38:20 -0400 Subject: [AccessD] Upsize wizard => Queries In-Reply-To: <29f585dd0707111220if71501fxcc4a3c35e43c6783@mail.gmail.com> Message-ID: <20070711193824.10F94BD2E@smtp-auth.no-ip.com> LOL, Right you are Arthur. And stop using static functions, and references to controls on forms and functions that are VBA but don't exist elsewhere and... Hmmm... You are correct on all counts Arthur, however I think that if a move to SQL Server is in order, then they probably got a huge usage out of the database and should just pay up to do a conversion. All of the things mentioned are shortcuts that only work in Access and are part of what makes Access a RAD environment. Moving to client server is a whole nother ball game and trying to build every app in anticipation of that trip is not useful IMHO. Those who need it pay for it, those who don't, don't. It is relatively trivial to write code to open forms and look for SQL statements in combos etc, and even to build saved queries using that SQL statement, embedding the object name in the querydef name. For example qfrmXyzCboAbc. That would "build stored queries" and voila, you can then try the upsize and see what fails now. If I have a major upgrade happening I could write such code quickly enough. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 11, 2007 3:21 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Upsize wizard => Queries The biggest single thing you can do to get from Here to There is check all your recordsouces and rowsources for instances that begin with "SELECT". Before you migrate, visit every instance and turn it into a named query. Failure to do this results in a) a bunch of views/sprocs with names similar to "~#;flkjh", which may be meaningful to you but certainly are not to me. Following this simple rule results in error messages that precisely identify the queries that wouldn't port. These failures can occur for several reasons, among which are: 1. use of a built-in Access function that doesn't exist in SQL. 2. (the one that got me many times) use of static functions that I wrote that don't exist in SQL. 3. differences in syntax (they're aren't a lot but there are more than a dozen). So. My recommendation is, if you're not already too deep in the puddle to retreat, back up and start again. Somewhere around I have code that walks all the rowsources and recordsources looking for the word SELECT as the first part of the string, then dumps all those and their consumers to a file. I haven't needed it for a while, so it may take a bit of time to dig it up. Alternatively, if you have Rick Fisher's FR or Speed Ferret you can narrow the search scope and quickly locate these errant bits of code. My second recommendation is, even if you think you're going to work in Access to your twilight days, STOP planting SELECT statements in the code and control properties. It's asinine. Create named queries. In case my point wasn't clear, Create Named Queries! (With respect, your air code misses most of the problems that arise. QueryDefs are easily identified and fixed or rewritten. It's the embedded SELECTs that kill ya.) Arthur On 7/11/07, Heenan, Lambert wrote: > > Sure. > > > > Dim qd as QueryDef > Dim strSQL as String > > For Each qd in QueryDefs > strSQL = qd.SQL > ' Save the sql somewhere > Next qd > > > > Lambert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der > Sent: Wednesday, July 11, 2007 2:45 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Upsize wizard => Queries > > > Ok, was afraid of that. Is there a way to retrieve the SQL text of the > query in a automated way? > > Regards, > > Sander > > > > --- "Robert L. Stewart" wrote: > > > The syntax for the queries is too different to be migrated. You had > > to do that yourself. > > > > Or, you can change your default to be SQL-92 (I > > think) > > compliant. Then you can simply copy and paste the SQL between them. > > But, either way, you still have to do it yourself. > > > > Robert > > > > At 07:26 AM 7/10/2007, you wrote: > > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > > >From: Sad Der > > >Subject: [AccessD] Upsize wizard => Queries > > >To: Acces User Group > > >Message-ID: > > <460545.53873.qm at web31611.mail.mud.yahoo.com> > > >Content-Type: text/plain; charset=iso-8859-1 > > > > > >Hi group, > > > > > >Using the upgrade wizard I can migrate the tables > > and > > >data in a couple of minutes to SQL Server. > > > > > >(Action) Queries are not migrated. > > > > > >Does anybody know of a tool that migrates queries > > to > > >sql server views and/or sp's? > > > > > >TIA!!!! > > > > > >Regards, > > > > > >Sander > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > > ____________________________________________________________________________ > ________ > Be a PS3 game guru. > Get your game face on with the latest PS3 news and previews at Yahoo! > Games. > http://videogames.yahoo.com/platform?platform=120121 > -- > 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 markamatte at hotmail.com Wed Jul 11 15:10:18 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Wed, 11 Jul 2007 20:10:18 +0000 Subject: [AccessD] Upsize wizard => Queries In-Reply-To: <29f585dd0707111220if71501fxcc4a3c35e43c6783@mail.gmail.com> Message-ID: Sander, Can you use the DOCUMENTER in MS Access...select your queries...when it opens as a report...goto file save as table...open table and filter OBJECT TYPE field for "SQL Statement"...and this will give you the SQL for each query? Just an after thought... Mark A. matte >From: "Arthur Fuller" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Upsize wizard => Queries >Date: Wed, 11 Jul 2007 15:20:34 -0400 > >The biggest single thing you can do to get from Here to There is check all >your recordsouces and rowsources for instances that begin with "SELECT". >Before you migrate, visit every instance and turn it into a named query. >Failure to do this results in a) a bunch of views/sprocs with names similar >to "~#;flkjh", which may be meaningful to you but certainly are not to me. >Following this simple rule results in error messages that precisely >identify >the queries that wouldn't port. These failures can occur for several >reasons, among which are: > >1. use of a built-in Access function that doesn't exist in SQL. >2. (the one that got me many times) use of static functions that I wrote >that don't exist in SQL. >3. differences in syntax (they're aren't a lot but there are more than a >dozen). > >So. My recommendation is, if you're not already too deep in the puddle to >retreat, back up and start again. Somewhere around I have code that walks >all the rowsources and recordsources looking for the word SELECT as the >first part of the string, then dumps all those and their consumers to a >file. I haven't needed it for a while, so it may take a bit of time to dig >it up. Alternatively, if you have Rick Fisher's FR or Speed Ferret you can >narrow the search scope and quickly locate these errant bits of code. > >My second recommendation is, even if you think you're going to work in >Access to your twilight days, STOP planting SELECT statements in the code >and control properties. It's asinine. Create named queries. > >In case my point wasn't clear, Create Named Queries! > >(With respect, your air code misses most of the problems that arise. >QueryDefs are easily identified and fixed or rewritten. It's the embedded >SELECTs that kill ya.) > >Arthur > > >On 7/11/07, Heenan, Lambert wrote: > > > > Sure. > > > > > > > > Dim qd as QueryDef > > Dim strSQL as String > > > > For Each qd in QueryDefs > > strSQL = qd.SQL > > ' Save the sql somewhere > > Next qd > > > > > > > > Lambert > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der > > Sent: Wednesday, July 11, 2007 2:45 AM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] Upsize wizard => Queries > > > > > > Ok, was afraid of that. Is there a way to retrieve the > > SQL text of the query in a automated way? > > > > Regards, > > > > Sander > > > > > > > > --- "Robert L. Stewart" wrote: > > > > > The syntax for the queries is too different to be > > > migrated. You had to do that yourself. > > > > > > Or, you can change your default to be SQL-92 (I > > > think) > > > compliant. Then you can simply copy and paste the > > > SQL > > > between them. But, either way, you still have to do > > > it > > > yourself. > > > > > > Robert > > > > > > At 07:26 AM 7/10/2007, you wrote: > > > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > > > >From: Sad Der > > > >Subject: [AccessD] Upsize wizard => Queries > > > >To: Acces User Group > > > >Message-ID: > > > <460545.53873.qm at web31611.mail.mud.yahoo.com> > > > >Content-Type: text/plain; charset=iso-8859-1 > > > > > > > >Hi group, > > > > > > > >Using the upgrade wizard I can migrate the tables > > > and > > > >data in a couple of minutes to SQL Server. > > > > > > > >(Action) Queries are not migrated. > > > > > > > >Does anybody know of a tool that migrates queries > > > to > > > >sql server views and/or sp's? > > > > > > > >TIA!!!! > > > > > > > >Regards, > > > > > > > >Sander _________________________________________________________________ http://newlivehotmail.com From ssharkins at setel.com Wed Jul 11 17:35:16 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 11 Jul 2007 18:35:16 -0400 Subject: [AccessD] Export Outlook folder to Access Message-ID: <002901c7c40b$c176a110$23b62ad1@SusanOne> I thought that because Outlook could export email to Access so easily, manually, that there'd be a simple export method, but I'm not finding it. Do I really have to map each field to an Access table? When doing this manually, Outlook lets you map, but you don't have to -- so seems like there ought to be a more streamlined process in VBA too. I'm going hunting, but if anyone knows how to do this without running a loop to map each field for each record, I'd be glad for some direction. Susan H. From jmhecht at earthlink.net Wed Jul 11 21:30:49 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Wed, 11 Jul 2007 19:30:49 -0700 Subject: [AccessD] Query Question Message-ID: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> I I have a table with employee's five different certifications they need to work and the expiration date of these certificates. It is a one to one relationship between employee and certification. Professional license Medical Cert Dot Cert Cpr Drivers License It is a one to one relation between the license and expiration date. I need report that goes some thing this. Parameter = # of days into the future to check (user entered) For any expiration date in the criteria Return the employee, the license that is expiring and the name of that license only (not all their valid licensees) Or If returning all the licensees bold the license that is meeting the criteria and adding the employee to the report. TIA Joe Hecht jmhecht at earthlink.net From jwcolby at colbyconsulting.com Wed Jul 11 22:03:42 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 23:03:42 -0400 Subject: [AccessD] Windows 2003 x64; SQL Server 2005 X64 Message-ID: <20070712030347.0B7E8BDA9@smtp-auth.no-ip.com> Is anyone out there running Windows 2003 X64? If so would you care to comment on what was involved in getting it to happen, drivers, getting the software etc. Same question for SQl Server 2005 X64. John W. Colby Colby Consulting www.ColbyConsulting.com From miscellany at mvps.org Thu Jul 12 04:46:17 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 12 Jul 2007 21:46:17 +1200 Subject: [AccessD] Query Question In-Reply-To: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> References: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> Message-ID: <4695F869.7060805@mvps.org> Joe, As it stands, I think it would be a case for a User Defined Function. But before going down that track... Are you able to consider a change in your table design, so that these certification expiries are listed as separate records in a related table, instead of separate fields? Regards Steve Joe Hecht wrote: > I I have a table with employee's five different certifications they need to > work and the expiration date of these certificates. > > > > It is a one to one relationship between employee and certification. > > > > Professional license > > Medical Cert > > Dot Cert > > Cpr > > Drivers License > > > > It is a one to one relation between the license and expiration date. > > > > I need report that goes some thing this. > > > > Parameter = # of days into the future to check (user entered) > > > > For any expiration date in the criteria > > > > Return the employee, the license that is expiring and the name of that > license only (not all their valid licensees) > > > > Or > > > > If returning all the licensees bold the license that is meeting the criteria > and adding the employee to the report. > > > > TIA > > > > Joe Hecht > > jmhecht at earthlink.net > > > From jwelz at hotmail.com Thu Jul 12 07:14:55 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 12 Jul 2007 06:14:55 -0600 Subject: [AccessD] Query Question In-Reply-To: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> Message-ID: 1 table for Certs 1 table for Employees 1 table for EmployeeCerts with date of expiry I've found that certifications change with time. Expiry ranges change, we track new certifications, we've added locations with different certs. You can place a date taken in the junction table and use a duration from the Certs table, as this is more flexible. You can place a unique index on the EmployeeCerts table, on the EmployeeID and CertID combination, but then you cannot track history of certifications, only update the date taken or expired depending on the design. Placing an exclusive index on the combination of IDs and date would prevent accidental duplicates. Reporting may be done with a Parent report of employees with a sub report of Certs including the EmployeeID and expiry from the EmployeeCerts junction. You can place a parameter on expiry 'Between Now() and UserChosenExpiryMax'. My employees have a course that only has a date taken (non-expiry), though most entities requiring this cert will only recognize it for 3 years. Personally, I think it makes more sense to include course validity range in the course table as a characteristic of the course and the date taken as a characteristic of the Employee Course junction table because users can pick the date taken more accurately than some future expiry date. This complicates the expiry query a bit as it requires a calculated field so it slows things up a bit. Recalling the 'Performance' thread, normalization is usually a good thing, but it can hurt performance. A one to one relationship, or storing the cert expirys in the Employee table directly is a denormalized approach that would give significantly better performance. Sometimes you need to choose between performance and flexibilty. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Joe Hecht" >I I have a table with employee's five different certifications they need to >work and the expiration date of these certificates. > > > >It is a one to one relationship between employee and certification. > > > >Professional license > >Medical Cert > >Dot Cert > >Cpr > >Drivers License > > > >It is a one to one relation between the license and expiration date. > > > >I need report that goes some thing this. > > > >Parameter = # of days into the future to check (user entered) > > > >For any expiration date in the criteria > > > >Return the employee, the license that is expiring and the name of that >license only (not all their valid licensees) > > > >Or > > > >If returning all the licensees bold the license that is meeting the >criteria >and adding the employee to the report. > > > >TIA > > > >Joe Hecht > >jmhecht at earthlink.net _________________________________________________________________ Upgrade to Windows Live Hotmail for free today! www.newhotmail.ca?icid=WLHMENCA151 From jmhecht at earthlink.net Thu Jul 12 08:47:46 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Thu, 12 Jul 2007 06:47:46 -0700 Subject: [AccessD] Query Question In-Reply-To: <4695F869.7060805@mvps.org> References: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> <4695F869.7060805@mvps.org> Message-ID: <001301c7c48b$3b362190$6701a8c0@ACER2G> I can. tblMain Basic Employee Info Subtable Cert and Exp date Is that what you are thinking? Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Thursday, July 12, 2007 2:46 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Query Question Joe, As it stands, I think it would be a case for a User Defined Function. But before going down that track... Are you able to consider a change in your table design, so that these certification expiries are listed as separate records in a related table, instead of separate fields? Regards Steve Joe Hecht wrote: > I I have a table with employee's five different certifications they need to > work and the expiration date of these certificates. > > > > It is a one to one relationship between employee and certification. > > > > Professional license > > Medical Cert > > Dot Cert > > Cpr > > Drivers License > > > > It is a one to one relation between the license and expiration date. > > > > I need report that goes some thing this. > > > > Parameter = # of days into the future to check (user entered) > > > > For any expiration date in the criteria > > > > Return the employee, the license that is expiring and the name of that > license only (not all their valid licensees) > > > > Or > > > > If returning all the licensees bold the license that is meeting the criteria > and adding the employee to the report. > > > > TIA > > > > Joe Hecht > > jmhecht at earthlink.net > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Thu Jul 12 10:20:33 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Thu, 12 Jul 2007 11:20:33 -0400 Subject: [AccessD] SelPos Message-ID: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> I have a memo field for Notes. There is a button to add a new Note. This enables the note control and plonks in the date and sets focus to the note control. This part works nicely. I want to add a CRLF and then place the cursor on the next line. I think it has something to do with SelPos, but I can't remember how to do it. TIA, Arthur From cfoust at infostatsystems.com Thu Jul 12 11:08:21 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 12 Jul 2007 09:08:21 -0700 Subject: [AccessD] SelPos In-Reply-To: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> References: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> Message-ID: I did this in a popup form for editing a memo field in an old app, but I don't have a sample on this machine. If no one else comes up with an answer, I'll dig it out tonight. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Thursday, July 12, 2007 8:21 AM To: Access Developers discussion and problem solving Subject: [AccessD] SelPos I have a memo field for Notes. There is a button to add a new Note. This enables the note control and plonks in the date and sets focus to the note control. This part works nicely. I want to add a CRLF and then place the cursor on the next line. I think it has something to do with SelPos, but I can't remember how to do it. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Thu Jul 12 13:13:58 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 12 Jul 2007 18:13:58 +0000 Subject: [AccessD] SelPos In-Reply-To: Message-ID: Arthur, I have an old example that does something simliar...but it takes text from an unbound field...and places it in Me!History(my notes field). This approach was to keep anyone from editting old notes/history. Hope it helps: Me!History = Me!History & vbCrLf & "*****" & Now() & "**" & Forms!Switchboard!UserName & "**" & vbCrLf & Me!NewHistory Thanks, Mark A. Matte >From: "Charlotte Foust" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] SelPos >Date: Thu, 12 Jul 2007 09:08:21 -0700 > >I did this in a popup form for editing a memo field in an old app, but I >don't have a sample on this machine. If no one else comes up with an >answer, I'll dig it out tonight. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller >Sent: Thursday, July 12, 2007 8:21 AM >To: Access Developers discussion and problem solving >Subject: [AccessD] SelPos > >I have a memo field for Notes. There is a button to add a new Note. This >enables the note control and plonks in the date and sets focus to the >note control. This part works nicely. I want to add a CRLF and then >place the cursor on the next line. I think it has something to do with >SelPos, but I can't remember how to do it. > >TIA, >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 _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From miscellany at mvps.org Thu Jul 12 14:54:30 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 13 Jul 2007 07:54:30 +1200 Subject: [AccessD] Query Question In-Reply-To: <001301c7c48b$3b362190$6701a8c0@ACER2G> References: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> <4695F869.7060805@mvps.org> <001301c7c48b$3b362190$6701a8c0@ACER2G> Message-ID: <469686F6.6080800@mvps.org> Yes, Joe, that's exactly what I was thinking. The "subtable" would have these fields: - EmployeeID - Licence - ExpiryDate A more normalised data structure like this would make the type of query you are asking about a lot simpler. Rergards Steve Joe Hecht wrote: > I can. > > tblMain > > Basic Employee Info > > Subtable > > > Cert and Exp date > > Is that what you are thinking? From miscellany at mvps.org Thu Jul 12 15:17:32 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 13 Jul 2007 08:17:32 +1200 Subject: [AccessD] SelPos In-Reply-To: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> References: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> Message-ID: <46968C5C.10007@mvps.org> Arthur, I think this might be the kind of thing you are after: Me.Notes.SelStart = Len(Me.Notes) + 1 By the way, aside from rich text formatting, another of the very nice new features in Access 2007 is the Append Only property, which does pretty much the kind of thing you are doing here, i.e. dated progressive additions to memo field data. Regards Steve Arthur Fuller wrote: > I have a memo field for Notes. There is a button to add a new Note. This > enables the note control and plonks in the date and sets focus to the note > control. This part works nicely. I want to add a CRLF and then place the > cursor on the next line. I think it has something to do with SelPos, but I > can't remember how to do it. > > TIA, > Arthur From fuller.artful at gmail.com Thu Jul 12 18:20:25 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Thu, 12 Jul 2007 19:20:25 -0400 Subject: [AccessD] SelPos In-Reply-To: References: Message-ID: <29f585dd0707121620k526f62ctd249afbfc545f408@mail.gmail.com> Thanks, Mark! That's precisely what I wanted to do, and I also like the embellishment of adding the user name. Arthur On 7/12/07, Mark A Matte wrote: > > Arthur, > > I have an old example that does something simliar...but it takes text from > an unbound field...and places it in Me!History(my notes field). This > approach was to keep anyone from editting old notes/history. > > Hope it helps: > Me!History = Me!History & vbCrLf & "*****" & Now() & "**" & > Forms!Switchboard!UserName & "**" & vbCrLf & Me!NewHistory > > Thanks, > > Mark A. Matte > > From jwcolby at colbyconsulting.com Fri Jul 13 18:26:43 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 13 Jul 2007 19:26:43 -0400 Subject: [AccessD] Checkbox dates Message-ID: <20070713232646.EA437BD09@smtp-auth.no-ip.com> I often like to use dates as flags, i.e. if a process happened I want a date that the process happened, if it did not happen, then I have a void for the date. However it is often convenient for the user to see the flag as a check box, i.e. they only care THAT it happened, not WHEN it happened. Obviously a checkbox is about Boolean values, not dates. In order to provide a check box interface to a date field in the database I designed a WithEvents class. The class is passed in an UNBOUND checkbox (for the visual display) and a BOUND text box (for the date storage). When the user checks the check box for the flag, the class sets or voids the TEXTBOX VALUE property. The txt.Value is set to Date() if the checkbox is set, and to VOID if the checkbox is cleared. Likewise the checkbox DISPLAYS a true if the value of the textbox is NOT NULL and DISPLAYS a FALSE if the textbox.Value is NULL. This code is in actual use in one of my forms, and represents flags for check stop payments and check voids in the database. The code for the class is as follows: '*************************************** ' 'This is the CLASS module. Cut and paste this into a new class, 'then save to the name clsCtlChk2Date ' Option Compare Database Option Explicit ' 'This class uses a check box to set / void a date in a record 'The objective is to allow the form to set a date to date() if a check box is checked 'and set that date to void if the check box is cleared. ' 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID 'and should display a FALSE if the date is VOID ' 'The class functions by passing in an UNBOUND check box which is the visual indicator 'A BOUND text box is passed in which actually stores the state of the flag as a date data type ' 'Thus as the user clicks the check box, this class sets the underlying (and invisible) text box 'The text box VALUE property is set to DATE if the check box displays a TRUE (is checked) 'and the textbox VALUE property is set to NULL if the checkbox displays a FALSE (is not checked) ' Private WithEvents mchk As CheckBox Private mtxt As TextBox Private Sub Class_Terminate() Set mchk = Nothing Set mtxt = Nothing End Sub Function init(lchk As CheckBox, ltxt As TextBox) Set mchk = lchk Set mtxt = ltxt SetChkState End Function ' 'This function causes the text box to track the visual state of the control 'If the user clicks the check box and the check box ends up TRUE then set the text box to Date() 'else set the text box to VOID ' Private Sub mchk_Click() On Error GoTo Err_mchk_Click If IsNull(mtxt) Then mtxt = Date Else mtxt = Null End If SetChkState Exit_mchk_Click: Exit Sub Err_mchk_Click: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" Resume Exit_mchk_Click End Select Resume 0 '.FOR TROUBLESHOOTING End Sub ' 'This sub causes the visual state of the checkbox to track the text box 'If the text box is VOID (no date) then display a FALSE 'else display a TRUE ' Public Sub SetChkState() On Error GoTo Err_SetChkState If IsNull(mtxt) Then mchk.Value = False Else mchk.Value = True End If Exit_SetChkState: Exit Sub Err_SetChkState: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" Resume Exit_SetChkState End Select Resume 0 '.FOR TROUBLESHOOTING End Sub '*************************************** It hooks in to the form as follows: '*************************************** ' 'This is the form's "code behind" module ' Option Compare Database Option Explicit Private fclsCtlVoidReq As clsctlChk2Date 'Dimension four instances of the class Private fclsCtlVoidProc As clsctlChk2Date Private fclsCtlStopReq As clsctlChk2Date Private fclsCtlStopProc As clsctlChk2Date Private Sub Form_Open(Cancel As Integer) Set fclsCtlStopReq = New clsctlChk2Date 'Instantiate the first one fclsCtlStopReq.init chkStopRequest, txtStopReq 'pass in an UNBOUND check box and a BOUND text box Set fclsCtlStopProc = New clsctlChk2Date fclsCtlStopProc.init chkStopProcessed, txtStopProcessed Set fclsCtlVoidReq = New clsctlChk2Date fclsCtlVoidReq.init chkVoidRequest, txtVoidReq Set fclsCtlVoidProc = New clsctlChk2Date fclsCtlVoidProc.init chkVoidProcessed, txtVoidProcessed End sub Private Sub Form_Current() fclsCtlStopReq.SetChkState 'As the form moves through records, make the checkbox display correctly fclsCtlStopProc.SetChkState fclsCtlVoidReq.SetChkState fclsCtlVoidProc.SetChkState End Sub '*************************************** That is all there is to it. This is another demonstration of where a class sinking events can replace a TON of code placed directly in the form, making code maintenance easier and also fo course making the concept usable in other forms as well as the current form. I hope those who don't use classes find this useful in understanding how classes can be useful, and how to implement classes and WithEvents to solve everyday problems. Enjoy, John W. Colby Colby Consulting www.ColbyConsulting.com From DWUTKA at Marlow.com Fri Jul 13 18:29:01 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Fri, 13 Jul 2007 18:29:01 -0500 Subject: [AccessD] Talking between Applications. Message-ID: Ya learn something new every day, don't ya? I've been re-writing an application I built 7 years ago. The new version is already in production, but I'll be adding new features probably for years to come. It's a help desk application, and one issue I'm working on is that there are several things that are 'monitored' events. Some events are lightning fast, some are a bit slower. The slower ones slow down the interface a bit, because it's all running in the same .exe. To fix this I thought about multithreading, but decided on just creating another application to do the monitoring. So how do you have one application talk to another? Before, I have used winsocks to do this. But it involves making socket connections, etc. This time, I dug into Window Messaging. I've done a lot of things with windows (in Windows) before, but I had to share this little tidbit with the List. To bring everyone up to snuff, every window on your machine has an hWnd value. That's the ID of each window. Windows sends all sorts of messages to each window, for every single thing that you do. When you move the mouse over a window, windows is firing window messages to that window with the mouse position. Clicking, typing, resizing, redrawing and more are all sent to the windows through window messages. When you close an application, that too is a window message. The fun part is, we can use that same process for our own purposes. There's a simple API call, called SendMessage, that requires the hWnd of the window you want to send a message too, the message ID (every process has a static ID, but you can use RegisterWindowMessage to create your own messageid (Unique to that particular machine)) and then two parameters (both long integers). Hey, but wait, if all I can send between two applications is two integers, what's the point? Well, you can also create a window on the fly, with a single API, you can then set it's window text to anything you want, and your recipient applications can read that window text and destroy the window. I have this process in place (the communication part, now I'm on to actually doing something with the comms), and it works great. Virtually no overhead in the communication process, runs as smoothly as moving a window across your screen. If there's interest in something like this, I'll post some code for it. Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From fuller.artful at gmail.com Fri Jul 13 18:41:33 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 13 Jul 2007 19:41:33 -0400 Subject: [AccessD] Talking between Applications. In-Reply-To: References: Message-ID: <29f585dd0707131641k49abbb2dud087ac3c605a81a2@mail.gmail.com> I've done something similar a few years back in PowerBuilder, but would love a look at your method. I don't have any immediate use for it, but this old dog does like to learn occasional new tricks. Arthur On 7/13/07, Drew Wutka wrote: > > Ya learn something new every day, don't ya? I've been re-writing an > application I built 7 years ago. The new version is already in > production, but I'll be adding new features probably for years to come. > It's a help desk application, and one issue I'm working on is that there > are several things that are 'monitored' events. Some events are > lightning fast, some are a bit slower. The slower ones slow down the > interface a bit, because it's all running in the same .exe. To fix this > I thought about multithreading, but decided on just creating another > application to do the monitoring. So how do you have one application > talk to another? > > > > Before, I have used winsocks to do this. But it involves making socket > connections, etc. This time, I dug into Window Messaging. I've done a > lot of things with windows (in Windows) before, but I had to share this > little tidbit with the List. > > > > To bring everyone up to snuff, every window on your machine has an hWnd > value. That's the ID of each window. Windows sends all sorts of > messages to each window, for every single thing that you do. When you > move the mouse over a window, windows is firing window messages to that > window with the mouse position. Clicking, typing, resizing, redrawing > and more are all sent to the windows through window messages. When you > close an application, that too is a window message. > > > > The fun part is, we can use that same process for our own purposes. > There's a simple API call, called SendMessage, that requires the hWnd of > the window you want to send a message too, the message ID (every process > has a static ID, but you can use RegisterWindowMessage to create your > own messageid (Unique to that particular machine)) and then two > parameters (both long integers). Hey, but wait, if all I can send > between two applications is two integers, what's the point? Well, you > can also create a window on the fly, with a single API, you can then set > it's window text to anything you want, and your recipient applications > can read that window text and destroy the window. > > > > I have this process in place (the communication part, now I'm on to > actually doing something with the comms), and it works great. Virtually > no overhead in the communication process, runs as smoothly as moving a > window across your screen. > > > > If there's interest in something like this, I'll post some code for it. > > > > Drew > > > > > The information contained in this transmission is intended only for the > person or entity to which it is addressed and may contain II-VI Proprietary > and/or II-VI BusinessSensitve material. If you are not the intended > recipient, please contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. You are notified that any > review, retransmission, copying, disclosure, dissemination, or other use of, > or taking of any action in reliance upon this information by persons or > entities other than the intended recipient is prohibited. > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From miscellany at mvps.org Fri Jul 13 18:53:00 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 14 Jul 2007 11:53:00 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <20070713232646.EA437BD09@smtp-auth.no-ip.com> References: <20070713232646.EA437BD09@smtp-auth.no-ip.com> Message-ID: <4698105C.4080509@mvps.org> John, That is very cool. Thanks. I am just learning about writing classes, given that there is such an emphasis on it in Access 2007. However, in this specific example, are you able to say whether this approach has any advantage over simple setting the Control Source property of the checkbox to: =[YourDateField] Is Not Null Regards Steve jwcolby wrote: > I often like to use dates as flags, i.e. if a process happened I want a date > that the process happened, if it did not happen, then I have a void for the > date. However it is often convenient for the user to see the flag as a > check box, i.e. they only care THAT it happened, not WHEN it happened. > Obviously a checkbox is about Boolean values, not dates. In order to > provide a check box interface to a date field in the database I designed a > WithEvents class. The class is passed in an UNBOUND checkbox (for the > visual display) and a BOUND text box (for the date storage). > > When the user checks the check box for the flag, the class sets or voids the > TEXTBOX VALUE property. The txt.Value is set to Date() if the checkbox is > set, and to VOID if the checkbox is cleared. > > Likewise the checkbox DISPLAYS a true if the value of the textbox is NOT > NULL and DISPLAYS a FALSE if the textbox.Value is NULL. > > This code is in actual use in one of my forms, and represents flags for > check stop payments and check voids in the database. > > The code for the class is as follows: > > '*************************************** > ' > 'This is the CLASS module. Cut and paste this into a new class, > 'then save to the name clsCtlChk2Date > ' > Option Compare Database > Option Explicit > ' > 'This class uses a check box to set / void a date in a record > 'The objective is to allow the form to set a date to date() if a check box > is checked > 'and set that date to void if the check box is cleared. > ' > 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID > 'and should display a FALSE if the date is VOID > ' > 'The class functions by passing in an UNBOUND check box which is the visual > indicator > 'A BOUND text box is passed in which actually stores the state of the flag > as a date data type > ' > 'Thus as the user clicks the check box, this class sets the underlying (and > invisible) text box > 'The text box VALUE property is set to DATE if the check box displays a TRUE > (is checked) > 'and the textbox VALUE property is set to NULL if the checkbox displays a > FALSE (is not checked) > ' > Private WithEvents mchk As CheckBox > Private mtxt As TextBox > > Private Sub Class_Terminate() > Set mchk = Nothing > Set mtxt = Nothing > End Sub > > Function init(lchk As CheckBox, ltxt As TextBox) > Set mchk = lchk > Set mtxt = ltxt > SetChkState > End Function > ' > 'This function causes the text box to track the visual state of the control > 'If the user clicks the check box and the check box ends up TRUE then set > the text box to Date() > 'else set the text box to VOID > ' > Private Sub mchk_Click() > On Error GoTo Err_mchk_Click > If IsNull(mtxt) Then > mtxt = Date > Else > mtxt = Null > End If > SetChkState > Exit_mchk_Click: > Exit Sub > Err_mchk_Click: > Select Case Err > Case 0 '.insert Errors you wish to ignore here > Resume Next > Case Else '.All other errors will trap > Beep > MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" > Resume Exit_mchk_Click > End Select > Resume 0 '.FOR TROUBLESHOOTING > End Sub > ' > 'This sub causes the visual state of the checkbox to track the text box > 'If the text box is VOID (no date) then display a FALSE > 'else display a TRUE > ' > Public Sub SetChkState() > On Error GoTo Err_SetChkState > If IsNull(mtxt) Then > mchk.Value = False > Else > mchk.Value = True > End If > Exit_SetChkState: > Exit Sub > Err_SetChkState: > Select Case Err > Case 0 '.insert Errors you wish to ignore here > Resume Next > Case Else '.All other errors will trap > Beep > MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" > Resume Exit_SetChkState > End Select > Resume 0 '.FOR TROUBLESHOOTING > End Sub > > '*************************************** > > It hooks in to the form as follows: > > '*************************************** > ' > 'This is the form's "code behind" module > ' > Option Compare Database > Option Explicit > Private fclsCtlVoidReq As clsctlChk2Date 'Dimension four > instances of the class > Private fclsCtlVoidProc As clsctlChk2Date > Private fclsCtlStopReq As clsctlChk2Date > Private fclsCtlStopProc As clsctlChk2Date > > Private Sub Form_Open(Cancel As Integer) > > Set fclsCtlStopReq = New clsctlChk2Date 'Instantiate the > first one > fclsCtlStopReq.init chkStopRequest, txtStopReq 'pass in an UNBOUND > check box and a BOUND text box > > Set fclsCtlStopProc = New clsctlChk2Date > fclsCtlStopProc.init chkStopProcessed, txtStopProcessed > > Set fclsCtlVoidReq = New clsctlChk2Date > fclsCtlVoidReq.init chkVoidRequest, txtVoidReq > > Set fclsCtlVoidProc = New clsctlChk2Date > fclsCtlVoidProc.init chkVoidProcessed, txtVoidProcessed > > End sub > > Private Sub Form_Current() > fclsCtlStopReq.SetChkState 'As the form moves through records, make the > checkbox display correctly > fclsCtlStopProc.SetChkState > fclsCtlVoidReq.SetChkState > fclsCtlVoidProc.SetChkState > End Sub > > '*************************************** > > That is all there is to it. This is another demonstration of where a class > sinking events can replace a TON of code placed directly in the form, making > code maintenance easier and also fo course making the concept usable in > other forms as well as the current form. > > I hope those who don't use classes find this useful in understanding how > classes can be useful, and how to implement classes and WithEvents to solve > everyday problems. > > Enjoy, > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > From jwcolby at colbyconsulting.com Fri Jul 13 23:22:47 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 14 Jul 2007 00:22:47 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <4698105C.4080509@mvps.org> Message-ID: <20070714042249.D0C17BD80@smtp-auth.no-ip.com> I suspect that would work for displaying the value, but I suspect that it would also prevent checking / unchecking the box since the check box could not set / clear what it is bound to. I haven't tried it yet though. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 13, 2007 7:53 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates John, That is very cool. Thanks. I am just learning about writing classes, given that there is such an emphasis on it in Access 2007. However, in this specific example, are you able to say whether this approach has any advantage over simple setting the Control Source property of the checkbox to: =[YourDateField] Is Not Null Regards Steve jwcolby wrote: > I often like to use dates as flags, i.e. if a process happened I want > a date that the process happened, if it did not happen, then I have a > void for the date. However it is often convenient for the user to see > the flag as a check box, i.e. they only care THAT it happened, not WHEN it happened. > Obviously a checkbox is about Boolean values, not dates. In order to > provide a check box interface to a date field in the database I > designed a WithEvents class. The class is passed in an UNBOUND > checkbox (for the visual display) and a BOUND text box (for the date storage). > > When the user checks the check box for the flag, the class sets or > voids the TEXTBOX VALUE property. The txt.Value is set to Date() if > the checkbox is set, and to VOID if the checkbox is cleared. > > Likewise the checkbox DISPLAYS a true if the value of the textbox is > NOT NULL and DISPLAYS a FALSE if the textbox.Value is NULL. > > This code is in actual use in one of my forms, and represents flags > for check stop payments and check voids in the database. > > The code for the class is as follows: > > '*************************************** > ' > 'This is the CLASS module. Cut and paste this into a new class, 'then > save to the name clsCtlChk2Date ' > Option Compare Database > Option Explicit > ' > 'This class uses a check box to set / void a date in a record 'The > objective is to allow the form to set a date to date() if a check box > is checked 'and set that date to void if the check box is cleared. > ' > 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID > 'and should display a FALSE if the date is VOID ' > 'The class functions by passing in an UNBOUND check box which is the > visual indicator 'A BOUND text box is passed in which actually stores > the state of the flag as a date data type ' > 'Thus as the user clicks the check box, this class sets the underlying > (and > invisible) text box > 'The text box VALUE property is set to DATE if the check box displays > a TRUE (is checked) 'and the textbox VALUE property is set to NULL if > the checkbox displays a FALSE (is not checked) ' > Private WithEvents mchk As CheckBox > Private mtxt As TextBox > > Private Sub Class_Terminate() > Set mchk = Nothing > Set mtxt = Nothing > End Sub > > Function init(lchk As CheckBox, ltxt As TextBox) > Set mchk = lchk > Set mtxt = ltxt > SetChkState > End Function > ' > 'This function causes the text box to track the visual state of the > control 'If the user clicks the check box and the check box ends up > TRUE then set the text box to Date() 'else set the text box to VOID ' > Private Sub mchk_Click() > On Error GoTo Err_mchk_Click > If IsNull(mtxt) Then > mtxt = Date > Else > mtxt = Null > End If > SetChkState > Exit_mchk_Click: > Exit Sub > Err_mchk_Click: > Select Case Err > Case 0 '.insert Errors you wish to ignore here > Resume Next > Case Else '.All other errors will trap > Beep > MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" > Resume Exit_mchk_Click > End Select > Resume 0 '.FOR TROUBLESHOOTING > End Sub > ' > 'This sub causes the visual state of the checkbox to track the text > box 'If the text box is VOID (no date) then display a FALSE 'else > display a TRUE ' > Public Sub SetChkState() > On Error GoTo Err_SetChkState > If IsNull(mtxt) Then > mchk.Value = False > Else > mchk.Value = True > End If > Exit_SetChkState: > Exit Sub > Err_SetChkState: > Select Case Err > Case 0 '.insert Errors you wish to ignore here > Resume Next > Case Else '.All other errors will trap > Beep > MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" > Resume Exit_SetChkState > End Select > Resume 0 '.FOR TROUBLESHOOTING > End Sub > > '*************************************** > > It hooks in to the form as follows: > > '*************************************** > ' > 'This is the form's "code behind" module ' > Option Compare Database > Option Explicit > Private fclsCtlVoidReq As clsctlChk2Date 'Dimension four > instances of the class > Private fclsCtlVoidProc As clsctlChk2Date Private fclsCtlStopReq As > clsctlChk2Date Private fclsCtlStopProc As clsctlChk2Date > > Private Sub Form_Open(Cancel As Integer) > > Set fclsCtlStopReq = New clsctlChk2Date 'Instantiate the > first one > fclsCtlStopReq.init chkStopRequest, txtStopReq 'pass in an UNBOUND > check box and a BOUND text box > > Set fclsCtlStopProc = New clsctlChk2Date > fclsCtlStopProc.init chkStopProcessed, txtStopProcessed > > Set fclsCtlVoidReq = New clsctlChk2Date > fclsCtlVoidReq.init chkVoidRequest, txtVoidReq > > Set fclsCtlVoidProc = New clsctlChk2Date > fclsCtlVoidProc.init chkVoidProcessed, txtVoidProcessed > > End sub > > Private Sub Form_Current() > fclsCtlStopReq.SetChkState 'As the form moves through records, make the > checkbox display correctly > fclsCtlStopProc.SetChkState > fclsCtlVoidReq.SetChkState > fclsCtlVoidProc.SetChkState > End Sub > > '*************************************** > > That is all there is to it. This is another demonstration of where a > class sinking events can replace a TON of code placed directly in the > form, making code maintenance easier and also fo course making the > concept usable in other forms as well as the current form. > > I hope those who don't use classes find this useful in understanding > how classes can be useful, and how to implement classes and WithEvents > to solve everyday problems. > > Enjoy, > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Sat Jul 14 00:38:58 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 14 Jul 2007 17:38:58 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <20070714042249.D0C17BD80@smtp-auth.no-ip.com> References: <20070714042249.D0C17BD80@smtp-auth.no-ip.com> Message-ID: <46986172.2070607@mvps.org> You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve jwcolby wrote: > I suspect that would work for displaying the value, but I suspect that it > would also prevent checking / unchecking the box since the check box could > not set / clear what it is bound to. I haven't tried it yet though. From jwcolby at colbyconsulting.com Sat Jul 14 00:47:36 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 14 Jul 2007 01:47:36 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <46986172.2070607@mvps.org> Message-ID: <20070714054738.CFE3DBD33@smtp-auth.no-ip.com> And that is what the code in the class does. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 14, 2007 1:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve jwcolby wrote: > I suspect that would work for displaying the value, but I suspect that > it would also prevent checking / unchecking the box since the check > box could not set / clear what it is bound to. I haven't tried it yet though. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Sat Jul 14 00:56:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 14 Jul 2007 01:56:23 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <46986172.2070607@mvps.org> Message-ID: <20070714055625.721BABC08@smtp-auth.no-ip.com> Oh, never mind. I see that you do it in the On Enter as opposed to the OnClick. Doing it this way would get rid of the need for the code in the OnCurrent event of the form. I will test that and see what I see. Simpler is better. Thanks for the feedback. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 14, 2007 1:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve jwcolby wrote: > I suspect that would work for displaying the value, but I suspect that > it would also prevent checking / unchecking the box since the check > box could not set / clear what it is bound to. I haven't tried it yet though. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Sat Jul 14 07:16:03 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sat, 14 Jul 2007 08:16:03 -0400 Subject: [AccessD] Bold tabs Message-ID: <29f585dd0707140516p7ce5f75dv72fda7d026ee4952@mail.gmail.com> I used to know how to do this. (My senior moments seem to be increasing in their frequency day by day by day!) I want to bold-face the tab strings. I cannot remember how I achieved this before. TIA, Arthur From dwaters at usinternet.com Sat Jul 14 08:18:40 2007 From: dwaters at usinternet.com (Dan Waters) Date: Sat, 14 Jul 2007 08:18:40 -0500 Subject: [AccessD] Bold tabs In-Reply-To: <29f585dd0707140516p7ce5f75dv72fda7d026ee4952@mail.gmail.com> References: <29f585dd0707140516p7ce5f75dv72fda7d026ee4952@mail.gmail.com> Message-ID: <000601c7c619$7edad0a0$0200a8c0@danwaters> In Design Mode, select the tab control (not one of the tabs). Then push the Bold formatting button. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Saturday, July 14, 2007 7:16 AM To: Access Developers discussion and problem solving Subject: [AccessD] Bold tabs I used to know how to do this. (My senior moments seem to be increasing in their frequency day by day by day!) I want to bold-face the tab strings. I cannot remember how I achieved this before. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From adtp at airtelbroadband.in Sat Jul 14 09:27:32 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sat, 14 Jul 2007 19:57:32 +0530 Subject: [AccessD] Checkbox dates References: <20070714055625.721BABC08@smtp-auth.no-ip.com> Message-ID: <017701c7c623$ff888300$f857a27a@pcadt> Apparently the hidden bound text box used for storing date stamp is meant to act as a slave to the check box in question. This would imply that the contents of this text box are not to be disturbed unless there is user action on the check box. Is this correct ? If so, would it not be convenient to make the check box also a bound one ? AfterUpdate event of the check box should then be the most suitable event for placing Steve's code, and as already indicated by him, no code should be needed anywhere else. A.D.Tejpal --------------- ----- Original Message ----- From: jwcolby To: 'Access Developers discussion and problem solving' Sent: Saturday, July 14, 2007 11:26 Subject: Re: [AccessD] Checkbox dates Oh, never mind. I see that you do it in the On Enter as opposed to the OnClick. Doing it this way would get rid of the need for the code in the OnCurrent event of the form. I will test that and see what I see. Simpler is better. Thanks for the feedback. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 14, 2007 1:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve << SNIPPED >> From fuller.artful at gmail.com Sat Jul 14 11:03:57 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sat, 14 Jul 2007 12:03:57 -0400 Subject: [AccessD] Bold tabs In-Reply-To: <000601c7c619$7edad0a0$0200a8c0@danwaters> References: <29f585dd0707140516p7ce5f75dv72fda7d026ee4952@mail.gmail.com> <000601c7c619$7edad0a0$0200a8c0@danwaters> Message-ID: <29f585dd0707140903q9a3540cu63ce6eb161049d10@mail.gmail.com> That did it. Thank you so much! I kept selecting the tabs and it wouldn't work. Totally forgot about selecting the tab control itself. A. On 7/14/07, Dan Waters wrote: > > In Design Mode, select the tab control (not one of the tabs). Then push > the > Bold formatting button. > > Dan > From miscellany at mvps.org Sat Jul 14 16:44:53 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sun, 15 Jul 2007 09:44:53 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <017701c7c623$ff888300$f857a27a@pcadt> References: <20070714055625.721BABC08@smtp-auth.no-ip.com> <017701c7c623$ff888300$f857a27a@pcadt> Message-ID: <469943D5.9020603@mvps.org> Indoctrination in the evils of storing redundant data has thus far prevented me from considering this option, A.D., but I agree that it is a good solution, and a reminder that rules are to be interpreted flexibly. Regards Steve A.D.TEJPAL wrote: > Apparently the hidden bound text box used for storing date stamp is > meant to act as a slave to the check box in question. This would > imply that the contents of this text box are not to be disturbed > unless there is user action on the check box. Is this correct ? > > If so, would it not be convenient to make the check box also a bound > one ? AfterUpdate event of the check box should then be the most > suitable event for placing Steve's code, and as already indicated by > him, no code should be needed anywhere else. From jwcolby at colbyconsulting.com Sat Jul 14 16:48:32 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 14 Jul 2007 17:48:32 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <017701c7c623$ff888300$f857a27a@pcadt> Message-ID: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> In fact you really need a click event. Otherwise if a user tabbed through the control it would change just by getting the focus so to speak. The check box cannot be bound because it is a binary value, not a date type. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Saturday, July 14, 2007 10:28 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates Apparently the hidden bound text box used for storing date stamp is meant to act as a slave to the check box in question. This would imply that the contents of this text box are not to be disturbed unless there is user action on the check box. Is this correct ? If so, would it not be convenient to make the check box also a bound one ? AfterUpdate event of the check box should then be the most suitable event for placing Steve's code, and as already indicated by him, no code should be needed anywhere else. A.D.Tejpal --------------- ----- Original Message ----- From: jwcolby To: 'Access Developers discussion and problem solving' Sent: Saturday, July 14, 2007 11:26 Subject: Re: [AccessD] Checkbox dates Oh, never mind. I see that you do it in the On Enter as opposed to the OnClick. Doing it this way would get rid of the need for the code in the OnCurrent event of the form. I will test that and see what I see. Simpler is better. Thanks for the feedback. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 14, 2007 1:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve << SNIPPED >> -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Sat Jul 14 18:09:10 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sun, 15 Jul 2007 11:09:10 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> References: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> Message-ID: <46995796.8090802@mvps.org> John, Using the idea that I first suggested, with an unbound checkbox's Control Source set to: =[YourDateField] Is Not Null ... will not work with the Click event. The Click event will not fire with a calculated checkbox control. It has to be the Enter event, I think. Setting the checkbox's Tab Stop property to No would prevent the type of problem you envisage. I think A.D. was suggesting the checkbox be bound to a *separate, additional* field, Yes/No data type, in the table. I don't think he meant tying to bind the checkbox to the date field itself. Regards Steve jwcolby wrote: > In fact you really need a click event. Otherwise if a user tabbed through > the control it would change just by getting the focus so to speak. The > check box cannot be bound because it is a binary value, not a date type. > From adtp at airtelbroadband.in Sun Jul 15 00:30:38 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sun, 15 Jul 2007 11:00:38 +0530 Subject: [AccessD] Checkbox dates References: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> <46995796.8090802@mvps.org> Message-ID: <007501c7c6a1$a4cd70f0$5857a27a@pcadt> As correctly presumed by Steve, SourceControl for the bound check box is meant to be an independent field in the table (Yes/No type). In this particular situation, it could be said that having one field for date stamp and another for Yes/No status need not necessarily be regarded as a case of storing redundant data. While Yes/No field acts as the primary one, the date stamp field (hidden from the user) is utilized to store complimentary mirror data in frozen state, with historical significance. Independently bound check box as suggested by me is dictated by user's requirement (as mentioned by John), as the primary means of recording completion of a process. If the form happens to be in continuous form or datasheet view, an unbound check box would be untenable, leading to absurd display. Taking the concept further, in order to prevent inadvertent interference, it might even be desirable to deny de-selection of check box, after it has been selected (to confirm completion of a process) and the record in question has been saved. (Any further interference with a check box in selected status could then be made conditional to authorization at higher level). Sample code in AfterUpdate & Enter events of the checkbox, as given below, should suffice, to cover the requirements outlined above. A.D.Tejpal --------------- Code in form's module (CkStaus and TxtDtStamp are names of controls for check box & hidden text box respectively) ============================= Private Sub CkStatus_AfterUpdate() ' Insert date stamp if check box is selected ' Otherwise clear the date stamp If Me.CkStatus = True Then Me.TxtDtStamp = Date Else Me.TxtDtStamp = Null End If End Sub ------------------------------------------------------ Private Sub CkStatus_Enter() ' Lock the check box if in selected state If Me.CkStatus = True Then Me.CkStatus.Locked = True Else Me.CkStatus.Locked = False End If End Sub ============================= ----- Original Message ----- From: Steve Schapel To: Access Developers discussion and problem solving Sent: Sunday, July 15, 2007 04:39 Subject: Re: [AccessD] Checkbox dates John, Using the idea that I first suggested, with an unbound checkbox's Control Source set to: =[YourDateField] Is Not Null ... will not work with the Click event. The Click event will not fire with a calculated checkbox control. It has to be the Enter event, I think. Setting the checkbox's Tab Stop property to No would prevent the type of problem you envisage. I think A.D. was suggesting the checkbox be bound to a *separate, additional* field, Yes/No data type, in the table. I don't think he meant tying to bind the checkbox to the date field itself. Regards Steve << SNIPPED >> From miscellany at mvps.org Sun Jul 15 01:19:05 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sun, 15 Jul 2007 18:19:05 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <007501c7c6a1$a4cd70f0$5857a27a@pcadt> References: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> <46995796.8090802@mvps.org> <007501c7c6a1$a4cd70f0$5857a27a@pcadt> Message-ID: <4699BC59.9090102@mvps.org> A.D., Not wishing to imply that I disagree with you in any way, because I like what you are suggesting. However... A.D.TEJPAL wrote: > ... If the form happens to be in > continuous form or datasheet view, an unbound check box would be > untenable, leading to absurd display. Just to be clear that I was not suggesting a totally unbound checkbox on the form, but rather one whose Control Source is like this: =[TheDateField] Is Not Null This serves the purpose of displaying, even on a continuous view form, whether the date has been recorded for each record. And equally, the code I suggested earlier, on the Enter event of the checkbox, can be used to manage the date data. I am just relating to how I have done this type of process in the past. I am certainly not claiming that it is superior to yours or John's suggested approaches. But I do know that it has effectively and simply served the purpose for me in various scenarios. Next time I need this type of functionality, I will be considering the idea of an extra (redundant ;-) ) field in the table, as you have described. Regards Steve From jwcolby at colbyconsulting.com Sun Jul 15 06:50:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sun, 15 Jul 2007 07:50:23 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <4699BC59.9090102@mvps.org> Message-ID: <20070715115028.DD5A2BD74@smtp-auth.no-ip.com> As we have discovered there are several ways to do this. I have used the method I suggested for other objects in the past and am comfortable with that. In fact, this is the kind of behavior that is a natural to migrate to my framework. By placing this behavior inside of my existing dclsCtlChkBox I can "turn on" the behavior by passing in a text box to a property of the dclsCtlChkBox and "voila" it would start behaving as a control for a date display. My dclsFrm can and does call each control already in it's OnCurrent event because of previous behaviors where the control needs to know when the form's current has fired (requerying dependent objects). Thus I will likely leave things the way they are for my usage, and you can modify the concept to suit your own requirements. I am content to have demonstrated how to use a class to encapsulate the behaviors required to perform this trick and get everyone thinking about classes and Event handling in classes. I do like A.D.s suggestion for allowing locking of the display based on the state of the display to preserve the fact that it happened. I already have users and groups in my LightWeight Security System built in to the framework so it is trivial to set up security to only allow specific groups to modify the control after it is locked. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 15, 2007 2:19 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates A.D., Not wishing to imply that I disagree with you in any way, because I like what you are suggesting. However... A.D.TEJPAL wrote: > ... If the form happens to be in > continuous form or datasheet view, an unbound check box would be > untenable, leading to absurd display. Just to be clear that I was not suggesting a totally unbound checkbox on the form, but rather one whose Control Source is like this: =[TheDateField] Is Not Null This serves the purpose of displaying, even on a continuous view form, whether the date has been recorded for each record. And equally, the code I suggested earlier, on the Enter event of the checkbox, can be used to manage the date data. I am just relating to how I have done this type of process in the past. I am certainly not claiming that it is superior to yours or John's suggested approaches. But I do know that it has effectively and simply served the purpose for me in various scenarios. Next time I need this type of functionality, I will be considering the idea of an extra (redundant ;-) ) field in the table, as you have described. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From adtp at airtelbroadband.in Sun Jul 15 09:08:02 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sun, 15 Jul 2007 19:38:02 +0530 Subject: [AccessD] Checkbox dates References: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com><46995796.8090802@ mvps.org> <007501c7c6a1$a4cd70f0$5857a27a@pcadt> <4699BC59.9090102@mvps.org> Message-ID: <005201c7c6e9$a593b970$4657a27a@pcadt> Steve, LOL! - Unbound checkbox was envisaged in John's original post. My comments were in that context, and by way of further elaboration of the course of action favored by you. Apparently, the scenario as originally presented, related to single form view. John has perfected a fascinating approach to form related matters. As stated by him, there are so many ways to meet the objectives, making Access all the more interesting. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Steve Schapel To: Access Developers discussion and problem solving Sent: Sunday, July 15, 2007 11:49 Subject: Re: [AccessD] Checkbox dates A.D., Not wishing to imply that I disagree with you in any way, because I like what you are suggesting. However... A.D.TEJPAL wrote: > ... If the form happens to be in > continuous form or datasheet view, an unbound check box would be untenable, leading to absurd display. Just to be clear that I was not suggesting a totally unbound checkbox on the form, but rather one whose Control Source is like this: =[TheDateField] Is Not Null This serves the purpose of displaying, even on a continuous view form, whether the date has been recorded for each record. And equally, the code I suggested earlier, on the Enter event of the checkbox, can be used to manage the date data. I am just relating to how I have done this type of process in the past. I am certainly not claiming that it is superior to yours or John's suggested approaches. But I do know that it has effectively and simply served the purpose for me in various scenarios. Next time I need this type of functionality, I will be considering the idea of an extra (redundant ;-) ) field in the table, as you have described. Regards Steve From accessd at shaw.ca Sun Jul 15 12:32:50 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 15 Jul 2007 10:32:50 -0700 Subject: [AccessD] Compile errors In-Reply-To: Message-ID: <0JL80088RDV9J600@l-daemon> Hi Gustav: A late response but things have been too busy here for checking the list. The client did some patching as was suggested and the app started working correctly. It is funny coincidence that when code increases in complexity the possibility of the program not working when moved to a client's site seems to go up exponentially as well. The dummer the more stable? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Tuesday, July 10, 2007 8:54 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Compile errors Hi Jim This sounds like one of our all time classics. Broken References in Runtime AXP and A97: http://databaseadvisors.com/mailman/htdig/accessd/2003-July/011034.html The issue is caused by the two installations being not fully identical even though it may appear so. /gustav >>> accessd at shaw.ca 10-07-2007 17:40 >>> Hi All: Has anyone had a similar error: "compile error: User defined type not defined" I can not duplicate the error on my system and the client can not resolve the error on their system. They have the complete application, to the letter, running on their site. What could be causing this error as it appears they have virtually the same MS Access version that I do? TIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sun Jul 15 12:33:46 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 15 Jul 2007 10:33:46 -0700 Subject: [AccessD] Compile errors In-Reply-To: Message-ID: <0JL800A4ADWTGRG0@l-daemon> Hi Bryan: Late response but thank you. Client patching worked. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bryan Carbonnell Sent: Tuesday, July 10, 2007 9:09 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Compile errors On 7/10/07, Jim Lawrence wrote: > Has anyone had a similar error: "compile error: User defined type not > defined" I can not duplicate the error on my system and the client can not > resolve the error on their system. They have the complete application, to > the letter, running on their site. > > What could be causing this error as it appears they have virtually the same > MS Access version that I do? Jet SP levels is what I have found causes these errors. I had this error once because I had Jet SP6 and the users workstations had Jet SP3. Once I upgraded the workstations to Jet SP6 the error went away. MS has a tool, MDAC Utility: Component Checker, to see what versions and SP level the install is at. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sun Jul 15 12:41:05 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 15 Jul 2007 10:41:05 -0700 Subject: [AccessD] Talking between Applications. In-Reply-To: Message-ID: <0JL800E4HE8Z5PC0@l-daemon> Hi Drew: As always I am interested in a fine piece of code which expands into new territory. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Friday, July 13, 2007 4:29 PM To: Access Developers discussion and problem solving Subject: [AccessD] Talking between Applications. Ya learn something new every day, don't ya? I've been re-writing an application I built 7 years ago. The new version is already in production, but I'll be adding new features probably for years to come. It's a help desk application, and one issue I'm working on is that there are several things that are 'monitored' events. Some events are lightning fast, some are a bit slower. The slower ones slow down the interface a bit, because it's all running in the same .exe. To fix this I thought about multithreading, but decided on just creating another application to do the monitoring. So how do you have one application talk to another? Before, I have used winsocks to do this. But it involves making socket connections, etc. This time, I dug into Window Messaging. I've done a lot of things with windows (in Windows) before, but I had to share this little tidbit with the List. To bring everyone up to snuff, every window on your machine has an hWnd value. That's the ID of each window. Windows sends all sorts of messages to each window, for every single thing that you do. When you move the mouse over a window, windows is firing window messages to that window with the mouse position. Clicking, typing, resizing, redrawing and more are all sent to the windows through window messages. When you close an application, that too is a window message. The fun part is, we can use that same process for our own purposes. There's a simple API call, called SendMessage, that requires the hWnd of the window you want to send a message too, the message ID (every process has a static ID, but you can use RegisterWindowMessage to create your own messageid (Unique to that particular machine)) and then two parameters (both long integers). Hey, but wait, if all I can send between two applications is two integers, what's the point? Well, you can also create a window on the fly, with a single API, you can then set it's window text to anything you want, and your recipient applications can read that window text and destroy the window. I have this process in place (the communication part, now I'm on to actually doing something with the comms), and it works great. Virtually no overhead in the communication process, runs as smoothly as moving a window across your screen. If there's interest in something like this, I'll post some code for it. Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Sun Jul 15 12:55:15 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sun, 15 Jul 2007 13:55:15 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <005201c7c6e9$a593b970$4657a27a@pcadt> Message-ID: <20070715175517.10513BE4F@smtp-auth.no-ip.com> A.D. It did indeed relate to single form view. This is a data entry screen of a fairly complex record where continuous view simply doesn't work well. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Sunday, July 15, 2007 10:08 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates Steve, LOL! - Unbound checkbox was envisaged in John's original post. My comments were in that context, and by way of further elaboration of the course of action favored by you. Apparently, the scenario as originally presented, related to single form view. John has perfected a fascinating approach to form related matters. As stated by him, there are so many ways to meet the objectives, making Access all the more interesting. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Steve Schapel To: Access Developers discussion and problem solving Sent: Sunday, July 15, 2007 11:49 Subject: Re: [AccessD] Checkbox dates A.D., Not wishing to imply that I disagree with you in any way, because I like what you are suggesting. However... A.D.TEJPAL wrote: > ... If the form happens to be in > continuous form or datasheet view, an unbound check box would be untenable, leading to absurd display. Just to be clear that I was not suggesting a totally unbound checkbox on the form, but rather one whose Control Source is like this: =[TheDateField] Is Not Null This serves the purpose of displaying, even on a continuous view form, whether the date has been recorded for each record. And equally, the code I suggested earlier, on the Enter event of the checkbox, can be used to manage the date data. I am just relating to how I have done this type of process in the past. I am certainly not claiming that it is superior to yours or John's suggested approaches. But I do know that it has effectively and simply served the purpose for me in various scenarios. Next time I need this type of functionality, I will be considering the idea of an extra (redundant ;-) ) field in the table, as you have described. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Sun Jul 15 15:34:42 2007 From: dwaters at usinternet.com (Dan Waters) Date: Sun, 15 Jul 2007 15:34:42 -0500 Subject: [AccessD] 2007 System Table? Message-ID: <000001c7c71f$964fbc30$0200a8c0@danwaters> I just opened a customer's BE file remotely (written in Access 2003). It has four system tables I've never seen before - one of them is MSysNavPaneGroupCategories, and they all start with MSysNavPane. I'm guessing that someone has opened this using Access 2007. Is that correct? Dan Waters From martyconnelly at shaw.ca Sun Jul 15 15:56:12 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Sun, 15 Jul 2007 13:56:12 -0700 Subject: [AccessD] 2007 System Table? In-Reply-To: <000001c7c71f$964fbc30$0200a8c0@danwaters> References: <000001c7c71f$964fbc30$0200a8c0@danwaters> Message-ID: <469A89EC.60207@shaw.ca> Yup they should contain XML instructions for the 2007 Ribbon Bar Dan Waters wrote: >I just opened a customer's BE file remotely (written in Access 2003). It >has four system tables I've never seen before - one of them is >MSysNavPaneGroupCategories, and they all start with MSysNavPane. > >I'm guessing that someone has opened this using Access 2007. Is that >correct? > > >Dan Waters > > > -- Marty Connelly Victoria, B.C. Canada From miscellany at mvps.org Sun Jul 15 16:21:31 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 16 Jul 2007 09:21:31 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <20070715115028.DD5A2BD74@smtp-auth.no-ip.com> References: <20070715115028.DD5A2BD74@smtp-auth.no-ip.com> Message-ID: <469A8FDB.6080706@mvps.org> John, jwcolby wrote: > ... I am content to have > demonstrated how to use a class to encapsulate the behaviors required to > perform this trick and get everyone thinking about classes and Event > handling in classes. I recognise that this was your initial intention, and for this I thank you. Sorry if the discussion went too far off on a tangent. Regards Steve From darrend at nimble.com.au Sun Jul 15 18:48:25 2007 From: darrend at nimble.com.au (Darren D) Date: Mon, 16 Jul 2007 09:48:25 +1000 Subject: [AccessD] Talking between Applications. In-Reply-To: Message-ID: <200707152348.l6FNmlBI029468@databaseadvisors.com> Howdy Would love to see an example of this DD -----Original Message----- From: Drew Wutka [mailto:DWUTKA at marlow.com] Sent: Saturday, 14 July 2007 9:29 AM To: Access Developers discussion and problem solving Subject: [AccessD] Talking between Applications. Ya learn something new every day, don't ya? I've been re-writing an application I built 7 years ago. The new version is already in production, but I'll be adding new features probably for years to come. It's a help desk application, and one issue I'm working on is that there are several things that are 'monitored' events. Some events are lightning fast, some are a bit slower. The slower ones slow down the interface a bit, because it's all running in the same .exe. To fix this I thought about multithreading, but decided on just creating another application to do the monitoring. So how do you have one application talk to another? Before, I have used winsocks to do this. But it involves making socket connections, etc. This time, I dug into Window Messaging. I've done a lot of things with windows (in Windows) before, but I had to share this little tidbit with the List. To bring everyone up to snuff, every window on your machine has an hWnd value. That's the ID of each window. Windows sends all sorts of messages to each window, for every single thing that you do. When you move the mouse over a window, windows is firing window messages to that window with the mouse position. Clicking, typing, resizing, redrawing and more are all sent to the windows through window messages. When you close an application, that too is a window message. The fun part is, we can use that same process for our own purposes. There's a simple API call, called SendMessage, that requires the hWnd of the window you want to send a message too, the message ID (every process has a static ID, but you can use RegisterWindowMessage to create your own messageid (Unique to that particular machine)) and then two parameters (both long integers). Hey, but wait, if all I can send between two applications is two integers, what's the point? Well, you can also create a window on the fly, with a single API, you can then set it's window text to anything you want, and your recipient applications can read that window text and destroy the window. I have this process in place (the communication part, now I'm on to actually doing something with the comms), and it works great. Virtually no overhead in the communication process, runs as smoothly as moving a window across your screen. If there's interest in something like this, I'll post some code for it. Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From pcs at azizaz.com Sun Jul 15 21:06:23 2007 From: pcs at azizaz.com (pcs at azizaz.com) Date: Mon, 16 Jul 2007 12:06:23 +1000 (EST) Subject: [AccessD] Lock of Record - Memofields Message-ID: <20070716120623.CYC21380@dommail.onthenet.com.au> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... This is the setup: Access2003 .mdb with SQL Server2005 Backend. Access .mdb is set to 'no record locks' and so are all Forms. Around 60 Users sitting in the application all day using Terminal Server. All tables odbc linked. There's a main Summary Form with a number of pre-defined filters. The Summary Form is populated using ADO recordset. >From Summary Form User clicks on a record line to access the Detail Form. The Detail Form consists of of a subform control that dynamically loads one of four different subforms. The main form is unbound. Each of the Subforms uses the same record from the same table as source. On the main Form there are four different labels - the click event here loads a particular subform into the subform control. The subform is populated using an ADO recordset call. On the Main Form there are two command buttons: Enter Edit Mode (setting the allow edits property of the Form to Yes) Exit Edit Mode (setting the allow edits property of the Form to No) The subform is always opened in "View Mode", i.e. the allow edits property of the SubForm is set to No. I am using the following record locking scheme : When User is clicking on Enter Edit Mode, code checks the record in question - using ADO call - to see if two fields on the record: "LockedBy" and "LockedDateTime" are null. If they are null, the ADO code updates the two fields with UserName and Current Date Time, and calls the record in again from the table to display on the SubForm currently selected and sets the 'allow edits' to true on the SubForm. The Exit Edit Mode sets the two fields to null and saves the record doing a straight docmd.save. This Exit Edit Mode code is fired before User is leaving the record/form or executing other code than runs an update query on the same record. However, we are encountering the situation where User when exiting the Edit Mode gets the *Access* Lock Message, where User can either drop changes or save changes. User has been instructed to drop changes, which causes the record on the Form to be set back to View Mode with the LockedBy and LockedDateTime Fields still set, resulting in User now 'locking' himself out of the homemade locking scheme. I am pulling out my hair trying to figure out what is causing the built in *Access* Lock Message. I have been over the code in detail making sure that User is not able to create changes to the record while in Edit mode other than via the Form. Other Users can obviously not access the same record via the Form in Edit mode and there is no code in the user interface that runs an update query on the same record. So what is causing the *Access* Lock messages? I searched the AccessD Archives the other day and I suspect the cause might be Memo Fields. If I understand what I read in the AccessD archives correct: Access on records with MemoFields are stil applying page locks and not record locks? There are five memo fields on the record of the table in question. Thank you for reading this far! What's your take on this? Is it the memo fields that are causing this?? What can I do to remedy this situation? The memo fields are basically comments fields. Is this a way to go: Place each comments in separate table in a record with a 255 character field - one to many relationship with main table (and include a comments type field), and on retrieving the main record build up the comments from the associated records into one unbound text control?? Currently the Comments memofield is popuplated and looks like this: 2007-05-23 12:35 jcitizen: Comments Text (vbCrLf) 2007-05-22 15:40 bbrown: Another Comments Text (vbCrLf) in descending date order Regards borge From galeper at gmail.com Sun Jul 15 21:22:22 2007 From: galeper at gmail.com (Gale Perez) Date: Sun, 15 Jul 2007 19:22:22 -0700 Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected, But Not Displayed Message-ID: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> Hello, I'm normalizing a db to replace certain fields with lookup fields. I used the lookup wizard and am storing an autonumber from the lookup table. All updated just fine, except for one. The old field is a text field consisting of the numbers 0-7. I created a query to update the new field (in the example, 8 is the autonumber PK in the lookup table): UPDATE mytable SET mytable.newfield = 8 WHERE (((mytable.[oldfield])="7")); But when I opened the table to verify the new field's data matched that in the old field, I saw that the new field showed nothing but zeros. When I clicked in that field of a particular record, my dropdown box appeared, with the correct value selected - but it is not being displayed! What the heck is going on? Has anyone else had this happen? I tried re-creating both the query and the field, and got the same results. Thank you very much for any thoughts! Gale From tortise at paradise.net.nz Sun Jul 15 21:20:50 2007 From: tortise at paradise.net.nz (Tortise) Date: Mon, 16 Jul 2007 14:20:50 +1200 Subject: [AccessD] Lock of Record - Memofields References: <20070716120623.CYC21380@dommail.onthenet.com.au> Message-ID: <068501c7c74f$eda05500$1e00a8c0@cheqsoft.local> I'd love to know the answer to this one too! We have an Access 2003 database which does much the same it seems, no SQL backend, problem is intermittent and is almost certainly associated with one memo field which locks after a small number of saves are made in it. The other fields save fine. The kludge we used was to add a second memo onto the form and save subsequent edits to that, which works reliably!!! I posted a long time ago about this but no one came up with a solution that I could work. Kind regards David Hingston ----- Original Message ----- From: To: "Access Developers discussion and problem solving" Sent: Monday, July 16, 2007 2:06 PM Subject: [AccessD] Lock of Record - Memofields Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... This is the setup: Access2003 .mdb with SQL Server2005 Backend. Access .mdb is set to 'no record locks' and so are all Forms. Around 60 Users sitting in the application all day using Terminal Server. All tables odbc linked. There's a main Summary Form with a number of pre-defined filters. The Summary Form is populated using ADO recordset. >From Summary Form User clicks on a record line to access the Detail Form. The Detail Form consists of of a subform control that dynamically loads one of four different subforms. The main form is unbound. Each of the Subforms uses the same record from the same table as source. On the main Form there are four different labels - the click event here loads a particular subform into the subform control. The subform is populated using an ADO recordset call. On the Main Form there are two command buttons: Enter Edit Mode (setting the allow edits property of the Form to Yes) Exit Edit Mode (setting the allow edits property of the Form to No) The subform is always opened in "View Mode", i.e. the allow edits property of the SubForm is set to No. I am using the following record locking scheme : When User is clicking on Enter Edit Mode, code checks the record in question - using ADO call - to see if two fields on the record: "LockedBy" and "LockedDateTime" are null. If they are null, the ADO code updates the two fields with UserName and Current Date Time, and calls the record in again from the table to display on the SubForm currently selected and sets the 'allow edits' to true on the SubForm. The Exit Edit Mode sets the two fields to null and saves the record doing a straight docmd.save. This Exit Edit Mode code is fired before User is leaving the record/form or executing other code than runs an update query on the same record. However, we are encountering the situation where User when exiting the Edit Mode gets the *Access* Lock Message, where User can either drop changes or save changes. User has been instructed to drop changes, which causes the record on the Form to be set back to View Mode with the LockedBy and LockedDateTime Fields still set, resulting in User now 'locking' himself out of the homemade locking scheme. I am pulling out my hair trying to figure out what is causing the built in *Access* Lock Message. I have been over the code in detail making sure that User is not able to create changes to the record while in Edit mode other than via the Form. Other Users can obviously not access the same record via the Form in Edit mode and there is no code in the user interface that runs an update query on the same record. So what is causing the *Access* Lock messages? I searched the AccessD Archives the other day and I suspect the cause might be Memo Fields. If I understand what I read in the AccessD archives correct: Access on records with MemoFields are stil applying page locks and not record locks? There are five memo fields on the record of the table in question. Thank you for reading this far! What's your take on this? Is it the memo fields that are causing this?? What can I do to remedy this situation? The memo fields are basically comments fields. Is this a way to go: Place each comments in separate table in a record with a 255 character field - one to many relationship with main table (and include a comments type field), and on retrieving the main record build up the comments from the associated records into one unbound text control?? Currently the Comments memofield is popuplated and looks like this: 2007-05-23 12:35 jcitizen: Comments Text (vbCrLf) 2007-05-22 15:40 bbrown: Another Comments Text (vbCrLf) in descending date order Regards borge -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From kp at sdsonline.net Sun Jul 15 21:27:13 2007 From: kp at sdsonline.net (Kath Pelletti) Date: Mon, 16 Jul 2007 12:27:13 +1000 Subject: [AccessD] Performance tips anyone? Message-ID: <01fa01c7c750$d2848600$6401a8c0@office> Having been away for a couple of weeks I am late in posting on this topic - there were some great suggestions made. I just wanted to add that in addition to all those things, I speeded up an app of mine by removing record sources of all combos (as previously suggested) and then using code which only populates the combo after the user types in eg. 3 letters. That way, not all data is bound to the combo when it's not needed. ______________________________________ Kath Pelletti From phpons at gmail.com Mon Jul 16 01:29:37 2007 From: phpons at gmail.com (philippe pons) Date: Mon, 16 Jul 2007 08:29:37 +0200 Subject: [AccessD] Talking between Applications. In-Reply-To: <200707152348.l6FNmlBI029468@databaseadvisors.com> References: <200707152348.l6FNmlBI029468@databaseadvisors.com> Message-ID: <57144ced0707152329u6e8676f8iee0b7659562ab429@mail.gmail.com> Hi, I'm curious to have a look at that too ! Philippe 2007/7/16, Darren D : > > Howdy > > Would love to see an example of this > > DD > > -----Original Message----- > From: Drew Wutka [mailto:DWUTKA at marlow.com] > Sent: Saturday, 14 July 2007 9:29 AM > To: Access Developers discussion and problem solving > Subject: [AccessD] Talking between Applications. > > Ya learn something new every day, don't ya? I've been re-writing an > application I built 7 years ago. The new version is already in > production, but I'll be adding new features probably for years to come. > It's a help desk application, and one issue I'm working on is that there > are several things that are 'monitored' events. Some events are > lightning fast, some are a bit slower. The slower ones slow down the > interface a bit, because it's all running in the same .exe. To fix this > I thought about multithreading, but decided on just creating another > application to do the monitoring. So how do you have one application > talk to another? > > > > Before, I have used winsocks to do this. But it involves making socket > connections, etc. This time, I dug into Window Messaging. I've done a > lot of things with windows (in Windows) before, but I had to share this > little tidbit with the List. > > > > To bring everyone up to snuff, every window on your machine has an hWnd > value. That's the ID of each window. Windows sends all sorts of > messages to each window, for every single thing that you do. When you > move the mouse over a window, windows is firing window messages to that > window with the mouse position. Clicking, typing, resizing, redrawing > and more are all sent to the windows through window messages. When you > close an application, that too is a window message. > > > > The fun part is, we can use that same process for our own purposes. > There's a simple API call, called SendMessage, that requires the hWnd of > the window you want to send a message too, the message ID (every process > has a static ID, but you can use RegisterWindowMessage to create your > own messageid (Unique to that particular machine)) and then two > parameters (both long integers). Hey, but wait, if all I can send > between two applications is two integers, what's the point? Well, you > can also create a window on the fly, with a single API, you can then set > it's window text to anything you want, and your recipient applications > can read that window text and destroy the window. > > > > I have this process in place (the communication part, now I'm on to > actually doing something with the comms), and it works great. Virtually > no overhead in the communication process, runs as smoothly as moving a > window across your screen. > > > > If there's interest in something like this, I'll post some code for it. > > > > Drew > > > > > The information contained in this transmission is intended only for the > person > or entity to which it is addressed and may contain II-VI Proprietary > and/or > II-VI BusinessSensitve material. If you are not the intended recipient, > please > contact the sender immediately and destroy the material in its entirety, > whether > electronic or hard copy. You are notified that any review, retransmission, > copying, disclosure, dissemination, or other use of, or taking of any > action in > reliance upon this information by persons or entities other than the > intended > recipient is prohibited. > > > > -- > 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 Mon Jul 16 04:05:57 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 16 Jul 2007 11:05:57 +0200 Subject: [AccessD] Checkbox dates Message-ID: Hi John et al Sorry to disturb the romance, but you all seem to forget that a Checkbox can be set/reset by pressing +/- and toggled by pressing the spacebar. Also, pressing a hotkey combo (Alt + a letter of the associated label) will toggle the Checkbox. I once expanded these keypress options a bit with a subfunction you may call at the OnKeyPress event: Private Sub chkSomeCheckbox_KeyPress(KeyAscii As Integer) Call CheckboxKeyPress(Me!chkSomeCheckbox, KeyAscii) End Sub Sub CheckboxKeyPress(ByRef chk As CheckBox, ByVal bytKeyAscii As Byte) ' Add more key entries than the standard (+, -, and Space) ' to set/reset or toggle the checkbox. ' ' 1998-10-08. Cactus Data ApS Dim booCheck As Boolean Select Case UCase(Chr(bytKeyAscii)) ' List of key entries for set (True). Case "1", "Y", "T", "S", "J" booCheck = True ' List of key entries for reset (False). Case "0", "N", "F", "R" booCheck = False ' List of key entries for toggle. Case "*", "X", "C" booCheck = Not chk.value Case Else ' No change. booCheck = chk.value End Select ' Only change state if needed. If chk.value Xor booCheck Then chk.value = booCheck End If End Sub This - or at least the default OnKeyPress behaviour - could easily be incorporated in the class. /gustav >>> miscellany at mvps.org 15-07-2007 23:21 >>> John, jwcolby wrote: > ... I am content to have > demonstrated how to use a class to encapsulate the behaviors required to > perform this trick and get everyone thinking about classes and Event > handling in classes. I recognise that this was your initial intention, and for this I thank you. Sorry if the discussion went too far off on a tangent. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Mon Jul 16 04:41:01 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 16 Jul 2007 11:41:01 +0200 Subject: [AccessD] Lock of Record - Memofields Message-ID: Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... This is the setup: Access2003 .mdb with SQL Server2005 Backend. Access .mdb is set to 'no record locks' and so are all Forms. Around 60 Users sitting in the application all day using Terminal Server. All tables odbc linked. There's a main Summary Form with a number of pre-defined filters. The Summary Form is populated using ADO recordset. >From Summary Form User clicks on a record line to access the Detail Form. The Detail Form consists of of a subform control that dynamically loads one of four different subforms. The main form is unbound. Each of the Subforms uses the same record from the same table as source. On the main Form there are four different labels - the click event here loads a particular subform into the subform control. The subform is populated using an ADO recordset call. On the Main Form there are two command buttons: Enter Edit Mode (setting the allow edits property of the Form to Yes) Exit Edit Mode (setting the allow edits property of the Form to No) The subform is always opened in "View Mode", i.e. the allow edits property of the SubForm is set to No. I am using the following record locking scheme : When User is clicking on Enter Edit Mode, code checks the record in question - using ADO call - to see if two fields on the record: "LockedBy" and "LockedDateTime" are null. If they are null, the ADO code updates the two fields with UserName and Current Date Time, and calls the record in again from the table to display on the SubForm currently selected and sets the 'allow edits' to true on the SubForm. The Exit Edit Mode sets the two fields to null and saves the record doing a straight docmd.save. This Exit Edit Mode code is fired before User is leaving the record/form or executing other code than runs an update query on the same record. However, we are encountering the situation where User when exiting the Edit Mode gets the *Access* Lock Message, where User can either drop changes or save changes. User has been instructed to drop changes, which causes the record on the Form to be set back to View Mode with the LockedBy and LockedDateTime Fields still set, resulting in User now 'locking' himself out of the homemade locking scheme. I am pulling out my hair trying to figure out what is causing the built in *Access* Lock Message. I have been over the code in detail making sure that User is not able to create changes to the record while in Edit mode other than via the Form. Other Users can obviously not access the same record via the Form in Edit mode and there is no code in the user interface that runs an update query on the same record. So what is causing the *Access* Lock messages? I searched the AccessD Archives the other day and I suspect the cause might be Memo Fields. If I understand what I read in the AccessD archives correct: Access on records with MemoFields are stil applying page locks and not record locks? There are five memo fields on the record of the table in question. Thank you for reading this far! What's your take on this? Is it the memo fields that are causing this?? What can I do to remedy this situation? The memo fields are basically comments fields. Is this a way to go: Place each comments in separate table in a record with a 255 character field - one to many relationship with main table (and include a comments type field), and on retrieving the main record build up the comments from the associated records into one unbound text control?? Currently the Comments memofield is popuplated and looks like this: 2007-05-23 12:35 jcitizen: Comments Text (vbCrLf) 2007-05-22 15:40 bbrown: Another Comments Text (vbCrLf) in descending date order Regards borge From pcs at azizaz.com Mon Jul 16 08:35:00 2007 From: pcs at azizaz.com (Borge Hansen) Date: Mon, 16 Jul 2007 23:35:00 +1000 Subject: [AccessD] Lock of Record - Memofields References: Message-ID: <005a01c7c7ae$1c4a5960$fa10a8c0@Albatross> Hi Gustav, I don't get it .... please explain what the me.dirty = false can do in this context. ... also, I admit I didn't get David's method either... borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Monday, July 16, 2007 7:41 PM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... ...... From Gustav at cactus.dk Mon Jul 16 09:17:32 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 16 Jul 2007 16:17:32 +0200 Subject: [AccessD] Lock of Record - Memofields Message-ID: Hi Borge It tells the form to save the record using the method of the form for this purpose. More precisely, it should look: If Me.Dirty = True Then ' The record has been edited. ' Save the record. Me.Dirty = False End If I'm not saying this is the magic cure. However, DoCmd operations may not always work as expected under stress, and it may be a stress situation when you - at the same time - wish to save a record and move to the next. /gustav >>> pcs at azizaz.com 16-07-2007 15:35 >>> Hi Gustav, I don't get it .... please explain what the me.dirty = false can do in this context. ... also, I admit I didn't get David's method either... borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Monday, July 16, 2007 7:41 PM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... From jwcolby at colbyconsulting.com Mon Jul 16 09:58:51 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 16 Jul 2007 10:58:51 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: Message-ID: <20070716145854.97E81BD2D@smtp-auth.no-ip.com> These methods do not fire the click event? When I test the + and - keys the click event fires. Likewise when pressing the space bar. This is the behavior I expect to happen since these keys emulate a mouse click. So my code works for those three keyboard events. The toggle works as you expect, it toggles the control. MY code also toggles the control using the - and the + whereas yours (hopefully) clears for the - and sets for the +. Unfortunately, making matters worse, BOTH the keypress and the click events happen. The keypress happens first, then the click event happens. So if I "set" the date field in the keypress, then the click event comes along and sees the value set and clears it. If the keypress event clears the event, the click event comes along and sets it. This makes it APPEAR that the keystroke - plus or minus - is doing the OPPOSITE of what it is supposed to do, when in fact it is doing exactly what it is supposed to do. In order to get around this unfortunate "helping hand", I added a flag to track that a KeyPressed occurred (set in KeyPress) and if so do NOT execute the OnClick code (flag always cleared in OnClick). Thus the code morphs to: '********************************************** Option Compare Database Option Explicit ' 'This class uses a check box to set / void a date in a record 'The objective is to allow the form to set a date to date() if a check box is checked 'and set that date to void if the check box is cleared. ' 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID 'and should display a FALSE if the date is VOID ' 'The class functions by passing in an UNBOUND check box which is the visual indicator 'A BOUND text box is passed in which actually stores the state of the flag as a date data type ' 'Thus as the user clicks the check box, this class sets the underlying (and invisible) text box 'The text box VALUE property is set to DATE if the check box displays a TRUE (is checked) 'and the textbox VALUE property is set to NULL if the checkbox displays a FALSE (is not checked) ' Private WithEvents mchk As CheckBox Private mtxt As TextBox Private Const cstrEventProc As String = "[Event Procedure]" Private mblnKeyPressed As Boolean Private Sub Class_Terminate() Set mchk = Nothing Set mtxt = Nothing End Sub Function init(lchk As CheckBox, ltxt As TextBox) Set mchk = lchk mchk.OnClick = cstrEventProc mchk.OnKeyPress = cstrEventProc Set mtxt = ltxt SetChkState End Function ' 'This function causes the text box to track the visual state of the control 'If the user clicks the check box and the check box ends up TRUE then set the text box to Date() 'else set the text box to VOID ' Private Sub mchk_Click() On Error GoTo Err_mchk_Click ' 'KeyPressed occurs first (if it happens) so short circuit the click event handler if KeyPressed ' If Not mblnKeyPressed Then If IsNull(mtxt.Value) Then mtxt.Value = Date Else mtxt.Value = Null End If SetChkState End If mblnKeyPressed = False Exit_mchk_Click: Exit Sub Err_mchk_Click: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" Resume Exit_mchk_Click End Select Resume 0 '.FOR TROUBLESHOOTING End Sub ' 'This sub causes the visual state of the checkbox to track the text box 'If the text box is VOID (no date) then display a FALSE 'else display a TRUE ' Public Sub SetChkState() On Error GoTo Err_SetChkState If IsNull(mtxt.Value) Then mchk.Value = False Else mchk.Value = True End If Exit_SetChkState: Exit Sub Err_SetChkState: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" Resume Exit_SetChkState End Select Resume 0 '.FOR TROUBLESHOOTING End Sub Private Sub mchk_KeyPress(KeyAscii As Integer) Dim bytKeyAscii As Byte bytKeyAscii = CByte(KeyAscii) Select Case Chr(bytKeyAscii) Case "+" If IsNull(mtxt.Value) Then mtxt.Value = Date End If mblnKeyPressed = True Case "-" If Not IsNull(mtxt.Value) Then mtxt.Value = Null End If mblnKeyPressed = True Case Else End Select SetChkState End Sub '********************************************** Notice in particular the new blnKeyPressed flag in the header, the code to SET the flag in mchk_KeyPress ONLY in the case of the + or -, and the code in mchk_Click to not execute the normal click code if the blnKeyPressed flag is set, and always clearing the flag. By my testing this now correctly handles the keyboard issues raised by Gustav. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, July 16, 2007 5:06 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Checkbox dates Hi John et al Sorry to disturb the romance, but you all seem to forget that a Checkbox can be set/reset by pressing +/- and toggled by pressing the spacebar. Also, pressing a hotkey combo (Alt + a letter of the associated label) will toggle the Checkbox. I once expanded these keypress options a bit with a subfunction you may call at the OnKeyPress event: Private Sub chkSomeCheckbox_KeyPress(KeyAscii As Integer) Call CheckboxKeyPress(Me!chkSomeCheckbox, KeyAscii) End Sub Sub CheckboxKeyPress(ByRef chk As CheckBox, ByVal bytKeyAscii As Byte) ' Add more key entries than the standard (+, -, and Space) ' to set/reset or toggle the checkbox. ' ' 1998-10-08. Cactus Data ApS Dim booCheck As Boolean Select Case UCase(Chr(bytKeyAscii)) ' List of key entries for set (True). Case "1", "Y", "T", "S", "J" booCheck = True ' List of key entries for reset (False). Case "0", "N", "F", "R" booCheck = False ' List of key entries for toggle. Case "*", "X", "C" booCheck = Not chk.value Case Else ' No change. booCheck = chk.value End Select ' Only change state if needed. If chk.value Xor booCheck Then chk.value = booCheck End If End Sub This - or at least the default OnKeyPress behaviour - could easily be incorporated in the class. /gustav From cfoust at infostatsystems.com Mon Jul 16 10:06:01 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 16 Jul 2007 08:06:01 -0700 Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected, But Not Displayed In-Reply-To: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> References: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> Message-ID: Opening a data view of an action query may not display anything useful, if that's what you're describing. Or do you mean that you ran the query and got zeros instead of 8s? Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gale Perez Sent: Sunday, July 15, 2007 7:22 PM To: accessd at databaseadvisors.com Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected,But Not Displayed Hello, I'm normalizing a db to replace certain fields with lookup fields. I used the lookup wizard and am storing an autonumber from the lookup table. All updated just fine, except for one. The old field is a text field consisting of the numbers 0-7. I created a query to update the new field (in the example, 8 is the autonumber PK in the lookup table): UPDATE mytable SET mytable.newfield = 8 WHERE (((mytable.[oldfield])="7")); But when I opened the table to verify the new field's data matched that in the old field, I saw that the new field showed nothing but zeros. When I clicked in that field of a particular record, my dropdown box appeared, with the correct value selected - but it is not being displayed! What the heck is going on? Has anyone else had this happen? I tried re-creating both the query and the field, and got the same results. Thank you very much for any thoughts! Gale -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Mon Jul 16 10:29:55 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Mon, 16 Jul 2007 15:29:55 +0000 Subject: [AccessD] Spellcheck from Access to web??? In-Reply-To: Message-ID: Hello All, Wasn't sure what subject to use...I have a web based app(not mine...so any webpage where you type stuff)...I need to spell check the text in a field. There is not a feature in the app. Any ideas on getting RunCommand acCmdSpelling to look at a field on a web page? I know its a little "out there"... Thanks, Mark A. Matte _________________________________________________________________ http://liveearth.msn.com From Gustav at cactus.dk Mon Jul 16 10:41:59 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 16 Jul 2007 17:41:59 +0200 Subject: [AccessD] Checkbox dates Message-ID: Hi John Interesting. I should have tested more carefully, sorry. But since when has a keypress raised an OnClick event? I don't see the relation between these two events. It must be a special case for the checkbox control. But that being so, couldn't you just eat the keypress and skip all the flag stuff? Like: Private Sub mchk_KeyPress(KeyAscii As Integer) KeyAscii = 0 End Sub But no. This eats +/- and the hotkey but not the spacebar. Go figure. /gustav >>> jwcolby at colbyconsulting.com 16-07-2007 16:58 >>> These methods do not fire the click event? When I test the + and - keys the click event fires. Likewise when pressing the space bar. This is the behavior I expect to happen since these keys emulate a mouse click. So my code works for those three keyboard events. The toggle works as you expect, it toggles the control. MY code also toggles the control using the - and the + whereas yours (hopefully) clears for the - and sets for the +. Unfortunately, making matters worse, BOTH the keypress and the click events happen. The keypress happens first, then the click event happens. So if I "set" the date field in the keypress, then the click event comes along and sees the value set and clears it. If the keypress event clears the event, the click event comes along and sets it. This makes it APPEAR that the keystroke - plus or minus - is doing the OPPOSITE of what it is supposed to do, when in fact it is doing exactly what it is supposed to do. In order to get around this unfortunate "helping hand", I added a flag to track that a KeyPressed occurred (set in KeyPress) and if so do NOT execute the OnClick code (flag always cleared in OnClick). Thus the code morphs to: '********************************************** Option Compare Database Option Explicit ' 'This class uses a check box to set / void a date in a record 'The objective is to allow the form to set a date to date() if a check box is checked 'and set that date to void if the check box is cleared. ' 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID 'and should display a FALSE if the date is VOID ' 'The class functions by passing in an UNBOUND check box which is the visual indicator 'A BOUND text box is passed in which actually stores the state of the flag as a date data type ' 'Thus as the user clicks the check box, this class sets the underlying (and invisible) text box 'The text box VALUE property is set to DATE if the check box displays a TRUE (is checked) 'and the textbox VALUE property is set to NULL if the checkbox displays a FALSE (is not checked) ' Private WithEvents mchk As CheckBox Private mtxt As TextBox Private Const cstrEventProc As String = "[Event Procedure]" Private mblnKeyPressed As Boolean Private Sub Class_Terminate() Set mchk = Nothing Set mtxt = Nothing End Sub Function init(lchk As CheckBox, ltxt As TextBox) Set mchk = lchk mchk.OnClick = cstrEventProc mchk.OnKeyPress = cstrEventProc Set mtxt = ltxt SetChkState End Function ' 'This function causes the text box to track the visual state of the control 'If the user clicks the check box and the check box ends up TRUE then set the text box to Date() 'else set the text box to VOID ' Private Sub mchk_Click() On Error GoTo Err_mchk_Click ' 'KeyPressed occurs first (if it happens) so short circuit the click event handler if KeyPressed ' If Not mblnKeyPressed Then If IsNull(mtxt.Value) Then mtxt.Value = Date Else mtxt.Value = Null End If SetChkState End If mblnKeyPressed = False Exit_mchk_Click: Exit Sub Err_mchk_Click: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" Resume Exit_mchk_Click End Select Resume 0 '.FOR TROUBLESHOOTING End Sub ' 'This sub causes the visual state of the checkbox to track the text box 'If the text box is VOID (no date) then display a FALSE 'else display a TRUE ' Public Sub SetChkState() On Error GoTo Err_SetChkState If IsNull(mtxt.Value) Then mchk.Value = False Else mchk.Value = True End If Exit_SetChkState: Exit Sub Err_SetChkState: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" Resume Exit_SetChkState End Select Resume 0 '.FOR TROUBLESHOOTING End Sub Private Sub mchk_KeyPress(KeyAscii As Integer) Dim bytKeyAscii As Byte bytKeyAscii = CByte(KeyAscii) Select Case Chr(bytKeyAscii) Case "+" If IsNull(mtxt.Value) Then mtxt.Value = Date End If mblnKeyPressed = True Case "-" If Not IsNull(mtxt.Value) Then mtxt.Value = Null End If mblnKeyPressed = True Case Else End Select SetChkState End Sub '********************************************** Notice in particular the new blnKeyPressed flag in the header, the code to SET the flag in mchk_KeyPress ONLY in the case of the + or -, and the code in mchk_Click to not execute the normal click code if the blnKeyPressed flag is set, and always clearing the flag. By my testing this now correctly handles the keyboard issues raised by Gustav. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, July 16, 2007 5:06 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Checkbox dates Hi John et al Sorry to disturb the romance, but you all seem to forget that a Checkbox can be set/reset by pressing +/- and toggled by pressing the spacebar. Also, pressing a hotkey combo (Alt + a letter of the associated label) will toggle the Checkbox. I once expanded these keypress options a bit with a subfunction you may call at the OnKeyPress event: Private Sub chkSomeCheckbox_KeyPress(KeyAscii As Integer) Call CheckboxKeyPress(Me!chkSomeCheckbox, KeyAscii) End Sub Sub CheckboxKeyPress(ByRef chk As CheckBox, ByVal bytKeyAscii As Byte) ' Add more key entries than the standard (+, -, and Space) ' to set/reset or toggle the checkbox. ' ' 1998-10-08. Cactus Data ApS Dim booCheck As Boolean Select Case UCase(Chr(bytKeyAscii)) ' List of key entries for set (True). Case "1", "Y", "T", "S", "J" booCheck = True ' List of key entries for reset (False). Case "0", "N", "F", "R" booCheck = False ' List of key entries for toggle. Case "*", "X", "C" booCheck = Not chk.value Case Else ' No change. booCheck = chk.value End Select ' Only change state if needed. If chk.value Xor booCheck Then chk.value = booCheck End If End Sub This - or at least the default OnKeyPress behaviour - could easily be incorporated in the class. /gustav From jwcolby at colbyconsulting.com Mon Jul 16 11:04:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 16 Jul 2007 12:04:23 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: Message-ID: <20070716160426.51A01BDF1@smtp-auth.no-ip.com> Gustav, >But since when has a keypress raised an OnClick event? I know, what a PITA. Furthermore the keypress event (but not the click event) is fired for ANY keypress while the checkbox has the focus including the tab that moves the focus into the checkbox. That is why I just decided to go the "simple route" and sense the + and - and bypass the click event for those two keys press events. Furthermore I couldn't just "eat" the key event because my click event code causes a TOGGLE of the checkbox. If I ate the key event for the + and - then those keys would still cause the click event and cause a toggle instead of the correct "clear for a -" and "set for a +". Anyway, AFAICT my code as last published functions correctly. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, July 16, 2007 11:42 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Checkbox dates Hi John Interesting. I should have tested more carefully, sorry. But since when has a keypress raised an OnClick event? I don't see the relation between these two events. It must be a special case for the checkbox control. But that being so, couldn't you just eat the keypress and skip all the flag stuff? Like: Private Sub mchk_KeyPress(KeyAscii As Integer) KeyAscii = 0 End Sub But no. This eats +/- and the hotkey but not the spacebar. Go figure. /gustav >>> jwcolby at colbyconsulting.com 16-07-2007 16:58 >>> These methods do not fire the click event? When I test the + and - keys the click event fires. Likewise when pressing the space bar. This is the behavior I expect to happen since these keys emulate a mouse click. So my code works for those three keyboard events. The toggle works as you expect, it toggles the control. MY code also toggles the control using the - and the + whereas yours (hopefully) clears for the - and sets for the +. Unfortunately, making matters worse, BOTH the keypress and the click events happen. The keypress happens first, then the click event happens. So if I "set" the date field in the keypress, then the click event comes along and sees the value set and clears it. If the keypress event clears the event, the click event comes along and sets it. This makes it APPEAR that the keystroke - plus or minus - is doing the OPPOSITE of what it is supposed to do, when in fact it is doing exactly what it is supposed to do. In order to get around this unfortunate "helping hand", I added a flag to track that a KeyPressed occurred (set in KeyPress) and if so do NOT execute the OnClick code (flag always cleared in OnClick). Thus the code morphs to: '********************************************** Option Compare Database Option Explicit ' 'This class uses a check box to set / void a date in a record 'The objective is to allow the form to set a date to date() if a check box is checked 'and set that date to void if the check box is cleared. ' 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID 'and should display a FALSE if the date is VOID ' 'The class functions by passing in an UNBOUND check box which is the visual indicator 'A BOUND text box is passed in which actually stores the state of the flag as a date data type ' 'Thus as the user clicks the check box, this class sets the underlying (and invisible) text box 'The text box VALUE property is set to DATE if the check box displays a TRUE (is checked) 'and the textbox VALUE property is set to NULL if the checkbox displays a FALSE (is not checked) ' Private WithEvents mchk As CheckBox Private mtxt As TextBox Private Const cstrEventProc As String = "[Event Procedure]" Private mblnKeyPressed As Boolean Private Sub Class_Terminate() Set mchk = Nothing Set mtxt = Nothing End Sub Function init(lchk As CheckBox, ltxt As TextBox) Set mchk = lchk mchk.OnClick = cstrEventProc mchk.OnKeyPress = cstrEventProc Set mtxt = ltxt SetChkState End Function ' 'This function causes the text box to track the visual state of the control 'If the user clicks the check box and the check box ends up TRUE then set the text box to Date() 'else set the text box to VOID ' Private Sub mchk_Click() On Error GoTo Err_mchk_Click ' 'KeyPressed occurs first (if it happens) so short circuit the click event handler if KeyPressed ' If Not mblnKeyPressed Then If IsNull(mtxt.Value) Then mtxt.Value = Date Else mtxt.Value = Null End If SetChkState End If mblnKeyPressed = False Exit_mchk_Click: Exit Sub Err_mchk_Click: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" Resume Exit_mchk_Click End Select Resume 0 '.FOR TROUBLESHOOTING End Sub ' 'This sub causes the visual state of the checkbox to track the text box 'If the text box is VOID (no date) then display a FALSE 'else display a TRUE ' Public Sub SetChkState() On Error GoTo Err_SetChkState If IsNull(mtxt.Value) Then mchk.Value = False Else mchk.Value = True End If Exit_SetChkState: Exit Sub Err_SetChkState: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" Resume Exit_SetChkState End Select Resume 0 '.FOR TROUBLESHOOTING End Sub Private Sub mchk_KeyPress(KeyAscii As Integer) Dim bytKeyAscii As Byte bytKeyAscii = CByte(KeyAscii) Select Case Chr(bytKeyAscii) Case "+" If IsNull(mtxt.Value) Then mtxt.Value = Date End If mblnKeyPressed = True Case "-" If Not IsNull(mtxt.Value) Then mtxt.Value = Null End If mblnKeyPressed = True Case Else End Select SetChkState End Sub '********************************************** Notice in particular the new blnKeyPressed flag in the header, the code to SET the flag in mchk_KeyPress ONLY in the case of the + or -, and the code in mchk_Click to not execute the normal click code if the blnKeyPressed flag is set, and always clearing the flag. By my testing this now correctly handles the keyboard issues raised by Gustav. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, July 16, 2007 5:06 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Checkbox dates Hi John et al Sorry to disturb the romance, but you all seem to forget that a Checkbox can be set/reset by pressing +/- and toggled by pressing the spacebar. Also, pressing a hotkey combo (Alt + a letter of the associated label) will toggle the Checkbox. I once expanded these keypress options a bit with a subfunction you may call at the OnKeyPress event: Private Sub chkSomeCheckbox_KeyPress(KeyAscii As Integer) Call CheckboxKeyPress(Me!chkSomeCheckbox, KeyAscii) End Sub Sub CheckboxKeyPress(ByRef chk As CheckBox, ByVal bytKeyAscii As Byte) ' Add more key entries than the standard (+, -, and Space) ' to set/reset or toggle the checkbox. ' ' 1998-10-08. Cactus Data ApS Dim booCheck As Boolean Select Case UCase(Chr(bytKeyAscii)) ' List of key entries for set (True). Case "1", "Y", "T", "S", "J" booCheck = True ' List of key entries for reset (False). Case "0", "N", "F", "R" booCheck = False ' List of key entries for toggle. Case "*", "X", "C" booCheck = Not chk.value Case Else ' No change. booCheck = chk.value End Select ' Only change state if needed. If chk.value Xor booCheck Then chk.value = booCheck End If End Sub This - or at least the default OnKeyPress behaviour - could easily be incorporated in the class. /gustav -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Mon Jul 16 11:41:45 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Mon, 16 Jul 2007 16:41:45 +0000 Subject: [AccessD] Access 2007: Lookup Field Shows Correct ValueSelected, But Not Displayed In-Reply-To: Message-ID: In the table properties...how many columns are in the rowsource of your lookup...and what are your column widths? Thanks, Mark A. Matte >From: "Charlotte Foust" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Access 2007: Lookup Field Shows Correct >ValueSelected, But Not Displayed >Date: Mon, 16 Jul 2007 08:06:01 -0700 > >Opening a data view of an action query may not display anything useful, >if that's what you're describing. Or do you mean that you ran the query >and got zeros instead of 8s? > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gale Perez >Sent: Sunday, July 15, 2007 7:22 PM >To: accessd at databaseadvisors.com >Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value >Selected,But Not Displayed > >Hello, > >I'm normalizing a db to replace certain fields with lookup fields. I >used the lookup wizard and am storing an autonumber from the lookup >table. All updated just fine, except for one. The old field is a text >field consisting of the numbers 0-7. I created a query to update the >new field (in the example, 8 is the autonumber PK in the lookup table): > >UPDATE mytable SET mytable.newfield = 8 >WHERE (((mytable.[oldfield])="7")); > >But when I opened the table to verify the new field's data matched that >in the old field, I saw that the new field showed nothing but zeros. >When I clicked in that field of a particular record, my dropdown box >appeared, with >the correct value selected - but it is not being displayed! What the >heck >is going on? Has anyone else had this happen? > >I tried re-creating both the query and the field, and got the same >results. > >Thank you very much for any thoughts! >Gale >-- >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 _________________________________________________________________ Need a brain boost? Recharge with a stimulating game. Play now!? http://club.live.com/home.aspx?icid=club_hotmailtextlink1 From miscellany at mvps.org Mon Jul 16 12:20:04 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 17 Jul 2007 05:20:04 +1200 Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected, But Not Displayed In-Reply-To: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> References: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> Message-ID: <469BA8C4.9070708@mvps.org> Gale, You may be interested in this article: http://www.mvps.org/access/lookupfields.htm Regards Steve Gale Perez wrote: > Hello, > > I'm normalizing a db to replace certain fields with lookup fields. I used > the lookup wizard and am storing an autonumber from the lookup table. All > updated just fine, except for one. The old field is a text field consisting > of the numbers 0-7. I created a query to update the new field (in the > example, 8 is the autonumber PK in the lookup table): > > UPDATE mytable SET mytable.newfield = 8 > WHERE (((mytable.[oldfield])="7")); > > But when I opened the table to verify the new field's data matched that in > the old field, I saw that the new field showed nothing but zeros. When I > clicked in that field of a particular record, my dropdown box appeared, with > the correct value selected - but it is not being displayed! What the heck > is going on? Has anyone else had this happen? > > I tried re-creating both the query and the field, and got the same results. > > Thank you very much for any thoughts! > Gale From galeper at gmail.com Mon Jul 16 12:36:36 2007 From: galeper at gmail.com (Gale Perez) Date: Mon, 16 Jul 2007 10:36:36 -0700 Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected, But Not Displayed In-Reply-To: References: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> Message-ID: <5b2621db0707161036oad3c521l1a090e38f15ef918@mail.gmail.com> Hi Charlotte, I ran the query, and when I opened the table (not the query results), it showed all zeros. Yet when I clicked in the field, the dropdown box showed that the correct value was selected (highlighted), it just isn't being displayed. Thank you, Gale On 7/16/07, Charlotte Foust wrote: > > Opening a data view of an action query may not display anything useful, > if that's what you're describing. Or do you mean that you ran the query > and got zeros instead of 8s? > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gale Perez > Sent: Sunday, July 15, 2007 7:22 PM > To: accessd at databaseadvisors.com > Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value > Selected,But Not Displayed > > Hello, > > I'm normalizing a db to replace certain fields with lookup fields. I > used the lookup wizard and am storing an autonumber from the lookup > table. All updated just fine, except for one. The old field is a text > field consisting of the numbers 0-7. I created a query to update the > new field (in the example, 8 is the autonumber PK in the lookup table): > > UPDATE mytable SET mytable.newfield = 8 > WHERE (((mytable.[oldfield])="7")); > > But when I opened the table to verify the new field's data matched that > in the old field, I saw that the new field showed nothing but zeros. > When I clicked in that field of a particular record, my dropdown box > appeared, with > the correct value selected - but it is not being displayed! What the > heck > is going on? Has anyone else had this happen? > > I tried re-creating both the query and the field, and got the same > results. > > Thank you very much for any thoughts! > Gale > -- > 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 DWUTKA at Marlow.com Mon Jul 16 16:52:08 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:52:08 -0500 Subject: [AccessD] Sample Of Talking between applications WAS(Talking between Applications.) In-Reply-To: <29f585dd0707131641k49abbb2dud087ac3c605a81a2@mail.gmail.com> Message-ID: Ok, I have gotten to a point with the code where I can give you a sample. After this, my code is going to be very specific for the application I'm working on. I broke the system down to 3 class modules, one basic module, and a form. Here's what the components do: (the system I'm working on is the ISFE (Information Services Front End, so that's why I have things prefixed,etc with ISFE). Class: ISFEMessage: This is a class used to manage the data sent between applications. It has a message type, data collection, etc. Messaging through windows only allows two Long Integer parameters. This class creates a 'temp' window to allow for the transfer of more information (text). So it has code to create, read and destroy that temp window, and it breaks the data into a collection to be used. In my sample, the first parameter is used as the message type, the second can be used as a single datapoint, for instance, one of the things the ISFE Monitor (application I am building to support the ISFE) is going to do, is monitor for new requests. When it finds a new request, it can message the ISFE with just the Ticket Number (which is a long integer), so it doesn't need the 'temp' window process. Class: ISFEMessaging: This class is the core messaging class. It creates a window to subclass and monitor for windows messages. The first line in it's initialization code registers a unique windows message "ISFEMessage". That string can be anything. You could have 2 different systems that register their own unique message ID, and the same code will only pick up it's particular window messages. Class: ISFEMonitoring: This class does the work for messages coming through. The demo just has code for a 'pulse' which justs sends dummy messages back and for. Module: SubClassingHook: This module has a global variable for an instance of ISFEMessaging, and then has the callback procedure to hook the window used in ISFEMessaging. Form: Just sample code to show how to use the above four objects. I'll send an email with the source for each of these. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 13, 2007 6:42 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Talking between Applications. I've done something similar a few years back in PowerBuilder, but would love a look at your method. I don't have any immediate use for it, but this old dog does like to learn occasional new tricks. Arthur The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:55:23 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:55:23 -0500 Subject: [AccessD] ISFEMessage Class (talking between applications) Message-ID: Option Explicit Private Declare Function CreateWindowEx Lib "user32" Alias "CreateWindowExA" (ByVal dwExStyle As Long, ByVal lpClassName As String, ByVal lpWindowName As String, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As Long, ByVal hMenu As Long, ByVal hInstance As Long, lpParam As Any) As Long Private Declare Function DestroyWindow Lib "user32" (ByVal hwnd As Long) As Long Private Declare Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hwnd As Long, ByVal lpString As String, ByVal cch As Long) As Long Private Declare Function SetWindowText Lib "user32" Alias "SetWindowTextA" (ByVal hwnd As Long, ByVal lpString As String) As Long Private Const HWND_BROADCAST = &HFFFF& Dim strType As String Dim DataCollection As Collection Dim DataNames As Collection Public FirstParameter As Long Public SecondParameter As Long Property Get DataCount() As Long DataCount = DataNames.Count End Property Property Get DataInfo(strName As String) As String DataInfo = DataCollection(strName) End Property Public Function AddData(ByVal strDataName As String, ByVal strData As String) On Error Resume Next DataCollection.Remove strDataName DataNames.Remove strDataName DataCollection.Add strData, strDataName DataNames.Add strDataName End Function Private Function GetStringSegment(ByRef strData As String) As String Dim intLength As Long intLength = Asc(Left(strData, 1)) GetStringSegment = Mid(strData, 2, intLength) strData = Mid(strData, intLength + 2) End Function Private Function CreateStringSegment(ByVal strToCreate As String) As String If Len(strToCreate) > 255 Then strToCreate = Left(strToCreate, 255) CreateStringSegment = Chr(Len(strToCreate)) & strToCreate End Function Private Function SetDataToWindow() As Long Dim strDataToSend As String Dim inthWndOfWindow As Long Dim i As Long strDataToSend = CreateStringSegment(Me.MessageType) strDataToSend = strDataToSend & CreateStringSegment("" & SecondParameter) For i = 1 To DataCollection.Count strDataToSend = strDataToSend & CreateStringSegment(DataNames(i)) & CreateStringSegment(DataCollection(i)) Next i FirstParameter = -3 SecondParameter = CreateWindowEx(0, "STATIC", strDataToSend, 0, 0, 0, 0, 0, 0, 0, App.hInstance, ByVal 0&) imMessaging.SendISFEMessage imMessaging.ISFE2007hWnd, FirstParameter, SecondParameter End Function Private Sub Class_Initialize() Set DataCollection = New Collection Set DataNames = New Collection End Sub Private Sub Class_Terminate() Set DataCollection = Nothing Set DataNames = Nothing End Sub Property Get MessageType() As String MessageType = strType End Property Public Function ProcessIncomingData() Select Case FirstParameter Case -2 strType = "Handshake" Case -1 strType = "Pulse" Case 1 strType = "NewRequest" 'This is for the ISFE Case -3 Dim strText As String Dim strName As String Dim strData As String Dim intLen As Long intLen = 256 ^ 2 strText = Space(intLen) intLen = GetWindowText(SecondParameter, strText, intLen) If intLen > 0 Then strText = Left(strText, intLen) strType = GetStringSegment(strText) SecondParameter = CLng(GetStringSegment(strText)) Do Until strText = "" strName = GetStringSegment(strText) strData = GetStringSegment(strText) DataCollection.Add strData, strName DataNames.Add strName Loop End If DestroyWindow SecondParameter End Select End Function Property Let MessageType(strEnter As String) strType = strEnter Select Case strType Case "Handshake" FirstParameter = -2 Case "Pulse" FirstParameter = -1 Case "NewRequest" FirstParameter = 1 End Select End Property Public Function SendData() If DataCollection.Count = 0 Then imMessaging.SendISFEMessage imMessaging.ISFE2007hWnd, FirstParameter, SecondParameter Else SetDataToWindow End If End Function Public Function BroadcastData() imMessaging.SendISFEMessage HWND_BROADCAST, FirstParameter, SecondParameter End Function The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:55:54 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:55:54 -0500 Subject: [AccessD] ISFEMessaging Class (talking between applications) Message-ID: Option Explicit Private Declare Function CreateWindowEx Lib "user32" Alias "CreateWindowExA" (ByVal dwExStyle As Long, ByVal lpClassName As String, ByVal lpWindowName As String, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As Long, ByVal hMenu As Long, ByVal hInstance As Long, lpParam As Any) As Long Private Declare Function DestroyWindow Lib "user32" (ByVal hwnd As Long) As Long Private Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long Private Declare Function RegisterWindowMessage Lib "user32" Alias "RegisterWindowMessageA" (ByVal lpString As String) As Long Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long Const GWL_WNDPROC = -4 Public PreviousHwnd As Long Public ISFE2007hWnd As Long Dim intMessageHookHwnd As Long Dim intISFEMessageID As Long Event ISFEMessage(im As ISFEMessage) Event HandshakeCompleted(intRemoteHwnd As Long) Private Sub Class_Initialize() intISFEMessageID = RegisterWindowMessage("ISFEMessage") intMessageHookHwnd = CreateWindowEx(0, "STATIC", "", 0, 0, 0, 0, 0, 0, 0, App.hInstance, ByVal 0&) PreviousHwnd = SetWindowLong(intMessageHookHwnd, GWL_WNDPROC, AddressOf WindowProc) End Sub Public Function IncomingWindowMessage(intMessage As Long, intWParameter As Long, intLParameter As Long) Select Case intMessage Case intISFEMessageID Dim im As ISFEMessage Set im = New ISFEMessage im.FirstParameter = intWParameter im.SecondParameter = intLParameter im.ProcessIncomingData If Not ProcessMessage(im) Then RaiseEvent ISFEMessage(im) Set im = Nothing End Select End Function Private Sub Class_Terminate() Dim dwReturn As Long dwReturn = SetWindowLong(intMessageHookHwnd, GWL_WNDPROC, PreviousHwnd) DestroyWindow intMessageHookHwnd End Sub Public Function SendISFEMessage(ByVal inthWnd As Long, ByVal intParameter1 As Long, ByVal intParameter2 As Long) SendMessage inthWnd, intISFEMessageID, intParameter1, intParameter2 End Function Public Function Handshake() Dim im As ISFEMessage Set im = New ISFEMessage im.MessageType = "Handshake" im.SecondParameter = intMessageHookHwnd im.BroadcastData Set im = Nothing End Function Private Function ProcessMessage(im As ISFEMessage) As Boolean ProcessMessage = True Select Case im.MessageType Case "Handshake" If im.SecondParameter <> intMessageHookHwnd Then If Me.ISFE2007hWnd = 0 Then Me.ISFE2007hWnd = im.SecondParameter im.SecondParameter = intMessageHookHwnd im.SendData RaiseEvent HandshakeCompleted(Me.ISFE2007hWnd) End If End If Case Else ProcessMessage = False End Select End Function The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:56:36 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:56:36 -0500 Subject: [AccessD] ISFEMonitoring Class (talking between applications) Message-ID: Option Explicit Dim WithEvents tmrMessages As Timer Dim Messages As Collection Dim WithEvents Messaging As ISFEMessaging Event MonitoringEvent(strTextToDisplay As String) Private Sub Class_Initialize() Set Messages = New Collection Set tmrMessages = frmMain.tmrMessages Set Messaging = imMessaging End Sub Private Sub Class_Terminate() Set Messages = Nothing Set tmrMessages = Nothing Set Messaging = Nothing End Sub Private Sub Messaging_HandshakeCompleted(intRemoteHwnd As Long) RaiseEvent MonitoringEvent("Handshake Complete with hWnd: " & intRemoteHwnd) End Sub Private Sub Messaging_ISFEMessage(im As ISFEMessage) Messages.Add im tmrMessages.Enabled = True End Sub Private Sub tmrMessages_Timer() Dim im As ISFEMessage Do Until Messages.Count = 0 Set im = Messages(1) ProcessMessage im Messages.Remove (1) Loop tmrMessages.Enabled = False End Sub Private Function ProcessMessage(im As ISFEMessage) Select Case im.MessageType Case "Pulse" RaiseEvent MonitoringEvent("Pulse: " & im.SecondParameter & " - " & im.DataInfo("CurrentTime")) If im.SecondParameter > 0 Then im.SecondParameter = im.SecondParameter - 1 im.AddData "CurrentTime", "Time: " & Format(Time, "dd/mm/yyyy hh:mm:ss") im.SendData Set im = Nothing End If End Select End Function The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:57:25 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:57:25 -0500 Subject: [AccessD] modSubClassHooking Module (talking between applications) Message-ID: Option Explicit Private Declare Function CallWindowProc Lib "user32" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hwnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long Public imMessaging As ISFEMessaging Public Function WindowProc(ByVal hw As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long WindowProc = CallWindowProc(imMessaging.PreviousHwnd, hw, uMsg, wParam, lParam) imMessaging.IncomingWindowMessage uMsg, wParam, lParam End Function The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:58:24 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:58:24 -0500 Subject: [AccessD] frmMain Form (Talking between applications) Message-ID: Option Explicit Dim WithEvents ISFEMon As ISFEMonitoring Private Sub cmdHandshake_Click() imMessaging.Handshake End Sub Private Sub cmdPulse_Click() Dim im As ISFEMessage Set im = New ISFEMessage im.MessageType = "Pulse" im.SecondParameter = 1000 im.AddData "CurrentTime", "Time: " & Format(Time, "dd/mm/yyyy hh:mm:ss") im.SendData Set im = Nothing End Sub Private Sub Form_Load() Me.Caption = Me.hwnd Set imMessaging = New ISFEMessaging Set ISFEMon = New ISFEMonitoring End Sub Private Sub Form_Unload(Cancel As Integer) Set ISFEMon = Nothing Set imMessaging = Nothing End Sub Private Sub ISFEMon_MonitoringEvent(strTextToDisplay As String) Me.lstData.AddItem strTextToDisplay, 0 End Sub The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 17:09:32 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 17:09:32 -0500 Subject: [AccessD] Talking between Applications (final notes) Message-ID: Just an FYI, the code I have posted is in use in VB 6. It should work fine with Access VBA, but I know there will be two quirks. First, the ISFEMonitoring class uses frmMain's timer, the code will have to be changed for that, because Access forms have the timers as a native object, instead of a separate object. The timer is used to allow the windows messaging API's to completely finish before trying to do something with the message that came through. During testing, without this process in place, when I ran a 'pulse', it would run about 80 times before the code would just stop. No errors, it just stopped sending, because the code was firing messages back and forth without letting each progressive message finish on it's own. So instead of working the with message immediately, it's added to a collection, and the timer is used to kick start the process of working with the messages. The other quirk is that frmMain is adding messages to a listbox, in VB, you can just use an AddItem method, can't do that with an Access listbox. So another method should be used to display message results. There is also functionality that isn't used in the sample. The ISFEMessage has two ways it can be sent. SendMessage and BroadcastMessage. To use sendmessage, the ISFEMonitoring class must handshake, so it can find the hWnd of the window it's supposed to communicate with. It only needs to handshake once, then SendMessage will send messages back and forth between the same two applications. (which is what the pulse 'test' process does). BroadcastMessage (which I don't demo with the form) sends a message to EVERY window out there. Note, I only have it working for sending a long integer (through the SecondParameter) value of the ISFEMessage class. To broadcast other data, the receiving windows would have to NOT destroy the data window. I don't need this capability, so I didn't setup my code to do this. One ideas, if broadcasting text data is necessary, would be to just create a single 'data' window, and keep it open while the class is in use, then destroy it when the ISFEMessaging class terminates. Keep in mind, the window being used would be hidden from a user's desktop, but can be viewed with all sorts of utilities. (Which is why I destroy the window in the 1 to 1 process I have setup). Okey dokey, hope someone finds some use for this, I'm off to starting putting it into my actual application. Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From martyconnelly at shaw.ca Mon Jul 16 17:38:42 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Mon, 16 Jul 2007 15:38:42 -0700 Subject: [AccessD] Info: Microsoft to offer code protection, validation to software developers In-Reply-To: <005401cb255b$d1b7dad0$48619a89@DDICK> References: <40F80AD8.18919.6D50350@lexacorp.com.pg> <005401cb255b$d1b7dad0$48619a89@DDICK> Message-ID: <469BF372.8050609@shaw.ca> Microsoft to offer code protection, validation to other software developers The first release covers .Net then Win32 exe, Don't know if it will cover VBA http://blogs.zdnet.com/microsoft/?p=575&tag=nl.e539 http://www.microsoft.com/presspass/features/2007/jul07/07-10slpservices.mspx?rss_fdn=Top%20Stories The first is the Code Protector SDK. This is a software development toolkit with an intuitive user interface, application programming interfaces (APIs) and code samples, which will be available at no charge from the Microsoft Download Center. A version of it will also be included in the next version of Visual Studio, code-named ?Orcas.? This toolkit is specifically designed to help protect and fully transform managed code or .NET code. Full code transformation for Win32, or native code, is on our product roadmap and will be coming soon, but licensing and activation of native code applications will be available with the first release. The Code Protector SDK also allows developers to easily mark features as ?licensable entities? that can later be controlled through various kinds of digital licenses, as well as providing client-side protection of those licenses. Next a server product, the Software Licensing and Protection Server, in standard and enterprise editions. These allow the ISV to host their own servers, create licenses for their products and offer them in very flexible scenarios, either directly or through partners. SLP Services enables simple creation of machine-based licenses, time-based licenses for subscription models and trials, user-based licenses for roaming, as well as feature-based licenses ? supporting a wide range of business models. The third major feature is the SLP Online Service. This option allows partners to do all of their license management without hosting their own servers. We have three different levels of service available on a yearly subscription basis. Starting in October, all MSDN Premium subscription members will get a free subscription to the SLP Online Service Basic edition. -- Marty Connelly Victoria, B.C. Canada From accessd666 at yahoo.com Tue Jul 17 01:51:50 2007 From: accessd666 at yahoo.com (Sad Der) Date: Mon, 16 Jul 2007 23:51:50 -0700 (PDT) Subject: [AccessD] Conditional Compilation ADP 2002? Message-ID: <672443.1350.qm@web31615.mail.mud.yahoo.com> Hi, I want to use conditional compilation in a project. If i'm debugging the code some parts are not allowed to run. But it doesn't seem to work... I created a Mod with a public var: Public gbooConditionalCompilation As Boolean In my form I have the following code: #If gbooConditionalCompilation Then MsgBox "We are debugging this sht" #End If before I come to this point I set (in immediate window) the global boolean to true: gbooConditionalCompilation = True I think i'm making a massive error somewhere...any thoughts? Thnx ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From jwcolby at colbyconsulting.com Tue Jul 17 07:44:33 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 17 Jul 2007 08:44:33 -0400 Subject: [AccessD] Conditional Compilation ADP 2002? In-Reply-To: <672443.1350.qm@web31615.mail.mud.yahoo.com> Message-ID: <20070717124436.2D4A9BCEC@smtp-auth.no-ip.com> Global conditional compilation only works if the conditional constant is at the database level. Any conditional constants defined in a module are only valid for that module. To set a global constant: 1) Open any database 2) Open any module 3) Tools / MyDatabaseName Properties 4) Set the conditional compilation arguments text box there Conditional compilation arguments are NOT regular constants or variables. They have to be declared with a #const keyword: #const gbooConditionalCompilation = True Even then, this is only valid in the module in which it is declared. The only way to get a GLOBAL variable is the process discussed above. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der Sent: Tuesday, July 17, 2007 2:52 AM To: Acces User Group Subject: [AccessD] Conditional Compilation ADP 2002? Hi, I want to use conditional compilation in a project. If i'm debugging the code some parts are not allowed to run. But it doesn't seem to work... I created a Mod with a public var: Public gbooConditionalCompilation As Boolean In my form I have the following code: #If gbooConditionalCompilation Then MsgBox "We are debugging this sht" #End If before I come to this point I set (in immediate window) the global boolean to true: gbooConditionalCompilation = True I think i'm making a massive error somewhere...any thoughts? Thnx ____________________________________________________________________________ ________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bgoss711 at ameritech.net Tue Jul 17 08:23:49 2007 From: bgoss711 at ameritech.net (Bud Goss) Date: Tue, 17 Jul 2007 06:23:49 -0700 (PDT) Subject: [AccessD] Set Warnings Problem - Environment Access 2003 Message-ID: <715394.76976.qm@web81301.mail.mud.yahoo.com> Set Warnings problem - Environment Access 2003 A problem has recently developed on one of my PCs I can not get any warning messages to display when running delete, update, append or Make-table queries. I use docmd.setwarnings = true - Immediately followed by execution of the query The query runs and does the update etc., but there are no warning messages. The same problem (No Warning Message) occurs when I run the query by just double clicking on it This problem occurs on all Access 2003 databases run on this machine. If I use a different machine with the same query with the same database I get the warning messages. Access 2003 has been re-installed on this PC but the problem continues to occur. But the problem does not occur on Access97 databases. Is there some environment setting that I inadvertently changed? If so, what is it? Any advice would be appreciated. From ssharkins at setel.com Tue Jul 17 11:19:32 2007 From: ssharkins at setel.com (Susan Harkins) Date: Tue, 17 Jul 2007 12:19:32 -0400 Subject: [AccessD] Set Warnings Problem - Environment Access 2003 In-Reply-To: <715394.76976.qm@web81301.mail.mud.yahoo.com> References: <715394.76976.qm@web81301.mail.mud.yahoo.com> Message-ID: <002a01c7c88e$4a80ba50$61b82ad1@SusanOne> Check the Edit/Find tab in Options -- perhaps someone unchecked the manual settings. Susan H. Set Warnings problem - Environment Access 2003 A problem has recently developed on one of my PCs I can not get any warning messages to display when running delete, update, append or Make-table queries. I use docmd.setwarnings = true - Immediately followed by execution of the query The query runs and does the update etc., but there are no warning messages. The same problem (No Warning Message) occurs when I run the query by just double clicking on it This problem occurs on all Access 2003 databases run on this machine. If I use a different machine with the same query with the same database I get the warning messages. Access 2003 has been re-installed on this PC but the problem continues to occur. But the problem does not occur on Access97 databases. Is there some environment setting that I inadvertently changed? If so, what is it? Any advice would be appreciated. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 2007/07/15 02:21 PM From bgoss711 at ameritech.net Tue Jul 17 13:19:37 2007 From: bgoss711 at ameritech.net (Bud Goss) Date: Tue, 17 Jul 2007 11:19:37 -0700 (PDT) Subject: [AccessD] Set Warnings problem - Environment Access 2003 - Solved Thank you Message-ID: <660053.99904.qm@web81313.mail.mud.yahoo.com> Yes that was it - The Action Queries confirm box was unchecked Thank You, Thank You, Thank you Check the Edit/Find tab in Options -- perhaps someone unchecked the manual settings. Susan H. >>>Set Warnings problem - Environment Access 2003 A problem has recently developed on one of my PCs I can not get any warning messages to display when running delete, update, append or Make-table queries. I use docmd.setwarnings = true - Immediately followed by execution of the query The query runs and does the update etc., but there are no warning messages. The same problem (No Warning Message) occurs when I run the query by just double clicking on it This problem occurs on all Access 2003 databases run on this machine. If I use a different machine with the same query with the same database I get the warning messages. Access 2003 has been re-installed on this PC but the problem continues to occur. But the problem does not occur on Access97 databases. Is there some environment setting that I inadvertently changed? If so,what is it? Any advice would be appreciated. From markamatte at hotmail.com Tue Jul 17 14:48:40 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 17 Jul 2007 19:48:40 +0000 Subject: [AccessD] Require password for linked MDB tables In-Reply-To: <660053.99904.qm@web81313.mail.mud.yahoo.com> Message-ID: Hello All, Can I have an MDB linked to a seperate MDB(with password)...and have the user required to enter just a password to view the linked table each time? And is it different in different versions? Thanks, Mark A. Matte >From: Bud Goss >Reply-To: Access Developers discussion and problem >solving >To: accessd at databaseadvisors.com >Subject: [AccessD] Set Warnings problem - Environment Access 2003 - >SolvedThank you >Date: Tue, 17 Jul 2007 11:19:37 -0700 (PDT) > > > > > >Yes that was it - The Action Queries confirm box was unchecked > >Thank You, Thank You, Thank you > > >Check the Edit/Find tab in Options -- perhaps someone unchecked the manual >settings. > >Susan H. > > >>>Set Warnings problem - Environment Access 2003 > > A problem has recently developed on one of my PCs > > I can not get any warning messages to display when running delete, > > update, append or Make-table queries. > > I use docmd.setwarnings = true - Immediately followed by execution of > > the query > > The query runs and does the update etc., but there are no warning >messages. > > The same problem (No Warning Message) occurs when I run the query by >just > >double clicking on it > > This problem occurs on all Access 2003 databases run on this machine. > > If I use a different machine with the same query with the same database I > > get the warning messages. Access 2003 has been re-installed on this PC >but the > >problem continues to occur. > > But the problem does not occur on Access97 databases. > > Is there some environment setting that I inadvertently changed? If > > so,what is it? > > Any advice would be appreciated. > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 From pcs at azizaz.com Tue Jul 17 17:03:10 2007 From: pcs at azizaz.com (Borge Hansen) Date: Wed, 18 Jul 2007 08:03:10 +1000 Subject: [AccessD] Lock of Record - Memofields References: Message-ID: <025301c7c8be$446d1750$fa10a8c0@Albatross> Gustav, Never knew that doing a me.dirty = false actually saves the record on the Form I mentioned in my first email that I would save the record on the form with a docmd.save. What I meant was : docmd.runcommand accmdsaverecord Is a me.dirty = false preferable to a docmd.runcommand accmdsaverecord ? regards borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Tuesday, July 17, 2007 12:17 AM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge It tells the form to save the record using the method of the form for this purpose. More precisely, it should look: If Me.Dirty = True Then ' The record has been edited. ' Save the record. Me.Dirty = False End If I'm not saying this is the magic cure. However, DoCmd operations may not always work as expected under stress, and it may be a stress situation when you - at the same time - wish to save a record and move to the next. /gustav >>> pcs at azizaz.com 16-07-2007 15:35 >>> Hi Gustav, I don't get it .... please explain what the me.dirty = false can do in this context. ... also, I admit I didn't get David's method either... borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Monday, July 16, 2007 7:41 PM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.1/778 - Release Date: 4/27/2007 1:39 PM From Gustav at cactus.dk Wed Jul 18 03:16:52 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Wed, 18 Jul 2007 10:16:52 +0200 Subject: [AccessD] Lock of Record - Memofields Message-ID: Hi Borge Yes, setting Me.Dirty is preferable. It tells the form to save the current record, while DoCmd.RunCommand tells the application to tell the active form to save its current record. /gustav >>> pcs at azizaz.com 18-07-2007 00:03 >>> Gustav, Never knew that doing a me.dirty = false actually saves the record on the Form I mentioned in my first email that I would save the record on the form with a docmd.save. What I meant was : docmd.runcommand accmdsaverecord Is a me.dirty = false preferable to a docmd.runcommand accmdsaverecord ? regards borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Tuesday, July 17, 2007 12:17 AM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge It tells the form to save the record using the method of the form for this purpose. More precisely, it should look: If Me.Dirty = True Then ' The record has been edited. ' Save the record. Me.Dirty = False End If I'm not saying this is the magic cure. However, DoCmd operations may not always work as expected under stress, and it may be a stress situation when you - at the same time - wish to save a record and move to the next. /gustav >>> pcs at azizaz.com 16-07-2007 15:35 >>> Hi Gustav, I don't get it .... please explain what the me.dirty = false can do in this context. ... also, I admit I didn't get David's method either... borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Monday, July 16, 2007 7:41 PM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... From paul.hartland at fsmail.net Wed Jul 18 06:09:37 2007 From: paul.hartland at fsmail.net (paul.hartland at fsmail.net) Date: Wed, 18 Jul 2007 13:09:37 +0200 (CEST) Subject: [AccessD] Access/VB using Infragistics Ultragrid Message-ID: <11606970.1029431184756977786.JavaMail.www@wwinf3107> To all, Anyone used the Infragistics Ultragrid control using valuelists in Access or VB and how t limit to the list ? Thanks in advance for any help on this Paul Hartland paul.hartland at fsmail.net 07730 523179 From jwcolby at colbyconsulting.com Wed Jul 18 09:23:32 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 10:23:32 -0400 Subject: [AccessD] DSNs Message-ID: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com From ssharkins at setel.com Wed Jul 18 10:10:01 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 11:10:01 -0400 Subject: [AccessD] Access 2007 question about maximized forms Message-ID: <000d01c7c94d$b967a270$d432fad1@SusanOne> Maximized forms open behind the Navigation Pane -- that means part of the form is blocked. I think it would be neat to work with the pane open, without blocking the maximized form -- forcing Access to adjust the maximized "size" if the pane is open -- is that possible? Susan H. From jimdettman at verizon.net Wed Jul 18 11:41:49 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 18 Jul 2007 12:41:49 -0400 Subject: [AccessD] DSNs In-Reply-To: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> References: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> Message-ID: <003301c7c95a$8a935720$8abea8c0@XPS> John, 1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. 2. Redefine a single DSN. 3. Provide all the connection information in the .Connect property and go DSN less. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bhjohnson at verizon.net Wed Jul 18 11:47:35 2007 From: bhjohnson at verizon.net (Bruce H. Johnson) Date: Wed, 18 Jul 2007 09:47:35 -0700 Subject: [AccessD] DSNs In-Reply-To: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> References: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> Message-ID: <007501c7c95b$584df760$0201a8c0@HALSR> Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 7:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM From jwcolby at colbyconsulting.com Wed Jul 18 11:49:52 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 12:49:52 -0400 Subject: [AccessD] DSNs In-Reply-To: <003301c7c95a$8a935720$8abea8c0@XPS> Message-ID: <20070718164954.BDE89BD7D@smtp-auth.no-ip.com> >1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. I build a new database for each order, thus the reason for editing the DSN >2. Redefine a single DSN. In a text editor I assume? >3. Provide all the connection information in the .Connect property and go DSN less. I didn't state it, but these are for linking tables out of the SQL Server database. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 18, 2007 12:42 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs John, 1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. 2. Redefine a single DSN. 3. Provide all the connection information in the .Connect property and go DSN less. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.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 jwcolby at colbyconsulting.com Wed Jul 18 12:00:38 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 13:00:38 -0400 Subject: [AccessD] DSNs In-Reply-To: <007501c7c95b$584df760$0201a8c0@HALSR> Message-ID: <20070718170040.C599FBEA7@smtp-auth.no-ip.com> >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 7:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 18 12:06:38 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 18 Jul 2007 10:06:38 -0700 Subject: [AccessD] DSNs In-Reply-To: <20070718170040.C599FBEA7@smtp-auth.no-ip.com> References: <007501c7c95b$584df760$0201a8c0@HALSR> <20070718170040.C599FBEA7@smtp-auth.no-ip.com> Message-ID: The path on XP is >Control Panel > Administrative Tools > Data Sources (ODBC) Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 7:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM -- 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 jwcolby at colbyconsulting.com Wed Jul 18 12:14:45 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 13:14:45 -0400 Subject: [AccessD] DSNs In-Reply-To: Message-ID: <20070718171447.8CD17BDE7@smtp-auth.no-ip.com> That was it. And it comes with a little wizard for manually editing the file. Cool. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 18, 2007 1:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] DSNs The path on XP is >Control Panel > Administrative Tools > Data Sources (ODBC) Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH From Lambert.Heenan at AIG.com Wed Jul 18 12:22:20 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Wed, 18 Jul 2007 12:22:20 -0500 Subject: [AccessD] DSNs Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6C5E@xlivmbx35.aig.com> FYI. If your download and install the XP version of TweakUI you'll find a node for 'Control Panel'. There you can check a box and have Data Sources (ODBC) show up in the first control panel window instead of having to open the admin screen too. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 1:15 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs That was it. And it comes with a little wizard for manually editing the file. Cool. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 18, 2007 1:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] DSNs The path on XP is >Control Panel > Administrative Tools > Data Sources (ODBC) Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Wed Jul 18 12:27:13 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 18 Jul 2007 13:27:13 -0400 Subject: [AccessD] DSNs In-Reply-To: <20070718164954.BDE89BD7D@smtp-auth.no-ip.com> References: <003301c7c95a$8a935720$8abea8c0@XPS> <20070718164954.BDE89BD7D@smtp-auth.no-ip.com> Message-ID: <000d01c7c960$e2076f90$8abea8c0@XPS> <> Well scratch that one then. <> No, with code. I've pasted in the VB6 code I use below. Will work fine in Access. This code uses a table however to get the DSN specifics. You'd need to modify it a bit to pull in the database name. However, from what you've said, I would go DSN less. <> Basically a DSN is nothing more then a holding place for connection info. You can supply that info right in the .Connect property and skip the DSN. See this MSDN article: http://msdn2.microsoft.com/en-us/library/bb188204.aspx and look for "Setting Connection Properties" There are loads of examples of doing this on the web. A good site for getting connection strings is: http://www.connectionstrings.com/ Jim. ============================================================================ == Option Explicit ' Require variables to be declared before being used. Private Const ODBC_ADD_SYS_DSN = 4 'Add data source Private Const ODBC_CONFIG_SYS_DSN = 5 'Configure (edit) data source Private Const ODBC_REMOVE_SYS_DSN = 6 'Remove data source Private Const vbAPINull = 0& Private Declare Function SQLConfigDataSource Lib "ODBCCP32.DLL" (ByVal _ hwndParent As Long, ByVal fRequest As Long, ByVal _ lpszDriver As String, ByVal lpszAttributes As String) As Long Function CreateDSNs(strDatabaseName As String) As Integer ' Using tblDSNs, Create/refresh required DSN entires for a database. Dim ws As DAO.Workspace Dim db As DAO.Database Dim rs As DAO.Recordset Dim strDriver As String Dim strAttributes As String Dim strDatabase As String Dim strDSN As String Dim intEntryCount As Integer Dim intNumberofDSNs As Integer Dim varRet As Variant 'Dim pb As New Form_frm_ProgBar On Error goto CreateDSNs_Err Set ws = DBEngine.CreateWorkspace("", "Admin", "") Set db = ws.OpenDatabase("P:\xxx\SetClientEnv\SetClientEnv.MDB") Set rs = db.OpenRecordset("tblDSNs") intNumberofDSNs = rs.RecordCount intEntryCount = 0 'pb.SetMessage "Creating/refreshing DSN Entries" With rs While Not .EOF ' Check if this entry applies to this database. If UCase(rs("DatabaseName")) = UCase(strDatabaseName) Then ' Register method can't create system DSNs ' only user ones. 'DBEngine.RegisterDatabase rs("DSN"), _ ' "SQL Server", _ ' True, _ ' "Description= Traverse - " & strDatabase & _ ' Chr(13) & "Server=" & rs("Server") & _ ' Chr(13) & "Database=" & strDatabase & _ ' Chr(13) & "Network=DBMSSOCN" & _ ' Chr(13) & "Trusted_Connection=Yes" strDriver = "SQL Server" & Chr(0) strAttributes = "DSN=" & rs("DSN") & Chr(0) strAttributes = strAttributes & "Description= Traverse - " & rs("Database") & Chr(0) strAttributes = strAttributes & "Server=" & rs("Server") & Chr(0) strAttributes = strAttributes & "Database=" & rs("Database") & Chr(0) strAttributes = strAttributes & "Network=DBMSSOCN" & Chr(0) strAttributes = strAttributes & "Trusted_Connection=Yes" & Chr(0) varRet = SQLConfigDataSource(vbAPINull, ODBC_ADD_SYS_DSN, strDriver, strAttributes) If varRet <> 1 Then MsgBox "DSN Creation Failed" GoTo CreateDSNs_Err End If End If intEntryCount = intEntryCount + 1 'pb.SetBarPercent (intEntryCount / intNumberofDSNs) * 100 rs.MoveNext Wend End With CreateDSNs = True CreateDSNs_End: On Error Resume Next If Not rs Is Nothing Then rs.Close Set rs = Nothing End If If Not db Is Nothing Then db.Close Set db = Nothing End If If Not ws Is Nothing Then ws.Close Set ws = Nothing End If Exit Function CreateDSNs_Err: CreateDSNs = False GoTo CreateDSNs_End End Function -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 12:50 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. I build a new database for each order, thus the reason for editing the DSN >2. Redefine a single DSN. In a text editor I assume? >3. Provide all the connection information in the .Connect property and go DSN less. I didn't state it, but these are for linking tables out of the SQL Server database. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 18, 2007 12:42 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs John, 1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. 2. Redefine a single DSN. 3. Provide all the connection information in the .Connect property and go DSN less. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.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 adtp at hotmail.com Wed Jul 18 12:28:30 2007 From: adtp at hotmail.com (A.D.TEJPAL) Date: Wed, 18 Jul 2007 22:58:30 +0530 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> Message-ID: Joe, My sample db named NotesHierarchical has just been uploaded to Rogers Access Library (other developers library). Link - http://www.rogersaccesslibrary.com/OtherLibraries.asp#Tejpal,A.D. Apart from meeting the requirements outlined by you, it incorporates certain other desirable features. Brief description is given below. Best wishes, A.D.Tejpal --------------- NotesHierarchical (Sample Db) Brief Description ==================================== This sample db demonstrates handling of performance notes in an organization. Persons in administrative position are assigned various levels. For example the top boss has level 1. Managers next in command, each have level 2. Supervisors next in command, each have level 3. General employees do not have any level assigned to them. Though three level administrative set up is shown in the db, it can be adapted to any number of levels, simply by assigning levels 4, 5 & so on. In order to identify clear chain of command, the immediate boss for each employee is identified via BossID. For top boss, BossID field is blank. Performance notes for a given employee as selected, can be recorded at various levels by his superiors in direct chain of command. A person in senior position can not alter the notes recorded by those below him (but can view the same). The row source for combo box meant for selecting employee is set dynamically in such a manner that it is confined only to those in direct chain of command under the selected noter. This involves recursive reference to BossID field in employees table, implemented via user defined function. Any person in administrative position, wishing to record a note, has to log in using a password. On successful log in, the noter has full read/write access to his own notes for the selected employee. At the same time, all the notes for this employee, as recorded by other noters (only those in the chain of command below the current noter) get displayed, but in read-only state. The notes table, has a Yes/No field named Sent. When Sent is set to true, the note in question can no longer be edited, even by the person who recorded it originally. More-over, once set to True, it can no longer be re-set to False and no back dated note can be created. For example, if note dated 31-Dec-2006 for a given combination of employee and noter has been marked sent, and we are now in year 2007, any new note with date prior to 31-Dec-2006 can not be created this noter for the given employee. Version: Access 2000 File Format Reference: DAO 3.6 ==================================== ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Sunday, July 01, 2007 04:38 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net From jwcolby at colbyconsulting.com Wed Jul 18 12:35:56 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 13:35:56 -0400 Subject: [AccessD] DSNs In-Reply-To: <000d01c7c960$e2076f90$8abea8c0@XPS> Message-ID: <20070718173558.3FEDFBED7@smtp-auth.no-ip.com> Hmm... John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 18, 2007 1:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs <> Well scratch that one then. <> No, with code. I've pasted in the VB6 code I use below. Will work fine in Access. This code uses a table however to get the DSN specifics. You'd need to modify it a bit to pull in the database name. However, from what you've said, I would go DSN less. <> Basically a DSN is nothing more then a holding place for connection info. You can supply that info right in the .Connect property and skip the DSN. See this MSDN article: http://msdn2.microsoft.com/en-us/library/bb188204.aspx and look for "Setting Connection Properties" There are loads of examples of doing this on the web. A good site for getting connection strings is: http://www.connectionstrings.com/ Jim. ============================================================================ == Option Explicit ' Require variables to be declared before being used. Private Const ODBC_ADD_SYS_DSN = 4 'Add data source Private Const ODBC_CONFIG_SYS_DSN = 5 'Configure (edit) data source Private Const ODBC_REMOVE_SYS_DSN = 6 'Remove data source Private Const vbAPINull = 0& Private Declare Function SQLConfigDataSource Lib "ODBCCP32.DLL" (ByVal _ hwndParent As Long, ByVal fRequest As Long, ByVal _ lpszDriver As String, ByVal lpszAttributes As String) As Long Function CreateDSNs(strDatabaseName As String) As Integer ' Using tblDSNs, Create/refresh required DSN entires for a database. Dim ws As DAO.Workspace Dim db As DAO.Database Dim rs As DAO.Recordset Dim strDriver As String Dim strAttributes As String Dim strDatabase As String Dim strDSN As String Dim intEntryCount As Integer Dim intNumberofDSNs As Integer Dim varRet As Variant 'Dim pb As New Form_frm_ProgBar On Error goto CreateDSNs_Err Set ws = DBEngine.CreateWorkspace("", "Admin", "") Set db = ws.OpenDatabase("P:\xxx\SetClientEnv\SetClientEnv.MDB") Set rs = db.OpenRecordset("tblDSNs") intNumberofDSNs = rs.RecordCount intEntryCount = 0 'pb.SetMessage "Creating/refreshing DSN Entries" With rs While Not .EOF ' Check if this entry applies to this database. If UCase(rs("DatabaseName")) = UCase(strDatabaseName) Then ' Register method can't create system DSNs ' only user ones. 'DBEngine.RegisterDatabase rs("DSN"), _ ' "SQL Server", _ ' True, _ ' "Description= Traverse - " & strDatabase & _ ' Chr(13) & "Server=" & rs("Server") & _ ' Chr(13) & "Database=" & strDatabase & _ ' Chr(13) & "Network=DBMSSOCN" & _ ' Chr(13) & "Trusted_Connection=Yes" strDriver = "SQL Server" & Chr(0) strAttributes = "DSN=" & rs("DSN") & Chr(0) strAttributes = strAttributes & "Description= Traverse - " & rs("Database") & Chr(0) strAttributes = strAttributes & "Server=" & rs("Server") & Chr(0) strAttributes = strAttributes & "Database=" & rs("Database") & Chr(0) strAttributes = strAttributes & "Network=DBMSSOCN" & Chr(0) strAttributes = strAttributes & "Trusted_Connection=Yes" & Chr(0) varRet = SQLConfigDataSource(vbAPINull, ODBC_ADD_SYS_DSN, strDriver, strAttributes) If varRet <> 1 Then MsgBox "DSN Creation Failed" GoTo CreateDSNs_Err End If End If intEntryCount = intEntryCount + 1 'pb.SetBarPercent (intEntryCount / intNumberofDSNs) * 100 rs.MoveNext Wend End With CreateDSNs = True CreateDSNs_End: On Error Resume Next If Not rs Is Nothing Then rs.Close Set rs = Nothing End If If Not db Is Nothing Then db.Close Set db = Nothing End If If Not ws Is Nothing Then ws.Close Set ws = Nothing End If Exit Function CreateDSNs_Err: CreateDSNs = False GoTo CreateDSNs_End End Function -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 12:50 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >1. Have multiple DSN's defined and switch the .Connect property to >point to the correct one. I build a new database for each order, thus the reason for editing the DSN >2. Redefine a single DSN. In a text editor I assume? >3. Provide all the connection information in the .Connect property and >go DSN less. I didn't state it, but these are for linking tables out of the SQL Server database. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 18, 2007 12:42 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs John, 1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. 2. Redefine a single DSN. 3. Provide all the connection information in the .Connect property and go DSN less. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.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 kathryn at bassett.net Wed Jul 18 13:13:43 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Wed, 18 Jul 2007 11:13:43 -0700 Subject: [AccessD] Many to Many problem part 1 - the background Message-ID: <005c01c7c967$60fd3590$6401a8c0@Kathryn> I've been working on something on Webweavers (Dreamweaver group). But my design problem actualy has more to do with understanding how to imput something into MySql database. If I could understand it in Access, then I will be able to figure it out in MySql. With that in mind, an explanation of what will be in the database is needed. In Webweavers, one of the gals didn't understand the collections the database is based on. I'll start with Win's last question first: > You talked about a library of collections, but what I see here looks > like a genealogy of sorts. To me a library means collections of > literary works - is that not the case here? No, that's not the case. Have you ever heard of a libray that has "vertical files"? I'll give you an example. A number of years ago, I went to the library in Lake county Ohio. In the genealogy and history section of the library they had a file cabinet of uncataloged papers. In this particular case, there were file folders with surnames on it. A misc jumble of papers would end up in the file folders. In the case I'm thinking of, there was a folder named Harmon. In it were just two papers, one was a letter from someone inquiring about a Harmon family. The other was a copy of a genealogy society newsletter with an article on a man named Harmon. This is unindexed material, not in any catalogs. If I hadn't gone there in person and looked in the files, I would not have made the discovery that was important to me (if you are curious, http://bassett.net/secondsite/kathryn-p/p202.shtml#i10064 and scroll down til you see Story). Another, larger example is Gwen, the lady I work for. She has the equivalent of about 30 "bankers boxes" full of materials from her 30+ years of research. There are many "collections" like this - they are not published books or other literary works. People like Caroline Ackley, David Gardner, Walter Hilbig etc have turned over their un-indexed collections to my friend Arlene. She has been going through the collections and been making indexes of the names in the collections. In metaphoric terms, she has a notebook labeled Caroline Ackley, and as she was going through that collection and sorting it into a way she could find things in the future, she wrote down names she encountered. In some cases, she also made a note about the name - like my hypothetical memo for John Doe in the AckleyCaroline collection (see below). There are many genealogists that will be interested in knowing that "Win Day" is mentioned in an otherwise unindexed group of papers that Alene now has, and they are willing to pay to get copies of those papers - or they will plan to visit her library in person to look at them. Her library is not a normal library, it's an archive of research collections. Hopefully, this fuller description will help you all understand. > When I design a database, I don't start with the database, or thinking > about the web-based forms. I start by writing descriptions of the > information I want to display and how the bits relate to each other. After someone does a search by filling in last name and probably also the first name (though they may only search last name), then this is a sample of what I want to display. ========= Someone by the name of Win Day(1) can be found in the following collections: AckleyCaroline(2) - son of Fred, circa 1800; son of Thomas, circa 1600; and another married to Jane Smith(3) GardnerDavid(2) - married to Jane Smith(3) HilbigWalter(2) SmithJeremiah(2) For a flat fee of $n you can get a copy of 1-nn pages. If there are more than nn pages involved, you will be notified of the charge and your payment can either be applied or refunded if you choose not to purchase. ========= (1) pulled in from tblCScollections (2) pulled in from tblCSnames (3) pulled in from tblCSmemos So, that is the information I want to display. Part two will describe where I'm stuck. -- Kathryn Rhinehart Bassett (Pasadena CA) "Genealogy is my bag" "GH is my soap" kathryn at bassett.net http://bassett.net No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 17 Jul 07 6:30 pm From kathryn at bassett.net Wed Jul 18 13:13:53 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Wed, 18 Jul 2007 11:13:53 -0700 Subject: [AccessD] Many to Many problem part 2 - the tables and question Message-ID: <006001c7c967$6661ac00$6401a8c0@Kathryn> Read part 1 first so you understand what the database is about. I have these three tables. tblCScollections tblCScollectionID int(7) tblCScollectionName varchar(50) populated with the 11 collections we have at present. 1 AckleyCarolyn 2 DunnPhillip 3 GardnerDavid 4 HilbigWalter 5 HollingsworthHarry 6 PriceRichard 7 SmithJeremiah 8 MillsVirginia 9 MooreWilburta 10 MottAnita 11 SmithConley tblCSnames tblCSnamesID int(7) tblCSlastname varchar(50) tblCSfirstname varchar(50) populated with 1 Van Horn G. Armour 2 Bassett Kathryn 3 Day Win 4 Sullivan Stephanie 5 Gentry Doug 6 Lohmar Michael tblCSmemos tblCScollectionID tblCSnamesID tblCSmemo not populated at all at present Bottom line is that I now understand the two+middle table concept. The inputting of data into the database is where I'm having a problem. The flat way I *had* been thinking (using spreadsheet analogy) is that column A/B is lastname/firstname, column B is collectionID1, column C is the memo for collectionID1 and the rest of the columns are like columcs C/D for each collection. I put "true" in each collection ID column that the name in row 2 (or 3 or 4) appears in. Now if Win Day (nameID=3) was ONLY in one collection, then a dropdown box of the collection names would work. But since nameID=3 is in multiple collections and may or may not have a memo, I'm not clear on how to do the input. Help? -- Kathryn Rhinehart Bassett (Pasadena CA) "Genealogy is my bag" "GH is my soap" kathryn at bassett.net http://bassett.net No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 17 Jul 07 6:30 pm From ssharkins at setel.com Wed Jul 18 13:36:31 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 14:36:31 -0400 Subject: [AccessD] Function to grab decimal value? Message-ID: <000a01c7c96a$90721360$a2b82ad1@SusanOne> Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. From ssharkins at setel.com Wed Jul 18 13:48:52 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 14:48:52 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <000a01c7c96a$90721360$a2b82ad1@SusanOne> References: <000a01c7c96a$90721360$a2b82ad1@SusanOne> Message-ID: <000c01c7c96c$4a3a63a0$a2b82ad1@SusanOne> Oh for pete's sakes, duh... Nevermind... Susan H. Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? From jimdettman at verizon.net Wed Jul 18 13:49:05 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 18 Jul 2007 14:49:05 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <000a01c7c96a$90721360$a2b82ad1@SusanOne> References: <000a01c7c96a$90721360$a2b82ad1@SusanOne> Message-ID: <004301c7c96c$51a1d600$8abea8c0@XPS> Susan, MOD comes close but is not quite what you want. Instead, use: =-Int() Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 2:37 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Function to grab decimal value? Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Wed Jul 18 13:50:28 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Wed, 18 Jul 2007 20:50:28 +0200 Subject: [AccessD] Function to grab decimal value? Message-ID: Hi Susan No, you'll have to run your own: f = d - Fix(d) /gustav >>> ssharkins at setel.com 18-07-2007 20:36 >>> Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. From jwcolby at colbyconsulting.com Wed Jul 18 13:51:31 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 14:51:31 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <000a01c7c96a$90721360$a2b82ad1@SusanOne> Message-ID: <20070718185134.759F2BE94@smtp-auth.no-ip.com> First of all, Int will only work for a value up to 32 (or 64) K. Aside from that, something like NewVal = MyVal-int(MyVal). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 2:37 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Function to grab decimal value? Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Wed Jul 18 14:01:12 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Wed, 18 Jul 2007 21:01:12 +0200 Subject: [AccessD] Function to grab decimal value? Message-ID: Hi John Don't you have CInt() in mind? Int() and Fix() accept very large numbers. Further, here Fix must be used in case of a negative decimal number. /gustav >>> jwcolby at colbyconsulting.com 18-07-2007 20:51 >>> First of all, Int will only work for a value up to 32 (or 64) K. Aside from that, something like NewVal = MyVal-int(MyVal). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 2:37 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Function to grab decimal value? Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. From jwcolby at colbyconsulting.com Wed Jul 18 14:06:29 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 15:06:29 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: Message-ID: <20070718190631.6E8BEBD3C@smtp-auth.no-ip.com> Yep, and I keep forgetting Fix() Just keep reminding me and SOMEDAY.... I might remember that one! ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Wednesday, July 18, 2007 3:01 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Function to grab decimal value? Hi John Don't you have CInt() in mind? Int() and Fix() accept very large numbers. Further, here Fix must be used in case of a negative decimal number. /gustav >>> jwcolby at colbyconsulting.com 18-07-2007 20:51 >>> First of all, Int will only work for a value up to 32 (or 64) K. Aside from that, something like NewVal = MyVal-int(MyVal). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 2:37 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Function to grab decimal value? Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From martyconnelly at shaw.ca Wed Jul 18 14:15:37 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Wed, 18 Jul 2007 12:15:37 -0700 Subject: [AccessD] DSNs In-Reply-To: <20070718171447.8CD17BDE7@smtp-auth.no-ip.com> References: <20070718171447.8CD17BDE7@smtp-auth.no-ip.com> Message-ID: <469E66D9.6050408@shaw.ca> I believe you can bring up that wizard from VBA code but it has been 5 years since I last looked. Saw it done via VB6. jwcolby wrote: >That was it. And it comes with a little wizard for manually editing the >file. Cool. > > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust >Sent: Wednesday, July 18, 2007 1:07 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] DSNs > >The path on XP is >Control Panel > Administrative Tools > Data Sources >(ODBC) > >Charlotte > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby >Sent: Wednesday, July 18, 2007 10:01 AM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] DSNs > > > >>Hopefully I'm not being condescending. >> >> > >Not at all. I don't know this stuff > > > >>Control Panel > Data Sources (ODBC) >> >> > >I don't have that. Windows XP Profession SP2 > > > >>HKLM\Software\ODBC\ODBC.INI >> >> > >I don't understand this one. Is this a directory path? A registry key? > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. >Johnson >Sent: Wednesday, July 18, 2007 12:48 PM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] DSNs > >Hopefully I'm not being condescending. > >If this is for your machine only: > >Control Panel > Data Sources (ODBC) > >If you need it programmable: >HKLM\Software\ODBC\ODBC.INI > >HTH > > > -- Marty Connelly Victoria, B.C. Canada From ssharkins at setel.com Wed Jul 18 14:45:01 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 15:45:01 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: References: Message-ID: <001301c7c974$223e5c50$a2b82ad1@SusanOne> No negative values, but thanks guys -- as soon as it hit me, I felt like a true moron. Susan H. Hi John Don't you have CInt() in mind? Int() and Fix() accept very large numbers. Further, here Fix must be used in case of a negative decimal number. From jwcolby at colbyconsulting.com Wed Jul 18 14:52:09 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 15:52:09 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <001301c7c974$223e5c50$a2b82ad1@SusanOne> Message-ID: <20070718195211.E5757BEDF@smtp-auth.no-ip.com> LOL. That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 3:45 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? No negative values, but thanks guys -- as soon as it hit me, I felt like a true moron. Susan H. Hi John Don't you have CInt() in mind? Int() and Fix() accept very large numbers. Further, here Fix must be used in case of a negative decimal number. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Jim.Hale at FleetPride.com Wed Jul 18 15:35:26 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Wed, 18 Jul 2007 15:35:26 -0500 Subject: [AccessD] DSNs In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6C5E@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6C5E@xlivmbx35.aig.com> Message-ID: Here is a discussion I've found useful in the past for creating dsn-less connections http://www-1.ibm.com/support/docview.wss?rs=0&q1=dsn-less&uid=nas1c52dfe 451b37518086256931005499ff&loc=en_US&cs=utf-8&cc=us&lang=en Here is one I've found that helps with propgramming DSNs: How To Create and Remove a DSN in Visual Basic http://support.microsoft.com/kb/q171146/ Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Wednesday, July 18, 2007 12:22 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs FYI. If your download and install the XP version of TweakUI you'll find a node for 'Control Panel'. There you can check a box and have Data Sources (ODBC) show up in the first control panel window instead of having to open the admin screen too. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 1:15 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs That was it. And it comes with a little wizard for manually editing the file. Cool. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 18, 2007 1:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] DSNs The path on XP is >Control Panel > Administrative Tools > Data Sources (ODBC) Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH -- 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From jwelz at hotmail.com Wed Jul 18 16:17:46 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Wed, 18 Jul 2007 15:17:46 -0600 Subject: [AccessD] DSNs In-Reply-To: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> Message-ID: In my environment security renders me unable to create, modify or delete DSNs. Access connects to data in a series of files in a couple of folders in order to read or update information stored by something called a 'Pervasive Database Engine'. I tried relinking to different files at one time when I had rights for the purpose of testing and the time taken to relink was over a minute. What I do now instead is swap the files in the linked location and rename them to the required name. The file system can move the files in a second or two and I can simply use the linked tables with the existing DSN. My DSN points to a series of files in a specific folder and I have a prelinked file with a name based on the logged in UserID so it is useable in a multiuser envrionment. I created the initial link and took the time hit at that point. When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart Expansion - Delta.pee' in one of my lists, that file and some 60 files below it in a subfolder named PVData get copied to the DSN folder overwriting the file 6.pee and all the files below PVData (also renamed). Since the linked tables already exist in the Access applicaiton, the code immediately opens a recordset and reads, processes and reports on or updates the file. For reporting, I just leave the file in place and overwrite it. For updating, the code copies the file back to its source location so it can be opened in its source application. When we create new takeoff files, we use Access data to prefill in the names of the Architects, Engineers, Suppliers, Owners, Contractors, Estimator, our company information, bid closing time, closing date, location, contacts and a ton of other information that we track in Access. This saves our users a ton of time and helps ensure that the information has been validated in Access rather than entered via an application that does not permit validation. This approach was faster and painless in that it was easier to circumvent security restrictions that it would have been to try to change them. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "jwcolby" > >I am working with Access as the FE to processing orders where I need to >export to a fixed width file because Access stores the format, which is >convenient until I come up to speed on how to do something similar in SQL >Server. The issue is that the DSN is specific to a database name. How can >I edit that to point to a different database? > >John W. Colby >Colby Consulting >www.ColbyConsulting.com > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ New Windows Live Hotmail is here. Upgrade for free and get a better look. www.newhotmail.ca?icid=WLHMENCA150 From Jim.Hale at FleetPride.com Wed Jul 18 16:51:19 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Wed, 18 Jul 2007 16:51:19 -0500 Subject: [AccessD] DSNs In-Reply-To: References: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> Message-ID: Isn't this process asynchronous, so there is a danger the user or code will move to other activities before the files have finished copying? I have had issues where dos copies or deletes haven't finished before the Access code tries to use the file. Solutions posted here from time to time (other than a primitive timer loop) to get Access to pause have not worked for me. Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 18, 2007 4:18 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] DSNs In my environment security renders me unable to create, modify or delete DSNs. Access connects to data in a series of files in a couple of folders in order to read or update information stored by something called a 'Pervasive Database Engine'. I tried relinking to different files at one time when I had rights for the purpose of testing and the time taken to relink was over a minute. What I do now instead is swap the files in the linked location and rename them to the required name. The file system can move the files in a second or two and I can simply use the linked tables with the existing DSN. My DSN points to a series of files in a specific folder and I have a prelinked file with a name based on the logged in UserID so it is useable in a multiuser envrionment. I created the initial link and took the time hit at that point. When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart Expansion - Delta.pee' in one of my lists, that file and some 60 files below it in a subfolder named PVData get copied to the DSN folder overwriting the file 6.pee and all the files below PVData (also renamed). Since the linked tables already exist in the Access applicaiton, the code immediately opens a recordset and reads, processes and reports on or updates the file. For reporting, I just leave the file in place and overwrite it. For updating, the code copies the file back to its source location so it can be opened in its source application. When we create new takeoff files, we use Access data to prefill in the names of the Architects, Engineers, Suppliers, Owners, Contractors, Estimator, our company information, bid closing time, closing date, location, contacts and a ton of other information that we track in Access. This saves our users a ton of time and helps ensure that the information has been validated in Access rather than entered via an application that does not permit validation. This approach was faster and painless in that it was easier to circumvent security restrictions that it would have been to try to change them. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From ssharkins at setel.com Wed Jul 18 16:55:50 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 17:55:50 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <20070718195211.E5757BEDF@smtp-auth.no-ip.com> References: <001301c7c974$223e5c50$a2b82ad1@SusanOne> <20070718195211.E5757BEDF@smtp-auth.no-ip.com> Message-ID: <000101c7c986$6ab2c590$c0b62ad1@SusanOne> That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. =====Familiar to you, is it???? :) Susan H. From bheid at sc.rr.com Wed Jul 18 17:14:10 2007 From: bheid at sc.rr.com (Bobby Heid) Date: Wed, 18 Jul 2007 18:14:10 -0400 Subject: [AccessD] Require password for linked MDB tables In-Reply-To: References: <660053.99904.qm@web81313.mail.mud.yahoo.com> Message-ID: <006801c7c988$f7c3fba0$e74bf2e0$@rr.com> I guess if you asked the user for the password before linking the table, then it might work. You would have it unlink it after using it. Bobby -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Tuesday, July 17, 2007 3:49 PM To: accessd at databaseadvisors.com Subject: [AccessD] Require password for linked MDB tables Hello All, Can I have an MDB linked to a seperate MDB(with password)...and have the user required to enter just a password to view the linked table each time? And is it different in different versions? Thanks, Mark A. Matte From jwelz at hotmail.com Wed Jul 18 20:26:03 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Wed, 18 Jul 2007 19:26:03 -0600 Subject: [AccessD] DSNs In-Reply-To: Message-ID: I call the CopyFileA API from Lib "kernel32" that gives me an overwrite parameter and that proceeds synchronously. Alternatively I could call a ShellWait procedure as follows: Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) Dim proc As PROCESS_INFORMATION Dim start As STARTUPINFO Dim ret As Long With start .cb = Len(start) If Not IsMissing(WindowStyle) Then .dwFlags = STARTF_USESHOWWINDOW .wShowWindow = WindowStyle End If End With ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, 0&, 0&, start, proc) ret& = WaitForSingleObject(proc.hProcess, INFINITE) CloseHandle proc.hProcess End Sub but this has not been necessary as my copyfile wrapper waits until the copy completes before returning success or fail. No need for a timer kludge. This is the method I've used since Access97 was brand spanking new with 5 or 6 users and it works just as well with over 40. I've never known this approach to fail. In fact, every estimate we've done with Timberline in the past 9 years has used this method and there are 10s of thousands of these files. The links for reporting that have been created must be in the 100s of thousands. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Hale, Jim" > >Isn't this process asynchronous, so there is a danger the user or code will >move to other activities before the files have finished copying? I have >had issues where dos copies or deletes haven't finished before the Access >code tries to use the file. Solutions posted here from time to time (other >than a primitive timer loop) to get Access to pause have not worked for me. > >Jim Hale > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 4:18 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >In my environment security renders me unable to create, modify or delete >DSNs. Access connects to data in a series of files in a couple of folders >in order to read or update information stored by something called a >'Pervasive Database Engine'. > >I tried relinking to different files at one time when I had rights for the >purpose of testing and the time taken to relink was over a minute. What I >do now instead is swap the files in the linked location and rename them to >the required name. The file system can move the files in a second or two >and I can simply use the linked tables with the existing DSN. My DSN >points >to a series of files in a specific folder and I have a prelinked file with >a >name based on the logged in UserID so it is useable in a multiuser >envrionment. I created the initial link and took the time hit at that >point. > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart >Expansion - Delta.pee' in one of my lists, that file and some 60 files >below >it in a subfolder named PVData get copied to the DSN folder overwriting the >file 6.pee and all the files below PVData (also renamed). Since the linked >tables already exist in the Access applicaiton, the code immediately opens >a >recordset and reads, processes and reports on or updates the file. For >reporting, I just leave the file in place and overwrite it. For updating, >the code copies the file back to its source location so it can be opened in >its source application. When we create new takeoff files, we use Access >data to prefill in the names of the Architects, Engineers, Suppliers, >Owners, Contractors, Estimator, our company information, bid closing time, >closing date, location, contacts and a ton of other information that we >track in Access. This saves our users a ton of time and helps ensure that >the information has been validated in Access rather than entered via an >application that does not permit validation. > >This approach was faster and painless in that it was easier to circumvent >security restrictions that it would have been to try to change them. > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > >*********************************************************************** >The information transmitted is intended solely for the individual or >entity to which it is addressed and may contain confidential and/or >privileged material. Any review, retransmission, dissemination or >other use of or taking action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. >If you have received this email in error please contact the sender and >delete the material from any computer. As a recipient of this email, >you are responsible for screening its contents and the contents of any >attachments for the presence of viruses. No liability is accepted for >any damages caused by any virus transmitted by this email. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com . _________________________________________________________________ Windows Live Hotmail. Even hotter than before. Get a better look now. www.newhotmail.ca?icid=WLHMENCA148 From jwcolby at colbyconsulting.com Wed Jul 18 20:53:40 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 21:53:40 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <000101c7c986$6ab2c590$c0b62ad1@SusanOne> Message-ID: <20070719015342.9BBFFBD0E@smtp-auth.no-ip.com> Oh yea. My life is made up of a series of OhNoSeconds. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 5:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. =====Familiar to you, is it???? :) Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Thu Jul 19 07:11:44 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 07:11:44 -0500 Subject: [AccessD] CopyFile (was DSNs) In-Reply-To: References: Message-ID: <000501c7c9fd$f9422900$0200a8c0@danwaters> Jurgen, Could you post your CopyFile wrapper procedure? Thanks, Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 18, 2007 8:26 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] DSNs I call the CopyFileA API from Lib "kernel32" that gives me an overwrite parameter and that proceeds synchronously. Alternatively I could call a ShellWait procedure as follows: Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) Dim proc As PROCESS_INFORMATION Dim start As STARTUPINFO Dim ret As Long With start .cb = Len(start) If Not IsMissing(WindowStyle) Then .dwFlags = STARTF_USESHOWWINDOW .wShowWindow = WindowStyle End If End With ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, 0&, 0&, start, proc) ret& = WaitForSingleObject(proc.hProcess, INFINITE) CloseHandle proc.hProcess End Sub but this has not been necessary as my copyfile wrapper waits until the copy completes before returning success or fail. No need for a timer kludge. This is the method I've used since Access97 was brand spanking new with 5 or 6 users and it works just as well with over 40. I've never known this approach to fail. In fact, every estimate we've done with Timberline in the past 9 years has used this method and there are 10s of thousands of these files. The links for reporting that have been created must be in the 100s of thousands. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Hale, Jim" > >Isn't this process asynchronous, so there is a danger the user or code will >move to other activities before the files have finished copying? I have >had issues where dos copies or deletes haven't finished before the Access >code tries to use the file. Solutions posted here from time to time (other >than a primitive timer loop) to get Access to pause have not worked for me. > >Jim Hale > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 4:18 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >In my environment security renders me unable to create, modify or delete >DSNs. Access connects to data in a series of files in a couple of folders >in order to read or update information stored by something called a >'Pervasive Database Engine'. > >I tried relinking to different files at one time when I had rights for the >purpose of testing and the time taken to relink was over a minute. What I >do now instead is swap the files in the linked location and rename them to >the required name. The file system can move the files in a second or two >and I can simply use the linked tables with the existing DSN. My DSN >points >to a series of files in a specific folder and I have a prelinked file with >a >name based on the logged in UserID so it is useable in a multiuser >envrionment. I created the initial link and took the time hit at that >point. > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart >Expansion - Delta.pee' in one of my lists, that file and some 60 files >below >it in a subfolder named PVData get copied to the DSN folder overwriting the >file 6.pee and all the files below PVData (also renamed). Since the linked >tables already exist in the Access applicaiton, the code immediately opens >a >recordset and reads, processes and reports on or updates the file. For >reporting, I just leave the file in place and overwrite it. For updating, >the code copies the file back to its source location so it can be opened in >its source application. When we create new takeoff files, we use Access >data to prefill in the names of the Architects, Engineers, Suppliers, >Owners, Contractors, Estimator, our company information, bid closing time, >closing date, location, contacts and a ton of other information that we >track in Access. This saves our users a ton of time and helps ensure that >the information has been validated in Access rather than entered via an >application that does not permit validation. > >This approach was faster and painless in that it was easier to circumvent >security restrictions that it would have been to try to change them. > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > >*********************************************************************** >The information transmitted is intended solely for the individual or >entity to which it is addressed and may contain confidential and/or >privileged material. Any review, retransmission, dissemination or >other use of or taking action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. >If you have received this email in error please contact the sender and >delete the material from any computer. As a recipient of this email, >you are responsible for screening its contents and the contents of any >attachments for the presence of viruses. No liability is accepted for >any damages caused by any virus transmitted by this email. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.c From jwelz at hotmail.com Thu Jul 19 07:58:09 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 19 Jul 2007 06:58:09 -0600 Subject: [AccessD] CopyFile (was DSNs) In-Reply-To: <000501c7c9fd$f9422900$0200a8c0@danwaters> Message-ID: Private Declare Function CopyFileA Lib "kernel32" (ByVal ExistingFileName As String, _ ByVal NewFileName As String, ByVal FailIfExists As Long) As Long Public Function Copy(FileSrc As String, FileDst As String, Optional NoOverWrite As Boolean = True) _ As Boolean On Error GoTo ErrorHandler Copy = CopyFileA(FileSrc, FileDst, NoOverWrite) = 1 ExitRoutine: On Error Resume Next Exit Function ErrorHandler: With Err Select Case .Number Case Else MsgBox .Number & vbCrLf & .Description, vbInformation, "Error - Copy" End Select End With 'Resume 0 Resume ExitRoutine End Function Parameters are: FileSrc : Full path and file name. Accepts UNC or Mapped. The caller verifies the existence of the source file with Len(Dir(FileSrc)) prior to calling Copy. FileDst: Full path and file name. As above except the caller creates the target path if it doesn't exist by calling a function called fnCreateBasePath (below). NoOverWrite is an optional boolean parameter that if left out will not allow the function to overwrite an existing file. You must pass a false if you wish it to overwrite a preexisting target file. To ensure the creation of the target path, I use a couple of functions. I check available drives and once the target drive is verified, the caller of the Copy procedure also calls: Public Function fnCreateBasePath(strCreatePath As String) As Boolean On Error GoTo ErrorHandler Dim strPath As String Dim lngPos As Long strCreatePath = Trim$(strCreatePath) If Right$(strCreatePath, 1) <> "\" Then strCreatePath = strCreatePath & "\" lngPos = 7 Do Until lngPos = 1 lngPos = InStr(lngPos + 1, strCreatePath, "\") If lngPos Then strPath = Left$(strCreatePath, lngPos - 1) If Not Len(Dir(strPath, vbDirectory)) > 0 Then MkDir strPath End If End If lngPos = lngPos + 1 Loop fnCreateBasePath = True ExitRoutine: On Error Resume Next Exit Function ErrorHandler: With Err Select Case .Number Case Else MsgBox .Number & vbCrLf & .Description & vbCrLf & vbCrLf & _ " Error in creating Folder: '" & strCreatePath & "'", _ vbInformation, "Error - fnCreateBasePath" End Select End With 'Resume 0 Resume ExitRoutine End Function In my environment I am guaranteed that the lower base path inicluding the drive letter willl exceed 7 characters once the drive has been verified which is why lngPos starts at an initial value of 7. If any part of the procedure fails, it reports failure to the caller and the caller aborts with an error message to the user. Because it is synchronous, there is no misreporting on old data that failed to be overwritten. For certain kinds of files, I verify that no one has the source file open by calling a file Open (help file says Open pathname For mode [Access access] [lock] As [#]filenumber [Len=reclength]) and attempting to open exclusive. Alternatively, if you've set up your file structure like mine where files related to a record are in or below a single folder, you can check whether anyone is working in any files related to the record by attempting to rename the folder first. I'm certain the filesystemobject will let you do these things as well but it requires a reference to some scripting library that is not enabled in my users' environment. In any event, the built in VBA file and folder methods are fast and totally reliable and don't require loading external libraries so without a need to use the FSO, I'll leave things as they are. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Dan Waters" > >Jurgen, > >Could you post your CopyFile wrapper procedure? > >Thanks, >Dan Waters > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 8:26 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >I call the CopyFileA API from Lib "kernel32" that gives me an overwrite >parameter and that proceeds synchronously. Alternatively I could call a >ShellWait procedure as follows: > >Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) > Dim proc As PROCESS_INFORMATION > Dim start As STARTUPINFO > Dim ret As Long > > With start > .cb = Len(start) > If Not IsMissing(WindowStyle) Then > .dwFlags = STARTF_USESHOWWINDOW > .wShowWindow = WindowStyle > End If > End With > ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, >0&, 0&, start, proc) > ret& = WaitForSingleObject(proc.hProcess, INFINITE) > CloseHandle proc.hProcess >End Sub > >but this has not been necessary as my copyfile wrapper waits until the copy >completes before returning success or fail. No need for a timer kludge. > >This is the method I've used since Access97 was brand spanking new with 5 >or > >6 users and it works just as well with over 40. I've never known this >approach to fail. In fact, every estimate we've done with Timberline in >the > >past 9 years has used this method and there are 10s of thousands of these >files. The links for reporting that have been created must be in the 100s >of thousands. > > > > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > > > > > >From: "Hale, Jim" > > > >Isn't this process asynchronous, so there is a danger the user or code >will > > >move to other activities before the files have finished copying? I have > >had issues where dos copies or deletes haven't finished before the Access > >code tries to use the file. Solutions posted here from time to time >(other > >than a primitive timer loop) to get Access to pause have not worked for >me. > > > >Jim Hale > > > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz > >Sent: Wednesday, July 18, 2007 4:18 PM > >To: accessd at databaseadvisors.com > >Subject: Re: [AccessD] DSNs > > > >In my environment security renders me unable to create, modify or delete > >DSNs. Access connects to data in a series of files in a couple of >folders > >in order to read or update information stored by something called a > >'Pervasive Database Engine'. > > > >I tried relinking to different files at one time when I had rights for >the > >purpose of testing and the time taken to relink was over a minute. What >I > >do now instead is swap the files in the linked location and rename them >to > >the required name. The file system can move the files in a second or two > >and I can simply use the linked tables with the existing DSN. My DSN > >points > >to a series of files in a specific folder and I have a prelinked file >with > >a > >name based on the logged in UserID so it is useable in a multiuser > >envrionment. I created the initial link and took the time hit at that > >point. > > > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart > >Expansion - Delta.pee' in one of my lists, that file and some 60 files > >below > >it in a subfolder named PVData get copied to the DSN folder overwriting >the > >file 6.pee and all the files below PVData (also renamed). Since the >linked > >tables already exist in the Access applicaiton, the code immediately >opens > >a > >recordset and reads, processes and reports on or updates the file. For > >reporting, I just leave the file in place and overwrite it. For >updating, > >the code copies the file back to its source location so it can be opened >in > >its source application. When we create new takeoff files, we use Access > >data to prefill in the names of the Architects, Engineers, Suppliers, > >Owners, Contractors, Estimator, our company information, bid closing >time, > >closing date, location, contacts and a ton of other information that we > >track in Access. This saves our users a ton of time and helps ensure >that > >the information has been validated in Access rather than entered via an > >application that does not permit validation. > > > >This approach was faster and painless in that it was easier to circumvent > >security restrictions that it would have been to try to change them. > > > >Ciao > >J?rgen Welz > >Edmonton, Alberta > >jwelz at hotmail.com > > > >*********************************************************************** > >The information transmitted is intended solely for the individual or > >entity to which it is addressed and may contain confidential and/or > >privileged material. Any review, retransmission, dissemination or > >other use of or taking action in reliance upon this information by > >persons or entities other than the intended recipient is prohibited. > >If you have received this email in error please contact the sender and > >delete the material from any computer. As a recipient of this email, > >you are responsible for screening its contents and the contents of any > >attachments for the presence of viruses. No liability is accepted for > >any damages caused by any virus transmitted by this email. > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.c > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Windows Live Hotmail with drag and drop, you can easily move and organize your mail in one simple step. Get it today! www.newhotmail.ca?icid=WLHMENCA153 From dwaters at usinternet.com Thu Jul 19 08:12:54 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 08:12:54 -0500 Subject: [AccessD] CopyFile (was DSNs) In-Reply-To: References: <000501c7c9fd$f9422900$0200a8c0@danwaters> Message-ID: <001001c7ca06$857a5570$0200a8c0@danwaters> Excellent! Thanks Jurgen! Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Thursday, July 19, 2007 7:58 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] CopyFile (was DSNs) Private Declare Function CopyFileA Lib "kernel32" (ByVal ExistingFileName As String, _ ByVal NewFileName As String, ByVal FailIfExists As Long) As Long Public Function Copy(FileSrc As String, FileDst As String, Optional NoOverWrite As Boolean = True) _ As Boolean On Error GoTo ErrorHandler Copy = CopyFileA(FileSrc, FileDst, NoOverWrite) = 1 ExitRoutine: On Error Resume Next Exit Function ErrorHandler: With Err Select Case .Number Case Else MsgBox .Number & vbCrLf & .Description, vbInformation, "Error - Copy" End Select End With 'Resume 0 Resume ExitRoutine End Function Parameters are: FileSrc : Full path and file name. Accepts UNC or Mapped. The caller verifies the existence of the source file with Len(Dir(FileSrc)) prior to calling Copy. FileDst: Full path and file name. As above except the caller creates the target path if it doesn't exist by calling a function called fnCreateBasePath (below). NoOverWrite is an optional boolean parameter that if left out will not allow the function to overwrite an existing file. You must pass a false if you wish it to overwrite a preexisting target file. To ensure the creation of the target path, I use a couple of functions. I check available drives and once the target drive is verified, the caller of the Copy procedure also calls: Public Function fnCreateBasePath(strCreatePath As String) As Boolean On Error GoTo ErrorHandler Dim strPath As String Dim lngPos As Long strCreatePath = Trim$(strCreatePath) If Right$(strCreatePath, 1) <> "\" Then strCreatePath = strCreatePath & "\" lngPos = 7 Do Until lngPos = 1 lngPos = InStr(lngPos + 1, strCreatePath, "\") If lngPos Then strPath = Left$(strCreatePath, lngPos - 1) If Not Len(Dir(strPath, vbDirectory)) > 0 Then MkDir strPath End If End If lngPos = lngPos + 1 Loop fnCreateBasePath = True ExitRoutine: On Error Resume Next Exit Function ErrorHandler: With Err Select Case .Number Case Else MsgBox .Number & vbCrLf & .Description & vbCrLf & vbCrLf & _ " Error in creating Folder: '" & strCreatePath & "'", _ vbInformation, "Error - fnCreateBasePath" End Select End With 'Resume 0 Resume ExitRoutine End Function In my environment I am guaranteed that the lower base path inicluding the drive letter willl exceed 7 characters once the drive has been verified which is why lngPos starts at an initial value of 7. If any part of the procedure fails, it reports failure to the caller and the caller aborts with an error message to the user. Because it is synchronous, there is no misreporting on old data that failed to be overwritten. For certain kinds of files, I verify that no one has the source file open by calling a file Open (help file says Open pathname For mode [Access access] [lock] As [#]filenumber [Len=reclength]) and attempting to open exclusive. Alternatively, if you've set up your file structure like mine where files related to a record are in or below a single folder, you can check whether anyone is working in any files related to the record by attempting to rename the folder first. I'm certain the filesystemobject will let you do these things as well but it requires a reference to some scripting library that is not enabled in my users' environment. In any event, the built in VBA file and folder methods are fast and totally reliable and don't require loading external libraries so without a need to use the FSO, I'll leave things as they are. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Dan Waters" > >Jurgen, > >Could you post your CopyFile wrapper procedure? > >Thanks, >Dan Waters > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 8:26 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >I call the CopyFileA API from Lib "kernel32" that gives me an overwrite >parameter and that proceeds synchronously. Alternatively I could call a >ShellWait procedure as follows: > >Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) > Dim proc As PROCESS_INFORMATION > Dim start As STARTUPINFO > Dim ret As Long > > With start > .cb = Len(start) > If Not IsMissing(WindowStyle) Then > .dwFlags = STARTF_USESHOWWINDOW > .wShowWindow = WindowStyle > End If > End With > ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, >0&, 0&, start, proc) > ret& = WaitForSingleObject(proc.hProcess, INFINITE) > CloseHandle proc.hProcess >End Sub > >but this has not been necessary as my copyfile wrapper waits until the copy >completes before returning success or fail. No need for a timer kludge. > >This is the method I've used since Access97 was brand spanking new with 5 >or > >6 users and it works just as well with over 40. I've never known this >approach to fail. In fact, every estimate we've done with Timberline in >the > >past 9 years has used this method and there are 10s of thousands of these >files. The links for reporting that have been created must be in the 100s >of thousands. > > > > >Ciao >J|rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > > > > > >From: "Hale, Jim" > > > >Isn't this process asynchronous, so there is a danger the user or code >will > > >move to other activities before the files have finished copying? I have > >had issues where dos copies or deletes haven't finished before the Access > >code tries to use the file. Solutions posted here from time to time >(other > >than a primitive timer loop) to get Access to pause have not worked for >me. > > > >Jim Hale > > > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz > >Sent: Wednesday, July 18, 2007 4:18 PM > >To: accessd at databaseadvisors.com > >Subject: Re: [AccessD] DSNs > > > >In my environment security renders me unable to create, modify or delete > >DSNs. Access connects to data in a series of files in a couple of >folders > >in order to read or update information stored by something called a > >'Pervasive Database Engine'. > > > >I tried relinking to different files at one time when I had rights for >the > >purpose of testing and the time taken to relink was over a minute. What >I > >do now instead is swap the files in the linked location and rename them >to > >the required name. The file system can move the files in a second or two > >and I can simply use the linked tables with the existing DSN. My DSN > >points > >to a series of files in a specific folder and I have a prelinked file >with > >a > >name based on the logged in UserID so it is useable in a multiuser > >envrionment. I created the initial link and took the time hit at that > >point. > > > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart > >Expansion - Delta.pee' in one of my lists, that file and some 60 files > >below > >it in a subfolder named PVData get copied to the DSN folder overwriting >the > >file 6.pee and all the files below PVData (also renamed). Since the >linked > >tables already exist in the Access applicaiton, the code immediately >opens > >a > >recordset and reads, processes and reports on or updates the file. For > >reporting, I just leave the file in place and overwrite it. For >updating, > >the code copies the file back to its source location so it can be opened >in > >its source application. When we create new takeoff files, we use Access > >data to prefill in the names of the Architects, Engineers, Suppliers, > >Owners, Contractors, Estimator, our company information, bid closing >time, > >closing date, location, contacts and a ton of other information that we > >track in Access. This saves our users a ton of time and helps ensure >that > >the information has been validated in Access rather than entered via an > >application that does not permit validation. > > > >This approach was faster and painless in that it was easier to circumvent > >security restrictions that it would have been to try to change them. > > > >Ciao > >J|rgen Welz > >Edmonton, Alberta > >jwelz at hotmail.com > > > >*********************************************************************** > >The information transmitted is intended solely for the individual or > >entity to which it is addressed and may contain confidential and/or > >privileged material. Any review, retransmission, dissemination or > >other use of or taking action in reliance upon this information by > >persons or entities other than the intended recipient is prohibited. > >If you have received this email in error please contact the sender and > >delete the material from any computer. As a recipient of this email, > >you are responsible for screening its contents and the contents of any > >attachments for the presence of viruses. No liability is accepted for > >any damages caused by any virus transmitted by this email. > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.c > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Windows Live Hotmail with drag and drop, you can easily move and organize your mail in one simple step. Get it today! www.newhotmail.ca?icid=WLHMENCA153 From Jim.Hale at FleetPride.com Thu Jul 19 08:16:02 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 19 Jul 2007 08:16:02 -0500 Subject: [AccessD] DSNs In-Reply-To: References: Message-ID: Very nice, I'll give it a try, thanks Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 18, 2007 8:26 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] DSNs I call the CopyFileA API from Lib "kernel32" that gives me an overwrite parameter and that proceeds synchronously. Alternatively I could call a ShellWait procedure as follows: Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) Dim proc As PROCESS_INFORMATION Dim start As STARTUPINFO Dim ret As Long With start .cb = Len(start) If Not IsMissing(WindowStyle) Then .dwFlags = STARTF_USESHOWWINDOW .wShowWindow = WindowStyle End If End With ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, 0&, 0&, start, proc) ret& = WaitForSingleObject(proc.hProcess, INFINITE) CloseHandle proc.hProcess End Sub but this has not been necessary as my copyfile wrapper waits until the copy completes before returning success or fail. No need for a timer kludge. This is the method I've used since Access97 was brand spanking new with 5 or 6 users and it works just as well with over 40. I've never known this approach to fail. In fact, every estimate we've done with Timberline in the past 9 years has used this method and there are 10s of thousands of these files. The links for reporting that have been created must be in the 100s of thousands. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Hale, Jim" > >Isn't this process asynchronous, so there is a danger the user or code will >move to other activities before the files have finished copying? I have >had issues where dos copies or deletes haven't finished before the Access >code tries to use the file. Solutions posted here from time to time (other >than a primitive timer loop) to get Access to pause have not worked for me. > >Jim Hale > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 4:18 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >In my environment security renders me unable to create, modify or delete >DSNs. Access connects to data in a series of files in a couple of folders >in order to read or update information stored by something called a >'Pervasive Database Engine'. > >I tried relinking to different files at one time when I had rights for the >purpose of testing and the time taken to relink was over a minute. What I >do now instead is swap the files in the linked location and rename them to >the required name. The file system can move the files in a second or two >and I can simply use the linked tables with the existing DSN. My DSN >points >to a series of files in a specific folder and I have a prelinked file with >a >name based on the logged in UserID so it is useable in a multiuser >envrionment. I created the initial link and took the time hit at that >point. > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart >Expansion - Delta.pee' in one of my lists, that file and some 60 files >below >it in a subfolder named PVData get copied to the DSN folder overwriting the >file 6.pee and all the files below PVData (also renamed). Since the linked >tables already exist in the Access applicaiton, the code immediately opens >a >recordset and reads, processes and reports on or updates the file. For >reporting, I just leave the file in place and overwrite it. For updating, >the code copies the file back to its source location so it can be opened in >its source application. When we create new takeoff files, we use Access >data to prefill in the names of the Architects, Engineers, Suppliers, >Owners, Contractors, Estimator, our company information, bid closing time, >closing date, location, contacts and a ton of other information that we >track in Access. This saves our users a ton of time and helps ensure that >the information has been validated in Access rather than entered via an >application that does not permit validation. > >This approach was faster and painless in that it was easier to circumvent >security restrictions that it would have been to try to change them. > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > >*********************************************************************** >The information transmitted is intended solely for the individual or >entity to which it is addressed and may contain confidential and/or >privileged material. Any review, retransmission, dissemination or >other use of or taking action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. >If you have received this email in error please contact the sender and >delete the material from any computer. As a recipient of this email, >you are responsible for screening its contents and the contents of any >attachments for the presence of viruses. No liability is accepted for >any damages caused by any virus transmitted by this email. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com . _________________________________________________________________ Windows Live Hotmail. Even hotter than before. Get a better look now. www.newhotmail.ca?icid=WLHMENCA148 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From jwelz at hotmail.com Thu Jul 19 08:42:36 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 19 Jul 2007 07:42:36 -0600 Subject: [AccessD] CopyFile (was DSNs) In-Reply-To: <000501c7c9fd$f9422900$0200a8c0@danwaters> Message-ID: An anomoly I've recently run into has been an inconsistency in mapping of several of our drives in a Remote Desktop environment where the server environment is Win2K3 Server. When a user of mine clicks a record's explore button on a form, the application checks for the existence of the record's target folder and creates it if it doesn't exist. The target path is passed to shellexecute and a windows explorer window opens to the target path. If the mapping is good, the path is correct and any existing files or folders are displayed. If the mapping doesn't exist, the procedure that creates the path creates a path alright. It is on the correct drive, but it is an 8.3 path. The explorer window will display the full mapped path at the top of the window. Users will drag files into this folder to related them to the record. For example, we may get some pdf specs and some dwg blueprints, or email correspondence. The users navigate to the record, pop the explorer window and drag or paste files into the record's folder. But if the mapping is bad and there are spaces in the file name or parts of the path or file name exceed 8 characters, there is a problem. If the file name doesn't comply with the 8.3 or has a space, Explorer will present a user with an error message and offer to fix the file name. When the file is pasted, it goes into a locaton with a truncated path and never appears in the explorer window the user has open into which files are pasted. Bizzare. If the application creates a file, like an estimate, Word or Excel file, it will save it in a truncated path. No error is ever returned by the file system. If my procedure calls MkDir in a loop to create("S:\GOM\Vancouver\2003\..."), the code will in fact create S:\GOM\Vancouve\2003\..." truncating Vancouver and never giving an error. In such a case, the file will be saved in the truncated path and the name will be truncated, if necessary, but no error message at all is returned anywhere. This problem started happening in April 2007. I am told by IT that it has to do with terminals that allow upload by providing access to local resources (local usb connected ports). However, this had never been a problem in the past. The older versions of the server Windows would report an error in a situation like this and the 2003 version had been reliable for the 2.5 years preceeding this April even though we've had access to local resources the entire time. There must be some service pack to the server windows that messed up the system. With the older versions of Windows, I could occasionally enumerate mapped drives and the system would list drives that were actually disconnected. The only reliable means of verifying a mapped drive was to run a directory against the mapped drive and see if a '.' was returned. For this reason I mentioned in the previous post that I verify existence of mapped drives. The bizzare thing is that the base path I create is on the mapped drive and thats where it is created, even if the mapped drive doesn't exist. The solution was to use the UNC paths, but that was complicated on the July 1 long weekend when we switched from 2 servers to 5. While most of the files remain on a single server, all Estimate files need to reside on a root (C or D) drive of the former 2nd server. Fortunately, copying to the UNC will place them on an appropriate root drive. As the servers are broken down on a regional basis, I've had to update my code to work with the correct server in the situation. Given that all servers are mapped identically, it would have been easier to stay with the drive mappings, but reliability concerns have prompted me to consider moving strictly to UNC paths. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com _________________________________________________________________ Fight Allergies With Live Search http://search.live.com/results.aspx?q=Remedies+For+Spring+Allergies&mkt=en-ca&FORM=SERNEP From markamatte at hotmail.com Thu Jul 19 08:53:01 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 19 Jul 2007 13:53:01 +0000 Subject: [AccessD] Require password for linked MDB tables In-Reply-To: <006801c7c988$f7c3fba0$e74bf2e0$@rr.com> Message-ID: But if I use the following to try to link...I get the error (invalid Password): Set tdf = dbs.CreateTableDef("Test") tdf.Connect = ";Database=C:\temp\test.mdb" tdf.SourceTableName = "tblPass" dbs.TableDefs.Append tdf >From: "Bobby Heid" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Require password for linked MDB tables >Date: Wed, 18 Jul 2007 18:14:10 -0400 > >I guess if you asked the user for the password before linking the table, >then it might work. You would have it unlink it after using it. > >Bobby > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Tuesday, July 17, 2007 3:49 PM >To: accessd at databaseadvisors.com >Subject: [AccessD] Require password for linked MDB tables > >Hello All, > >Can I have an MDB linked to a seperate MDB(with password)...and have the >user required to enter just a password to view the linked table each time? > >And is it different in different versions? > >Thanks, > >Mark A. Matte > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://im.live.com/messenger/im/home/?source=hmtextlinkjuly07 From jwcolby at colbyconsulting.com Thu Jul 19 09:27:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 10:27:23 -0400 Subject: [AccessD] OT: Excel - Get sheet out of workbook Message-ID: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> I have a workbook with 4 sheets. I need to get those four sheets out into separate workbooks (one sheet per workbook). Other than copying the file four times and deleting the sheets not wanted, is there a way to save a specific sheet as a new workbook? John W. Colby Colby Consulting www.ColbyConsulting.com From jwcolby at colbyconsulting.com Thu Jul 19 09:31:31 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 10:31:31 -0400 Subject: [AccessD] OT: Excel - Merge several cells Message-ID: <20070719143134.436C0BD57@smtp-auth.no-ip.com> I need to "merge" several cells to create one big cell. I have seen this in spreadsheets but have no idea how to do it myself. Any clue? For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and all the cells below them remain as they were. I need to put text in a "header cell". TIA John W. Colby Colby Consulting www.ColbyConsulting.com From Chris.Foote at uk.thalesgroup.com Thu Jul 19 09:46:20 2007 From: Chris.Foote at uk.thalesgroup.com (Foote, Chris) Date: Thu, 19 Jul 2007 15:46:20 +0100 Subject: [AccessD] OT: Excel - Merge several cells Message-ID: <7303A459C921B5499AF732CCEEAD2B7F064D1103@craws161660.int.rdel.co.uk> Hi John! Select all the cells you need to "merge". Right mouse click. Select "Format Cells". Select "Alignment" tab. Select "Merge cells" check box. Click "OK" button. Viola! Regards Chris Foote > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 3:32 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Merge several cells > > > I need to "merge" several cells to create one big cell. I > have seen this in > spreadsheets but have no idea how to do it myself. > > Any clue? > > For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and > all the cells > below them remain as they were. I need to put text in a > "header cell". > > TIA > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From jwcolby at colbyconsulting.com Thu Jul 19 09:52:42 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 10:52:42 -0400 Subject: [AccessD] OT: Excel - Merge several cells In-Reply-To: <7303A459C921B5499AF732CCEEAD2B7F064D1103@craws161660.int.rdel.co.uk> Message-ID: <20070719145242.E51E3BCB0@smtp-auth.no-ip.com> Voila indeed! Today, you da man! Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Foote, Chris Sent: Thursday, July 19, 2007 10:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Merge several cells Hi John! Select all the cells you need to "merge". Right mouse click. Select "Format Cells". Select "Alignment" tab. Select "Merge cells" check box. Click "OK" button. Viola! Regards Chris Foote > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 3:32 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Merge several cells > > > I need to "merge" several cells to create one big cell. I have seen > this in spreadsheets but have no idea how to do it myself. > > Any clue? > > For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and all the > cells below them remain as they were. I need to put text in a "header > cell". > > TIA > > John W. Colby > Colby Consulting > www.ColbyConsulting.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 dwaters at usinternet.com Thu Jul 19 09:53:39 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 09:53:39 -0500 Subject: [AccessD] OT: Excel - Get sheet out of workbook In-Reply-To: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> References: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> Message-ID: <001a01c7ca14$98637500$0200a8c0@danwaters> Yes - 1) Go to Sheet X of Y. 2) Select the entire sheet by clicking the gray box at the intersection of columns and rows. 3) Copy 4) Open new workbook by clicking the New button. 5) Select the same gray box as in 2). 6) Paste 7) Repeat as needed. This will preserve the text formatting and column and row sizes. HTH! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 9:27 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Excel - Get sheet out of workbook I have a workbook with 4 sheets. I need to get those four sheets out into separate workbooks (one sheet per workbook). Other than copying the file four times and deleting the sheets not wanted, is there a way to save a specific sheet as a new workbook? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Thu Jul 19 09:56:07 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 09:56:07 -0500 Subject: [AccessD] OT: Excel - Merge several cells In-Reply-To: <20070719143134.436C0BD57@smtp-auth.no-ip.com> References: <20070719143134.436C0BD57@smtp-auth.no-ip.com> Message-ID: <001b01c7ca14$efda5b50$0200a8c0@danwaters> There is a button immediately to the right of the right-hand justify button. It's called Merge and Center. 1) Select the cells you want to merge. (you might lose text) 2) Push the button. That's it! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 9:32 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Excel - Merge several cells I need to "merge" several cells to create one big cell. I have seen this in spreadsheets but have no idea how to do it myself. Any clue? For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and all the cells below them remain as they were. I need to put text in a "header cell". TIA John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Thu Jul 19 09:57:22 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 09:57:22 -0500 Subject: [AccessD] OT: Excel - Merge several cells In-Reply-To: <7303A459C921B5499AF732CCEEAD2B7F064D1103@craws161660.int.rdel.co.uk> References: <7303A459C921B5499AF732CCEEAD2B7F064D1103@craws161660.int.rdel.co.uk> Message-ID: <001c01c7ca15$1cd789c0$0200a8c0@danwaters> You can also use this method to 'unmerge' cells by unchecking the 'Merge cells' checkbox. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Foote, Chris Sent: Thursday, July 19, 2007 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Merge several cells Hi John! Select all the cells you need to "merge". Right mouse click. Select "Format Cells". Select "Alignment" tab. Select "Merge cells" check box. Click "OK" button. Viola! Regards Chris Foote > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 3:32 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Merge several cells > > > I need to "merge" several cells to create one big cell. I > have seen this in > spreadsheets but have no idea how to do it myself. > > Any clue? > > For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and > all the cells > below them remain as they were. I need to put text in a > "header cell". > > TIA > > John W. Colby > Colby Consulting > www.ColbyConsulting.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 jwcolby at colbyconsulting.com Thu Jul 19 10:02:21 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 11:02:21 -0400 Subject: [AccessD] OT: Excel - Get sheet out of workbook In-Reply-To: <001a01c7ca14$98637500$0200a8c0@danwaters> Message-ID: <20070719150222.85F73BF4B@smtp-auth.no-ip.com> Bueno. Silly me, I expect something like "select the sheet tab, right click, save as..." Makes too much sense I guess. Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Thursday, July 19, 2007 10:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Get sheet out of workbook Yes - 1) Go to Sheet X of Y. 2) Select the entire sheet by clicking the gray box at the intersection of columns and rows. 3) Copy 4) Open new workbook by clicking the New button. 5) Select the same gray box as in 2). 6) Paste 7) Repeat as needed. This will preserve the text formatting and column and row sizes. HTH! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 9:27 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Excel - Get sheet out of workbook I have a workbook with 4 sheets. I need to get those four sheets out into separate workbooks (one sheet per workbook). Other than copying the file four times and deleting the sheets not wanted, is there a way to save a specific sheet as a new workbook? John W. Colby Colby Consulting www.ColbyConsulting.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 markamatte at hotmail.com Thu Jul 19 10:10:33 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 19 Jul 2007 15:10:33 +0000 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: Hello All, This is just a 'mild' form of encryption...but I need to use math(+-*/) with numbers up to 16 digits(9,999,999,999,999,999)... Is there any way to do this without losing accuracy in VBA? Thanks, Mark A. Matte _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary!? http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 From cfoust at infostatsystems.com Thu Jul 19 10:10:17 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 19 Jul 2007 08:10:17 -0700 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <20070719015342.9BBFFBD0E@smtp-auth.no-ip.com> References: <000101c7c986$6ab2c590$c0b62ad1@SusanOne> <20070719015342.9BBFFBD0E@smtp-auth.no-ip.com> Message-ID: Try having an OhNoDecade ...:{ Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 6:54 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? Oh yea. My life is made up of a series of OhNoSeconds. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 5:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. =====Familiar to you, is it???? :) 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 jwcolby at colbyconsulting.com Thu Jul 19 10:20:44 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 11:20:44 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: Message-ID: <20070719152045.9DE34BD58@smtp-auth.no-ip.com> ROTFL. I am rapidly reaching that age where... John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 19, 2007 11:10 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Function to grab decimal value? Try having an OhNoDecade ...:{ Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 6:54 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? Oh yea. My life is made up of a series of OhNoSeconds. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 5:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. =====Familiar to you, is it???? :) Susan H. From reuben at gfconsultants.com Thu Jul 19 10:24:22 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Thu, 19 Jul 2007 11:24:22 -0400 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: Currency data types would be perfect if you are concerned about the accuracy of the decimals. However, it only handles 15 digits to the left of the decimal point (and four to the left). Single can be used well, but you will have to be careful how you handle rounding. I have to use single in several cases and then test, test, test to determine in what order, when, and where I should perform any rounding. Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte > Sent: Thursday, July 19, 2007 11:11 AM > To: accessd at databaseadvisors.com > Subject: [AccessD] Math in VBA > > > Hello All, > > This is just a 'mild' form of encryption...but I need to use > math(+-*/) with > numbers up to 16 digits(9,999,999,999,999,999)... > > Is there any way to do this without losing accuracy in VBA? > > Thanks, > > Mark A. Matte > > _________________________________________________________________ > Don't get caught with egg on your face. Play Chicktionary! > http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 > > From reuben at gfconsultants.com Thu Jul 19 10:34:31 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Thu, 19 Jul 2007 11:34:31 -0400 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: > decimal point (and four to the left). Should be four to the right Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Reuben > Cummings > Sent: Thursday, July 19, 2007 11:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Math in VBA > > > Currency data types would be perfect if you are concerned about > the accuracy > of the decimals. However, it only handles 15 digits to the left of the > decimal point (and four to the left). > > Single can be used well, but you will have to be careful how you handle > rounding. I have to use single in several cases and then test, test, test > to determine in what order, when, and where I should perform any rounding. > > Reuben Cummings > GFC, LLC > 812.523.1017 > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte > > Sent: Thursday, July 19, 2007 11:11 AM > > To: accessd at databaseadvisors.com > > Subject: [AccessD] Math in VBA > > > > > > Hello All, > > > > This is just a 'mild' form of encryption...but I need to use > > math(+-*/) with > > numbers up to 16 digits(9,999,999,999,999,999)... > > > > Is there any way to do this without losing accuracy in VBA? > > > > Thanks, > > > > Mark A. Matte > > > > _________________________________________________________________ > > Don't get caught with egg on your face. Play Chicktionary! > > http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 > > > > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From Lambert.Heenan at AIG.com Thu Jul 19 10:35:13 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Thu, 19 Jul 2007 11:35:13 -0400 Subject: [AccessD] OT: Excel - Get sheet out of workbook Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6C7D@xlivmbx35.aig.com> Even easier: Right Click the tab and select "Move Or Copy". In the Move or Copy dialog select "(new book)" in "To Book" combo and check the "Create a Copy" box at the bottom. That gives you an exact copy of the sheet in a new book. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 11:02 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Get sheet out of workbook Bueno. Silly me, I expect something like "select the sheet tab, right click, save as..." Makes too much sense I guess. Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Thursday, July 19, 2007 10:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Get sheet out of workbook Yes - 1) Go to Sheet X of Y. 2) Select the entire sheet by clicking the gray box at the intersection of columns and rows. 3) Copy 4) Open new workbook by clicking the New button. 5) Select the same gray box as in 2). 6) Paste 7) Repeat as needed. This will preserve the text formatting and column and row sizes. HTH! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 9:27 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Excel - Get sheet out of workbook I have a workbook with 4 sheets. I need to get those four sheets out into separate workbooks (one sheet per workbook). Other than copying the file four times and deleting the sheets not wanted, is there a way to save a specific sheet as a new workbook? John W. Colby Colby Consulting www.ColbyConsulting.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 Thu Jul 19 11:56:38 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 19 Jul 2007 18:56:38 +0200 Subject: [AccessD] Math in VBA Message-ID: Hi Mark That range is beyond the capacity of Currency, so your only chance without losing accuracy is probably to use a Variant with the subtype Decimal which can hold +/-79.228.162.514.264.337.593.543.950.335 with no decimals. Dim decNum As Variant decNum = CDec("9999999999999999") /gustav >>> markamatte at hotmail.com 19-07-2007 17:10 >>> Hello All, This is just a 'mild' form of encryption...but I need to use math(+-*/) with numbers up to 16 digits(9,999,999,999,999,999)... Is there any way to do this without losing accuracy in VBA? Thanks, Mark A. Matte From jwelz at hotmail.com Thu Jul 19 12:07:45 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 19 Jul 2007 11:07:45 -0600 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: You can perform math on the string just like you do it with pen and paper. For multiplication, start with the last digit of the 2nd number, multiply each digit of the first number, add the carries as you go and prepend the numbers to your string. Then take the 2nd last number, multiply each from the last digit, add the carries and then add the existing product to your current product, again as strings and add the carries, just like you would do it on a piece of paper. Keep going until you've gotten through all the digits. Division is a bit tougher because you need to truncate and then test with the multiplication whether you are above or below the number you're dividing into and the truncation can require you to try a lower digit if the additional digits put you over. All you really need to do is write an algorithm that works exactly the way you do it with pencil and paper. When we do multiplication, division, additon or subraction, we generally work with 2 'characters' at a time and that is fairly easy to mimic in VBA. There is no reason you couldn't do 10,000 digit numbers with complete precision. I've never seen such an algorithm but I'm sure they exist. If I needed it, I imagine I could write my own and get all four operators running in an hour or so. I'd start with an addition function; subraction is just adding a negative number and then multiplication and division would call the addition (and -) function with the intermediate solutions. I don't imagine it would be terribly fast, but 16 digits should be a piece of cake for a computer. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Mark A Matte" > >Hello All, > >This is just a 'mild' form of encryption...but I need to use math(+-*/) >with numbers up to 16 digits(9,999,999,999,999,999)... > >Is there any way to do this without losing accuracy in VBA? > >Thanks, > >Mark A. Matte _________________________________________________________________ New Windows Live Hotmail is here. Upgrade for free and get a better look. www.newhotmail.ca?icid=WLHMENCA150 From markamatte at hotmail.com Thu Jul 19 13:13:04 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 19 Jul 2007 18:13:04 +0000 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: Any ideas why ttt gives me an "OVERFLOW" error...but tt works just fine? Thanks, Mark Dim tt As Variant Dim ttt As Variant tt = CDec(36 ^ 10) ttt = CDec(36 * 36 * 36) >From: "Gustav Brock" >Reply-To: Access Developers discussion and problem >solving >To: >Subject: Re: [AccessD] Math in VBA >Date: Thu, 19 Jul 2007 18:56:38 +0200 > >Hi Mark > >That range is beyond the capacity of Currency, so your only chance without >losing accuracy is probably to use a Variant with the subtype Decimal which >can hold +/-79.228.162.514.264.337.593.543.950.335 with no decimals. > > Dim decNum As Variant > decNum = CDec("9999999999999999") > >/gustav > > >>> markamatte at hotmail.com 19-07-2007 17:10 >>> >Hello All, > >This is just a 'mild' form of encryption...but I need to use math(+-*/) >with >numbers up to 16 digits(9,999,999,999,999,999)... > >Is there any way to do this without losing accuracy in VBA? > >Thanks, > >Mark A. Matte > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://liveearth.msn.com From Gustav at cactus.dk Thu Jul 19 13:35:02 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 19 Jul 2007 20:35:02 +0200 Subject: [AccessD] Math in VBA Message-ID: Hi Mark Numbers may be handled as Integer if unknown. Specify as Long either: ttt = CDec(36& * 36& * 36&) or: Dim tt As Variant Dim ttt As Variant Dim d As Long d = 36 tt = CDec(d ^ 10) ttt = CDec(d * d * d) /gustav >>> markamatte at hotmail.com 19-07-2007 20:13 >>> Any ideas why ttt gives me an "OVERFLOW" error...but tt works just fine? Thanks, Mark Dim tt As Variant Dim ttt As Variant tt = CDec(36 ^ 10) ttt = CDec(36 * 36 * 36) >From: "Gustav Brock" >Reply-To: Access Developers discussion and problem >solving >To: >Subject: Re: [AccessD] Math in VBA >Date: Thu, 19 Jul 2007 18:56:38 +0200 > >Hi Mark > >That range is beyond the capacity of Currency, so your only chance without >losing accuracy is probably to use a Variant with the subtype Decimal which >can hold +/-79.228.162.514.264.337.593.543.950.335 with no decimals. > > Dim decNum As Variant > decNum = CDec("9999999999999999") > >/gustav > > >>> markamatte at hotmail.com 19-07-2007 17:10 >>> >Hello All, > >This is just a 'mild' form of encryption...but I need to use math(+-*/) with >numbers up to 16 digits(9,999,999,999,999,999)... > >Is there any way to do this without losing accuracy in VBA? > >Thanks, > >Mark A. Matte From cjeris at fas.harvard.edu Thu Jul 19 13:37:24 2007 From: cjeris at fas.harvard.edu (Christopher Jeris) Date: Thu, 19 Jul 2007 14:37:24 -0400 Subject: [AccessD] Math in VBA In-Reply-To: References: Message-ID: <469FAF64.60704@fas.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark A Matte wrote: > ttt = CDec(36 * 36 * 36) 6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up and kick someone in the head for leaving a 16-bit signed integer type in a program written after 1995. Try ttt = CDec(36) * CDec(36) * CDec(36) Also, be careful! > tt = CDec(36 ^ 10) That ^ is the _floating_point_ exponentiation operator! The result is not the integer 6^20; if you look at tt, you will see that it ends in a 0, which no power of 6 does. What you get there is the decimal conversion of the floating-point exponentiation. peace, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn69k5ICCNV0oGWARAjPHAJ9dz3+coNp2KVcjqwRK0FtFVFj9bACfW+oY JR0dThbFLOYR8UefedT5X48= =KxwX -----END PGP SIGNATURE----- From Patricia.O'Connor at otda.state.ny.us Thu Jul 19 13:39:58 2007 From: Patricia.O'Connor at otda.state.ny.us (O'Connor, Patricia (OTDA)) Date: Thu, 19 Jul 2007 14:39:58 -0400 Subject: [AccessD] OT: Excel - Get sheet out of workbook In-Reply-To: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> References: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> Message-ID: <01DBAB52E30A9A4AB3D94EF8029EDBE8021BAF0D@EXCNYSM0A1AI.nysemail.nyenet> IN EXCEL 2K3 RIGHT click on the TAB --> select MOVE or COPY ----> TO BOOK --- > drop down select (NEW book) ---> check mark CREATE A COPY this will save original and make a new copy bingo new workbook with one sheet ************************************************** * Patricia O'Connor * Associate Computer Programmer Analyst * OTDA - BDMA * (W) mailto:Patricia.O'Connor at otda.state.ny.us * (w) mailto:aa1160 at nysemail.state.ny.us ************************************************** > -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 10:27 AM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Get sheet out of workbook > > I have a workbook with 4 sheets. I need to get those four > sheets out into separate workbooks (one sheet per workbook). > Other than copying the file four times and deleting the > sheets not wanted, is there a way to save a specific sheet as > a new workbook? > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > From Patricia.O'Connor at otda.state.ny.us Thu Jul 19 13:47:03 2007 From: Patricia.O'Connor at otda.state.ny.us (O'Connor, Patricia (OTDA)) Date: Thu, 19 Jul 2007 14:47:03 -0400 Subject: [AccessD] OT: Excel - Merge several cells In-Reply-To: <001b01c7ca14$efda5b50$0200a8c0@danwaters> References: <20070719143134.436C0BD57@smtp-auth.no-ip.com> <001b01c7ca14$efda5b50$0200a8c0@danwaters> Message-ID: <01DBAB52E30A9A4AB3D94EF8029EDBE8021BAF0E@EXCNYSM0A1AI.nysemail.nyenet> FYI Unless there is a way to change things If there is text or even formulas in the other cells those will be lost. Only what is in the 1st (leftmost) cell will remain. Example cell1: Hello 1, Cell2: Iam2, Cell3: =A+B. Only "Hello 1" will remain if you merge all 3 cells Patti ************************************************** * Patricia O'Connor * Associate Computer Programmer Analyst * OTDA - BDMA * (W) mailto:Patricia.O'Connor at otda.state.ny.us * (w) mailto:aa1160 at nysemail.state.ny.us ************************************************** > -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Thursday, July 19, 2007 10:56 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] OT: Excel - Merge several cells > > There is a button immediately to the right of the right-hand > justify button. > It's called Merge and Center. > > 1) Select the cells you want to merge. (you might lose text) > 2) Push the button. > > That's it! > > Dan Waters > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 9:32 AM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Merge several cells > > I need to "merge" several cells to create one big cell. I > have seen this in spreadsheets but have no idea how to do it myself. > > Any clue? > > For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and > all the cells below them remain as they were. I need to put > text in a "header cell". > > TIA > > John W. Colby > Colby Consulting > www.ColbyConsulting.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 Thu Jul 19 14:25:42 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 19 Jul 2007 21:25:42 +0200 Subject: [AccessD] Math in VBA Message-ID: Hi Mark Chris is right. You have to keep the _numeric_ expressions within that of a Long if you wish to maintain accuracy. Thus: ? CDec(36 ^10) 3656158440062980 ? CDec(36 ^ 5) * CDec(36 ^ 5) 3656158440062976 because CDec(36 ^ 5) = 60466176. /gustav >>> cjeris at fas.harvard.edu 19-07-2007 20:37 >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark A Matte wrote: > ttt = CDec(36 * 36 * 36) 6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up and kick someone in the head for leaving a 16-bit signed integer type in a program written after 1995. Try ttt = CDec(36) * CDec(36) * CDec(36) Also, be careful! > tt = CDec(36 ^ 10) That ^ is the _floating_point_ exponentiation operator! The result is not the integer 6^20; if you look at tt, you will see that it ends in a 0, which no power of 6 does. What you get there is the decimal conversion of the floating-point exponentiation. peace, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn69k5ICCNV0oGWARAjPHAJ9dz3+coNp2KVcjqwRK0FtFVFj9bACfW+oY JR0dThbFLOYR8UefedT5X48= =KxwX -----END PGP SIGNATURE----- From robert at webedb.com Thu Jul 19 15:16:25 2007 From: robert at webedb.com (Robert L. Stewart) Date: Thu, 19 Jul 2007 15:16:25 -0500 Subject: [AccessD] Many to Many problem In-Reply-To: References: Message-ID: <200707192018.l6JKI5Sn018369@databaseadvisors.com> Kathryn, You can do it a couple of ways. You can have a subform with the collection that allows you to pick names that are associated with it and then enter the memo about it. (I would also have a date column there for when the memo was entered.) Or, you can have a subform on the names for so you can associate them with a collection and enter the memo there. Robert At 04:50 PM 7/18/2007, you wrote: >Date: Wed, 18 Jul 2007 11:13:53 -0700 >From: "Kathryn Bassett" >Subject: [AccessD] Many to Many problem part 2 - the tables and > question >To: "'Access Developers discussion and problem solving'" > >Message-ID: <006001c7c967$6661ac00$6401a8c0 at Kathryn> >Content-Type: text/plain; charset="windows-1250" > >Read part 1 first so you understand what the database is about. > >I have these three tables. > >tblCScollections > tblCScollectionID int(7) > tblCScollectionName varchar(50) >populated with the 11 collections we have at present. > >1 AckleyCarolyn >2 DunnPhillip >3 GardnerDavid >4 HilbigWalter >5 HollingsworthHarry >6 PriceRichard >7 SmithJeremiah >8 MillsVirginia >9 MooreWilburta >10 MottAnita >11 SmithConley > >tblCSnames > tblCSnamesID int(7) > tblCSlastname varchar(50) > tblCSfirstname varchar(50) >populated with > >1 Van Horn G. Armour >2 Bassett Kathryn >3 Day Win >4 Sullivan Stephanie >5 Gentry Doug >6 Lohmar Michael > >tblCSmemos > tblCScollectionID > tblCSnamesID > tblCSmemo >not populated at all at present > >Bottom line is that I now understand the two+middle table concept. >The inputting of data into the database is where I'm having a problem. > >The flat way I *had* been thinking (using spreadsheet analogy) is >that column A/B is lastname/firstname, column B is collectionID1, >column C is the memo for collectionID1 and the rest of the columns >are like columcs C/D for each collection. I put "true" in each >collection ID column that the name in row 2 (or 3 or 4) appears in. > >Now if Win Day (nameID=3) was ONLY in one collection, then a >dropdown box of the collection names would work. But since nameID=3 >is in multiple collections and may or may not have a memo, I'm not >clear on how to do the input. > >Help? From BarbaraRyan at cox.net Thu Jul 19 18:50:35 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Thu, 19 Jul 2007 19:50:35 -0400 Subject: [AccessD] One-to-One relationships Message-ID: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? Thanks, Barb Ryan From cfoust at infostatsystems.com Thu Jul 19 19:01:05 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 19 Jul 2007 17:01:05 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: Definitely, IMO, especially in databases where you may have different kinds of customers. For example, a business and a non-profit and an individual and a family group could all be customers, but would have differing kinds of information. Using one-to-one relationships, you could have a single Customer table that had the minimum information that would be collected on all customers, regardless of type. Then you could have a separate table for Organization and one for Persons. The PK in each of those tables would be inherited from the Customer table. This would also allow you to have other tables with common information hanging off the customer table instead of the Organization or Persons table. You might want to hang the Address table off Customers, for example, since addresses are fairly consistent. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan Sent: Thursday, July 19, 2007 4:51 PM To: Access List Subject: [AccessD] One-to-One relationships Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? Thanks, Barb Ryan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Thu Jul 19 19:09:15 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 20 Jul 2007 12:09:15 +1200 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: <469FFD2B.5050201@mvps.org> Barb, Not in the example you gave, no. Given that you will be recording sex, address, phone for all, or almost all, of the customers. The main use for one-to-one relationships is in a sub-typing scenario. This is where you have data where there are some data in common for all/most records, but there are also fields required specific to certain categories of the main data. Regards Steve Barbara Ryan wrote: > Is there any purpose/advantage in creating a one-to-one relationship > in a database (e.g., CustomerId and CustomerName in one table and all > the other customer data (e.g., sex, address, phone, etc) in another > table? From martyconnelly at shaw.ca Thu Jul 19 19:31:00 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 19 Jul 2007 17:31:00 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: <46A00244.6080609@shaw.ca> This quick article might explain http://www.allenbrowne.com/AppHuman.html Barbara Ryan wrote: >Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? > >Thanks, >Barb Ryan > > -- Marty Connelly Victoria, B.C. Canada From jwcolby at colbyconsulting.com Thu Jul 19 20:41:48 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 21:41:48 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: <20070720014150.891B8BC7A@smtp-auth.no-ip.com> In your example, maybe, maybe not. I have a database where there is a claim table and three different "extension" tables which are 1 to 1 with the claim table. TblClaimSTD is for short term disability claims, and stores information specific to short term claims. There is also a (you guessed it) tblClaimLTD for long term disability and stores all the claim information specific to long term claims. There is a third table tblWP or waiver of premium where claim waiver of premium information is stored. In all these cases there is a rather large table with information that is in every claim, and then one of those three "extension" tables with information about one of those three specific types of claims. 1-1 tables require special handling in entering data as well as displaying / reporting the data. Whether it is worth doing is a question that bears asking in any specific case. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan Sent: Thursday, July 19, 2007 7:51 PM To: Access List Subject: [AccessD] One-to-One relationships Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? Thanks, Barb Ryan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From clh at christopherhawkins.com Fri Jul 20 01:45:30 2007 From: clh at christopherhawkins.com (Christopher Hawkins) Date: Fri, 20 Jul 2007 00:45:30 -0600 Subject: [AccessD] ASP, anyone? Message-ID: <0efb6bb432b54680bdb48a3db0aa1772@mail1.gearhost.com> I know we have a vb.net mailing list...is there an asp or asp.net mailing list as well? Or am I the only one who spends a significant amount of time working with asp here? -Christopher Hawkins- From ssharkins at setel.com Fri Jul 20 07:45:34 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 08:45:34 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: <006501c7cacb$f129aa80$94b82ad1@SusanOne> Yes, if it has a purpose. A one-to-one relationship almost always flows from need rather from the data itself. If you need to force a one-to-one, I'd say do it. However, if there's no business rule saying, "there can be only one..." it might be unnecessary, even if the data is presenting that picture right now. Listen to the data. Susan H. Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? From jwcolby at colbyconsulting.com Fri Jul 20 08:14:07 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 09:14:07 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <006501c7cacb$f129aa80$94b82ad1@SusanOne> Message-ID: <20070720131410.771FDBEC3@smtp-auth.no-ip.com> >Listen to the data. And may the force be with you... ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 20, 2007 8:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Yes, if it has a purpose. A one-to-one relationship almost always flows from need rather from the data itself. If you need to force a one-to-one, I'd say do it. However, if there's no business rule saying, "there can be only one..." it might be unnecessary, even if the data is presenting that picture right now. Listen to the data. Susan H. Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? -- 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 Jul 20 08:24:08 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 09:24:08 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <006501c7cacb$f129aa80$94b82ad1@SusanOne> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> <006501c7cacb$f129aa80$94b82ad1@SusanOne> Message-ID: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> I would respectfully suggest that you're overlooking something in your analysis, Susan, but to observe it you need millions of rows in the given table. But suppose that you have a table called Customers, which as previously suggested in this thread might include both corporations and persons. The first rule of database development is performance, above all other considerations. Therefore one ought to identify the columns of immediate interest (CustomerID, CustomerName, etc.) and store those in a single table, pushing all the other attributes to one or more related tables with a 1:1 relationship. This way, I can search a small table with multiple indexes very quickly, and not bother with fetching the rest of the data until you explicitly request it, at which point it would be a lightning-quick sproc that receives a CustomerID and sends back the rest of the data. If you really want to push the performance button, then you won't return a rowset either. Instead you'll declare as many parameters as you have columns of interest, and declare them all Output parameters. When you want exactly one record, that's the quickest method. I hope I didn't obscure the point here. The point is what I call the Sally Rand principle. (You might have to be older than even I to understand the reference -- she was a famous stripper, back when stripping meant that you still retained most of your clothes.) Her point was, show them as little as possible to still maintain their interest. That's my motto in terms of database design. Never open an entire table. Show them only enough to pique their curiosity, as it were. On 7/20/07, Susan Harkins wrote: > > Yes, if it has a purpose. A one-to-one relationship almost always flows > from > need rather from the data itself. If you need to force a one-to-one, I'd > say > do it. However, if there's no business rule saying, "there can be only > one..." it might be unnecessary, even if the data is presenting that > picture > right now. Listen to the data. > > Susan H. > > Is there any purpose/advantage in creating a one-to-one relationship in a > database (e.g., CustomerId and CustomerName in one table and all the other > customer data (e.g., sex, address, phone, etc) in another table? > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From markamatte at hotmail.com Fri Jul 20 08:32:07 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 20 Jul 2007 13:32:07 +0000 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: Thanks Everyone, I ended up using a loop to get my powers...before I was the power by 1 for each record...now I added a new loop to get the actual number if you calculated out to the nth power. I was in the quadrillions when I finished. Thanks Again, Mark Power = Power - 1 PowerNum = CDec(36) For PNLoop = 1 To Power - 1 PowerNum = CDec(PowerNum * CDec(36)) Next >From: "Gustav Brock" >Reply-To: Access Developers discussion and problem >solving >To: >Subject: Re: [AccessD] Math in VBA >Date: Thu, 19 Jul 2007 21:25:42 +0200 > >Hi Mark > >Chris is right. You have to keep the _numeric_ expressions within that of a >Long if you wish to maintain accuracy. > >Thus: >? CDec(36 ^10) > 3656158440062980 >? CDec(36 ^ 5) * CDec(36 ^ 5) > 3656158440062976 > >because CDec(36 ^ 5) = 60466176. > >/gustav > > >>> cjeris at fas.harvard.edu 19-07-2007 20:37 >>> >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Mark A Matte wrote: > > ttt = CDec(36 * 36 * 36) > >6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up >and kick someone in the head for leaving a 16-bit signed integer type in >a program written after 1995. > >Try >ttt = CDec(36) * CDec(36) * CDec(36) > >Also, be careful! > > tt = CDec(36 ^ 10) > >That ^ is the _floating_point_ exponentiation operator! The result is >not the integer 6^20; if you look at tt, you will see that it ends in a >0, which no power of 6 does. What you get there is the decimal >conversion of the floating-point exponentiation. > >peace, Chris Jeris > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.6 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFGn69k5ICCNV0oGWARAjPHAJ9dz3+coNp2KVcjqwRK0FtFVFj9bACfW+oY >JR0dThbFLOYR8UefedT5X48= >=KxwX >-----END PGP SIGNATURE----- > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From Jim.Hale at FleetPride.com Fri Jul 20 08:37:49 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Fri, 20 Jul 2007 08:37:49 -0500 Subject: [AccessD] One-to-One relationships In-Reply-To: <006501c7cacb$f129aa80$94b82ad1@SusanOne> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> <006501c7cacb$f129aa80$94b82ad1@SusanOne> Message-ID: Or hire a Data Whisperer to do it for you :-) Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 20, 2007 7:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Yes, if it has a purpose. A one-to-one relationship almost always flows from need rather from the data itself. If you need to force a one-to-one, I'd say do it. However, if there's no business rule saying, "there can be only one..." it might be unnecessary, even if the data is presenting that picture right now. Listen to the data. Susan H. Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From jwcolby at colbyconsulting.com Fri Jul 20 08:45:06 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 09:45:06 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> Message-ID: <20070720134509.05E67BC79@smtp-auth.no-ip.com> Arthur, You've been on about strippers as long as I've known you. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 9:24 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships I would respectfully suggest that you're overlooking something in your analysis, Susan, but to observe it you need millions of rows in the given table. But suppose that you have a table called Customers, which as previously suggested in this thread might include both corporations and persons. The first rule of database development is performance, above all other considerations. Therefore one ought to identify the columns of immediate interest (CustomerID, CustomerName, etc.) and store those in a single table, pushing all the other attributes to one or more related tables with a 1:1 relationship. This way, I can search a small table with multiple indexes very quickly, and not bother with fetching the rest of the data until you explicitly request it, at which point it would be a lightning-quick sproc that receives a CustomerID and sends back the rest of the data. If you really want to push the performance button, then you won't return a rowset either. Instead you'll declare as many parameters as you have columns of interest, and declare them all Output parameters. When you want exactly one record, that's the quickest method. I hope I didn't obscure the point here. The point is what I call the Sally Rand principle. (You might have to be older than even I to understand the reference -- she was a famous stripper, back when stripping meant that you still retained most of your clothes.) Her point was, show them as little as possible to still maintain their interest. That's my motto in terms of database design. Never open an entire table. Show them only enough to pique their curiosity, as it were. From fuller.artful at gmail.com Fri Jul 20 08:50:16 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 09:50:16 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720134509.05E67BC79@smtp-auth.no-ip.com> References: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> <20070720134509.05E67BC79@smtp-auth.no-ip.com> Message-ID: <29f585dd0707200650p694efc6cxb3ff56e7b7606954@mail.gmail.com> LOL. On 7/20/07, jwcolby wrote: > > Arthur, > > You've been on about strippers as long as I've known you. > > ;-) > From john at winhaven.net Fri Jul 20 10:00:10 2007 From: john at winhaven.net (John Bartow) Date: Fri, 20 Jul 2007 10:00:10 -0500 Subject: [AccessD] ASP, anyone? In-Reply-To: <0efb6bb432b54680bdb48a3db0aa1772@mail1.gearhost.com> References: <0efb6bb432b54680bdb48a3db0aa1772@mail1.gearhost.com> Message-ID: <00f701c7cade$ac568410$6402a8c0@ScuzzPaq> Hi Christopher, Awhile back we asked the list population to email if they would like an ASP specific list to be setup. The response was low. However, if we have more people interested in this now we certainly could set up an ASP specific list. If any of you are interested in having a DBA-ASP list setup o discuss ASP related issues please let me know. John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher Hawkins Sent: Friday, July 20, 2007 1:46 AM To: accessd at databaseadvisors.com Subject: [AccessD] ASP, anyone? I know we have a vb.net mailing list...is there an asp or asp.net mailing list as well? Or am I the only one who spends a significant amount of time working with asp here? -Christopher Hawkins- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Fri Jul 20 10:09:25 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 08:09:25 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35><006501c7cacb$f129aa80$94b82ad1@SusanOne> <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> Message-ID: Actually, she was a fan dancer, which is different from a stripper, since they start out without much on and wave the fans around to expose bits at a time. She was quite famous in her time. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 6:24 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships I would respectfully suggest that you're overlooking something in your analysis, Susan, but to observe it you need millions of rows in the given table. But suppose that you have a table called Customers, which as previously suggested in this thread might include both corporations and persons. The first rule of database development is performance, above all other considerations. Therefore one ought to identify the columns of immediate interest (CustomerID, CustomerName, etc.) and store those in a single table, pushing all the other attributes to one or more related tables with a 1:1 relationship. This way, I can search a small table with multiple indexes very quickly, and not bother with fetching the rest of the data until you explicitly request it, at which point it would be a lightning-quick sproc that receives a CustomerID and sends back the rest of the data. If you really want to push the performance button, then you won't return a rowset either. Instead you'll declare as many parameters as you have columns of interest, and declare them all Output parameters. When you want exactly one record, that's the quickest method. I hope I didn't obscure the point here. The point is what I call the Sally Rand principle. (You might have to be older than even I to understand the reference -- she was a famous stripper, back when stripping meant that you still retained most of your clothes.) Her point was, show them as little as possible to still maintain their interest. That's my motto in terms of database design. Never open an entire table. Show them only enough to pique their curiosity, as it were. On 7/20/07, Susan Harkins wrote: > > Yes, if it has a purpose. A one-to-one relationship almost always > flows from need rather from the data itself. If you need to force a > one-to-one, I'd say do it. However, if there's no business rule > saying, "there can be only one..." it might be unnecessary, even if > the data is presenting that picture right now. Listen to the data. > > Susan H. > > Is there any purpose/advantage in creating a one-to-one relationship > in a database (e.g., CustomerId and CustomerName in one table and all > the other customer data (e.g., sex, address, phone, etc) in another table? > > > -- > 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 ebarro at verizon.net Fri Jul 20 10:18:27 2007 From: ebarro at verizon.net (Eric Barro) Date: Fri, 20 Jul 2007 08:18:27 -0700 Subject: [AccessD] ASP, anyone? In-Reply-To: <00f701c7cade$ac568410$6402a8c0@ScuzzPaq> Message-ID: <0JLH00L83H672T58@vms042.mailsrvcs.net> I develop exclusively in ASP/ASP.NET and I would be interested in an ASP specific list as well. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Friday, July 20, 2007 8:00 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] ASP, anyone? Hi Christopher, Awhile back we asked the list population to email if they would like an ASP specific list to be setup. The response was low. However, if we have more people interested in this now we certainly could set up an ASP specific list. If any of you are interested in having a DBA-ASP list setup o discuss ASP related issues please let me know. John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher Hawkins Sent: Friday, July 20, 2007 1:46 AM To: accessd at databaseadvisors.com Subject: [AccessD] ASP, anyone? I know we have a vb.net mailing list...is there an asp or asp.net mailing list as well? Or am I the only one who spends a significant amount of time working with asp here? -Christopher Hawkins- From fuller.artful at gmail.com Fri Jul 20 10:21:31 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 11:21:31 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> <006501c7cacb$f129aa80$94b82ad1@SusanOne> <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> Message-ID: <29f585dd0707200821i10dd90a2jdc33207d09a1c232@mail.gmail.com> Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to expose > bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and store > those in a single table, pushing all the other attributes to one or more > related tables with a 1:1 relationship. This way, I can search a small > table with multiple indexes very quickly, and not bother with fetching > the rest of the data until you explicitly request it, at which point it > would be a lightning-quick sproc that receives a CustomerID and sends > back the rest of the data. If you really want to push the performance > button, then you won't return a rowset either. Instead you'll declare as > many parameters as you have columns of interest, and declare them all > Output parameters. When you want exactly one record, that's the quickest > method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her point > was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and all > > the other customer data (e.g., sex, address, phone, etc) in another > table? > > > > > > -- > > 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 cfoust at infostatsystems.com Fri Jul 20 10:24:50 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 08:24:50 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707200821i10dd90a2jdc33207d09a1c232@mail.gmail.com> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35><006501c7cacb$f129aa80$94b82ad1@SusanOne><29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> <29f585dd0707200821i10dd90a2jdc33207d09a1c232@mail.gmail.com> Message-ID: What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 jwcolby at colbyconsulting.com Fri Jul 20 10:39:24 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 11:39:24 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: Message-ID: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 Jim.Hale at FleetPride.com Fri Jul 20 10:47:14 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Fri, 20 Jul 2007 10:47:14 -0500 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: Because developers are used to exposing different objects one at a time? JH -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 10:39 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From john at winhaven.net Fri Jul 20 10:01:37 2007 From: john at winhaven.net (John Bartow) Date: Fri, 20 Jul 2007 10:01:37 -0500 Subject: [AccessD] Request for new DBA List to discuss specific subjects Message-ID: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> If anyone has a request for a new DBA list to discuss a specific subject please email me directly. Also, please leave this subject line in tact so I can sort these messages into a new email folder. Thanks, John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Fri Jul 20 10:48:29 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 20 Jul 2007 08:48:29 -0700 Subject: [AccessD] OT: Deal of the Day Message-ID: <004801c7cae5$6b62d830$0301a8c0@HAL9005> Today at Fry's: GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... $149.00. How do they make any money on this? Rocky From max at sherman.org.uk Fri Jul 20 10:54:54 2007 From: max at sherman.org.uk (Max Sherman) Date: Fri, 20 Jul 2007 16:54:54 +0100 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: <014c01c7cae6$54a421c0$8119fea9@LTVM> Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 4:39 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 cfoust at infostatsystems.com Fri Jul 20 10:51:20 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 08:51:20 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: I've always been interested in theater and stage productions. Sally Rand performed in some of Billy Rose's productions. I think she even danced at a World's Fair. In any event I saw a publicity photo of her once, with a thin strip of Sally showing between two enormouse ostrich feather fans. I assume she wasn't ticklish! LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 8:39 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 cfoust at infostatsystems.com Fri Jul 20 10:51:53 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 08:51:53 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: ROTFLMAO Right!! Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim Sent: Friday, July 20, 2007 8:47 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Because developers are used to exposing different objects one at a time? JH -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 10:39 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. -- 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 Jul 20 10:58:15 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 11:58:15 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: <29f585dd0707200858w71a2f30evf7d4a2f2af5e38d9@mail.gmail.com> This is becoming way too sick even for my admittedly deviant interests. But hats off to Charlotte for The Mrs. Henderson's phrase, and I don't think I'll bother finding a rhyme for Charlotte. I guess it must be Friday! On 7/20/07, Hale, Jim wrote: > > > Because developers are used to exposing different objects one at a time? > JH > From cfoust at infostatsystems.com Fri Jul 20 11:00:33 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 09:00:33 -0700 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <014c01c7cae6$54a421c0$8119fea9@LTVM> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> <014c01c7cae6$54a421c0$8119fea9@LTVM> Message-ID: Traditionally, Fridays are very relaxed days with lots of nonsense. Developers can only be serious for a limited period of time before going totally insane, so we need at least one day a week to blow off some steam. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 4:39 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 fuller.artful at gmail.com Fri Jul 20 11:27:01 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 12:27:01 -0400 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> <014c01c7cae6$54a421c0$8119fea9@LTVM> Message-ID: <29f585dd0707200927j4311173ch9c7c2669e2f77325@mail.gmail.com> Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before going > totally insane, so we need at least one day a week to blow off some > steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Friday, July 20, 2007 4:39 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Charlotte, and how do you know all this? I can understand Arthur having > this prurient interest, but you? > > Inquiring minds want to know. ;-) > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte > Foust > Sent: Friday, July 20, 2007 11:25 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > What, "Mrs Henderson Presents" wasn't international enough for you? LOL > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Friday, July 20, 2007 8:22 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > Wow! I used the term "stripper" because I deferred to the international > character of this list, but you're entirely correct! Applause to you > from here, Charlotte. You are sooo correct. > > On 7/20/07, Charlotte Foust wrote: > > > > Actually, she was a fan dancer, which is different from a stripper, > > since they start out without much on and wave the fans around to > > expose bits at a time. She was quite famous in her time. > > > > Charlotte Foust > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > > Fuller > > Sent: Friday, July 20, 2007 6:24 AM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] One-to-One relationships > > > > I would respectfully suggest that you're overlooking something in your > > > analysis, Susan, but to observe it you need millions of rows in the > > given table. But suppose that you have a table called Customers, which > > > as previously suggested in this thread might include both corporations > > > and persons. The first rule of database development is performance, > > above all other considerations. Therefore one ought to identify the > > columns of immediate interest (CustomerID, CustomerName, etc.) and > > store those in a single table, pushing all the other attributes to one > > > or more related tables with a 1:1 relationship. This way, I can search > > > a small table with multiple indexes very quickly, and not bother with > > fetching the rest of the data until you explicitly request it, at > > which point it would be a lightning-quick sproc that receives a > > CustomerID and sends back the rest of the data. If you really want to > > push the performance button, then you won't return a rowset either. > > Instead you'll declare as many parameters as you have columns of > > interest, and declare them all Output parameters. When you want > > exactly one record, that's the quickest method. > > > > I hope I didn't obscure the point here. The point is what I call the > > Sally Rand principle. (You might have to be older than even I to > > understand the reference -- she was a famous stripper, back when > > stripping meant that you still retained most of your clothes.) Her > > point was, show them as little as possible to still maintain their > interest. > > That's my motto in terms of database design. Never open an entire > table. > > Show them only enough to pique their curiosity, as it were. > > > > On 7/20/07, Susan Harkins wrote: > > > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > > flows from need rather from the data itself. If you need to force a > > > one-to-one, I'd say do it. However, if there's no business rule > > > saying, "there can be only one..." it might be unnecessary, even if > > > the data is presenting that picture right now. Listen to the data. > > > > > > Susan H. > > > > > > Is there any purpose/advantage in creating a one-to-one relationship > > > > in a database (e.g., CustomerId and CustomerName in one table and > > > all the other customer data (e.g., sex, address, phone, etc) in > > > another > > table? > > > > > > > > > -- > > > 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 jmhecht at earthlink.net Fri Jul 20 11:45:06 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Fri, 20 Jul 2007 09:45:06 -0700 (GMT-07:00) Subject: [AccessD] OT: Deal of the Day Message-ID: <21470712.1184949906343.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> cause CompUSA aint around no more ? Joe Ex compUSA employee -----Original Message----- >From: Rocky Smolin at Beach Access Software >Sent: Jul 20, 2007 8:48 AM >To: dba-ot at databaseadvisors.com, 'Access Developers discussion and problem solving' >Subject: [AccessD] OT: Deal of the Day > >Today at Fry's: > >GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB >RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... > > >$149.00. > > >How do they make any money on this? > > >Rocky > > > > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From JHewson at karta.com Fri Jul 20 11:53:30 2007 From: JHewson at karta.com (Jim Hewson) Date: Fri, 20 Jul 2007 11:53:30 -0500 Subject: [AccessD] OT: Deal of the Day In-Reply-To: <21470712.1184949906343.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> References: <21470712.1184949906343.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Message-ID: We have CompUSA but NO Fry's. Jim jhewson at karta.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe Hecht Sent: Friday, July 20, 2007 11:45 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] OT: Deal of the Day cause CompUSA aint around no more ? Joe Ex compUSA employee -----Original Message----- >From: Rocky Smolin at Beach Access Software >Sent: Jul 20, 2007 8:48 AM >To: dba-ot at databaseadvisors.com, 'Access Developers discussion and problem solving' >Subject: [AccessD] OT: Deal of the Day > >Today at Fry's: > >GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB >RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... > > >$149.00. > > >How do they make any money on this? > > >Rocky > > > > > > >-- >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 max at sherman.org.uk Fri Jul 20 12:00:35 2007 From: max at sherman.org.uk (Max Sherman) Date: Fri, 20 Jul 2007 18:00:35 +0100 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <29f585dd0707200927j4311173ch9c7c2669e2f77325@mail.gmail.com> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com><014c01c7cae6$54a421c0$8119fea9@LTVM> <29f585dd0707200927j4311173ch9c7c2669e2f77325@mail.gmail.com> Message-ID: <015901c7caef$810bb0d0$8119fea9@LTVM> Thank you, I would appreciate that. I also appreciate the many useful contributions thay you all put in. Max Ps. I have been subscribing to Peach List for some 9 maybe more years now, so I do understand how it works. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 5:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before > going totally insane, so we need at least one day a week to blow off > some steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Friday, July 20, 2007 4:39 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Charlotte, and how do you know all this? I can understand Arthur > having this prurient interest, but you? > > Inquiring minds want to know. ;-) > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte > Foust > Sent: Friday, July 20, 2007 11:25 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > What, "Mrs Henderson Presents" wasn't international enough for you? > LOL > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 8:22 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > Wow! I used the term "stripper" because I deferred to the > international character of this list, but you're entirely correct! > Applause to you from here, Charlotte. You are sooo correct. > > On 7/20/07, Charlotte Foust wrote: > > > > Actually, she was a fan dancer, which is different from a stripper, > > since they start out without much on and wave the fans around to > > expose bits at a time. She was quite famous in her time. > > > > Charlotte Foust > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > > Fuller > > Sent: Friday, July 20, 2007 6:24 AM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] One-to-One relationships > > > > I would respectfully suggest that you're overlooking something in > > your > > > analysis, Susan, but to observe it you need millions of rows in the > > given table. But suppose that you have a table called Customers, > > which > > > as previously suggested in this thread might include both > > corporations > > > and persons. The first rule of database development is performance, > > above all other considerations. Therefore one ought to identify the > > columns of immediate interest (CustomerID, CustomerName, etc.) and > > store those in a single table, pushing all the other attributes to > > one > > > or more related tables with a 1:1 relationship. This way, I can > > search > > > a small table with multiple indexes very quickly, and not bother > > with fetching the rest of the data until you explicitly request it, > > at which point it would be a lightning-quick sproc that receives a > > CustomerID and sends back the rest of the data. If you really want > > to push the performance button, then you won't return a rowset either. > > Instead you'll declare as many parameters as you have columns of > > interest, and declare them all Output parameters. When you want > > exactly one record, that's the quickest method. > > > > I hope I didn't obscure the point here. The point is what I call the > > Sally Rand principle. (You might have to be older than even I to > > understand the reference -- she was a famous stripper, back when > > stripping meant that you still retained most of your clothes.) Her > > point was, show them as little as possible to still maintain their > interest. > > That's my motto in terms of database design. Never open an entire > table. > > Show them only enough to pique their curiosity, as it were. > > > > On 7/20/07, Susan Harkins wrote: > > > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > > flows from need rather from the data itself. If you need to force > > > a one-to-one, I'd say do it. However, if there's no business rule > > > saying, "there can be only one..." it might be unnecessary, even > > > if the data is presenting that picture right now. Listen to the data. > > > > > > Susan H. > > > > > > Is there any purpose/advantage in creating a one-to-one > > > relationship > > > > in a database (e.g., CustomerId and CustomerName in one table and > > > all the other customer data (e.g., sex, address, phone, etc) in > > > another > > table? > > > > > > > > > -- > > > 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 rockysmolin at bchacc.com Fri Jul 20 12:01:52 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 20 Jul 2007 10:01:52 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <014c01c7cae6$54a421c0$8119fea9@LTVM> Message-ID: <005601c7caef$abd0f0a0$0301a8c0@HAL9005> It's OT Friday. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 4:39 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 7/19/2007 6:10 PM From DWUTKA at Marlow.com Fri Jul 20 12:09:46 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Fri, 20 Jul 2007 12:09:46 -0500 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: Message-ID: I wish I would have known this earlier...... is there hope of recovery if you've gone totally insane? ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:01 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Traditionally, Fridays are very relaxed days with lots of nonsense. Developers can only be serious for a limited period of time before going totally insane, so we need at least one day a week to blow off some steam. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwcolby at colbyconsulting.com Fri Jul 20 12:31:13 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 13:31:13 -0400 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <015901c7caef$810bb0d0$8119fea9@LTVM> Message-ID: <20070720173116.542ABBDDD@smtp-auth.no-ip.com> BTW Max, this is an Access list. I am not yanking your chain or anything, I just noticed that you mentioned "sticking to VBA". We do have a VB list as well which (other than OT Friday) pretty much sticks to VBA and VB.Net. I am going to make an assumption that you are new to our list and welcome you aboard. I'll also take this opportunity to explain that we are a community as well as a "list". There are a TON of developers who have been on this list for 10 years or more. As such we do tend to get a little more personal than some other lists. We are friends as well as developers. We have people assigned to police the list should things get too out of hand and we mostly leave it up to them to do the policing. But we do not run as tight a ship as you might be accustomed to on other lists and we like it that way. You are of course welcomed to the list, welcomed to contribute and hang out, but if you expect this list to be "just the facts ma'am", I can tell you up front you are in the wrong place. So welcome to the list and I hope you enjoy the community as much as you enjoy the immense knowledge base that our members bring to the list. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 1:01 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT Thank you, I would appreciate that. I also appreciate the many useful contributions thay you all put in. Max Ps. I have been subscribing to Peach List for some 9 maybe more years now, so I do understand how it works. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 5:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before > going totally insane, so we need at least one day a week to blow off > some steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max From ebarro at verizon.net Fri Jul 20 13:05:32 2007 From: ebarro at verizon.net (Eric Barro) Date: Fri, 20 Jul 2007 11:05:32 -0700 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <20070720173116.542ABBDDD@smtp-auth.no-ip.com> Message-ID: <0JLH00119OX00LPC@vms044.mailsrvcs.net> And this is what makes this list a community that stands above the rest. Most started off with Access and have since then moved on to other technologies such as .NET, SQL, Sharepoint, heck even Linux-based technologies. And those people still stick around because this list covers more than just straight "Microsoft Access-specific" topics. Otherwise you'd be better off going to Google to find answers... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 10:31 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT BTW Max, this is an Access list. I am not yanking your chain or anything, I just noticed that you mentioned "sticking to VBA". We do have a VB list as well which (other than OT Friday) pretty much sticks to VBA and VB.Net. I am going to make an assumption that you are new to our list and welcome you aboard. I'll also take this opportunity to explain that we are a community as well as a "list". There are a TON of developers who have been on this list for 10 years or more. As such we do tend to get a little more personal than some other lists. We are friends as well as developers. We have people assigned to police the list should things get too out of hand and we mostly leave it up to them to do the policing. But we do not run as tight a ship as you might be accustomed to on other lists and we like it that way. You are of course welcomed to the list, welcomed to contribute and hang out, but if you expect this list to be "just the facts ma'am", I can tell you up front you are in the wrong place. So welcome to the list and I hope you enjoy the community as much as you enjoy the immense knowledge base that our members bring to the list. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 1:01 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT Thank you, I would appreciate that. I also appreciate the many useful contributions thay you all put in. Max Ps. I have been subscribing to Peach List for some 9 maybe more years now, so I do understand how it works. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 5:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before > going totally insane, so we need at least one day a week to blow off > some steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Fri Jul 20 13:21:12 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 14:21:12 -0400 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: Message-ID: <20070720182115.3FF0FBF54@smtp-auth.no-ip.com> In your case? No. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Friday, July 20, 2007 1:10 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT I wish I would have known this earlier...... is there hope of recovery if you've gone totally insane? ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:01 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Traditionally, Fridays are very relaxed days with lots of nonsense. Developers can only be serious for a limited period of time before going totally insane, so we need at least one day a week to blow off some steam. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From max at sherman.org.uk Fri Jul 20 13:23:35 2007 From: max at sherman.org.uk (Max Sherman) Date: Fri, 20 Jul 2007 19:23:35 +0100 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <20070720173116.542ABBDDD@smtp-auth.no-ip.com> References: <015901c7caef$810bb0d0$8119fea9@LTVM> <20070720173116.542ABBDDD@smtp-auth.no-ip.com> Message-ID: <016901c7cafb$16d79e20$8119fea9@LTVM> >>There are a TON of developers who have been on this list for 10 years or more Yes, I am one of them. >> VBA Only said in a generalised sense, not to be restrictive. Perhaps I should have said "Access" >>we mostly leave it up to them to do the policing. Perhaps they need to check more often. Certainly if I were one of the scrutinisers, I would have spoken up by now. >>tight a ship as you might be accustomed to on other lists I don't need a tight ship. Some of the OT posting are very helpful and often informative - some amusing. BUT "one-liners" bouncing back and forward between a few people is just too much. Whatever your reasons, please remember what the purpose of this list is. It is there, as are all the other lists, to assist people and share information. There are plenty of joke lists around and if people feel a need then perhaps they could have a sub-list for those that feel the need to bounce these sort of things between them. What you are forgetting is that there are many people ("the silent majority") who just, like me I would suggest, just groan and hit the delete key. All I am attempting to do, is perhaps, respectfully, remind people that even on OT Friday, there is a limit to what should be acceptable. And this nonsense bouncing back and forward about strippers and fan dancers is just one posting to many for me - and that is after 10 odd years! Repartee, for my part, is not required. I have no doubt that you and your friend will come back on this, but before you do please remember that none of my comments are made as a personal criticism, but only as a reminder that there are others out there who will also be receiving your postings. Whilst posters might feel that they have made the "comment of the century", others would not view it as so. Also, remember, like many others, that I am very appreciative of the much help that all the contributors have given (freely) over the years. I have had much help and for that I am very grateful. I do not post very often, but I read and often take on board the good ideas that come off the list. Thank you all for that. Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 6:31 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT BTW Max, this is an Access list. I am not yanking your chain or anything, I just noticed that you mentioned "sticking to VBA". We do have a VB list as well which (other than OT Friday) pretty much sticks to VBA and VB.Net. I am going to make an assumption that you are new to our list and welcome you aboard. I'll also take this opportunity to explain that we are a community as well as a "list". There are a TON of developers who have been on this list for 10 years or more. As such we do tend to get a little more personal than some other lists. We are friends as well as developers. We have people assigned to police the list should things get too out of hand and we mostly leave it up to them to do the policing. But we do not run as tight a ship as you might be accustomed to on other lists and we like it that way. You are of course welcomed to the list, welcomed to contribute and hang out, but if you expect this list to be "just the facts ma'am", I can tell you up front you are in the wrong place. So welcome to the list and I hope you enjoy the community as much as you enjoy the immense knowledge base that our members bring to the list. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 1:01 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT Thank you, I would appreciate that. I also appreciate the many useful contributions thay you all put in. Max Ps. I have been subscribing to Peach List for some 9 maybe more years now, so I do understand how it works. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 5:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before > going totally insane, so we need at least one day a week to blow off > some steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Fri Jul 20 13:25:22 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 11:25:22 -0700 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: References: Message-ID: For you, Drew, the possibilities are out there. ;-> Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Friday, July 20, 2007 10:10 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT I wish I would have known this earlier...... is there hope of recovery if you've gone totally insane? ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:01 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Traditionally, Fridays are very relaxed days with lots of nonsense. Developers can only be serious for a limited period of time before going totally insane, so we need at least one day a week to blow off some steam. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Fri Jul 20 14:05:31 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 15:05:31 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> Message-ID: <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> John, I'm working a lot more with other Office products now than Access, so a list dedicated to Office might be nice, of course, specifying that Access traffic should remain on the AccessD list. Susan H. If anyone has a request for a new DBA list to discuss a specific subject please email me directly. Also, please leave this subject line in tact so I can sort these messages into a new email folder. From ssharkins at setel.com Fri Jul 20 14:05:30 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 15:05:30 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35><006501c7cacb$f129aa80$94b82ad1@SusanOne> <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> Message-ID: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> The first rule of database development is performance, above all other considerations. ======I strongly disagree -- the first rule is to ensure data integrity. Susan H. From listmaster at databaseadvisors.com Fri Jul 20 14:27:50 2007 From: listmaster at databaseadvisors.com (Bryan Carbonnell) Date: Fri, 20 Jul 2007 15:27:50 -0400 (EDT) Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <016901c7cafb$16d79e20$8119fea9@LTVM> References: <015901c7caef$810bb0d0$8119fea9@LTVM> <20070720173116.542ABBDDD@smtp-auth.no-ip.com> <016901c7cafb$16d79e20$8119fea9@LTVM> Message-ID: <39200.159.33.10.92.1184959670.squirrel@carbonnell.ca> OK Folks this thread is closed. Move along. Nothing else to see here. -- Bryan Carbonnell - listmaster at databaseadvisors.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From fuller.artful at gmail.com Fri Jul 20 14:30:43 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 15:30:43 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> Message-ID: <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> Now that I have a sudden interest in Excel, I strongly agree! On 7/20/07, Susan Harkins wrote: > > John, I'm working a lot more with other Office products now than Access, > so > a list dedicated to Office might be nice, of course, specifying that > Access > traffic should remain on the AccessD list. > > Susan H. > > If anyone has a request for a new DBA list to discuss a specific subject > please email me directly. > > Also, please leave this subject line in tact so I can sort these messages > into a new email folder. > > > -- > 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 Jul 20 14:32:20 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 15:32:20 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> <006501c7cacb$f129aa80$94b82ad1@SusanOne> <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> Message-ID: <29f585dd0707201232k2e4a9920v6f8812c225c27796@mail.gmail.com> You're quite right, as usual, Susan. The second rule of db dev is performance; the first is integrity. A. On 7/20/07, Susan Harkins wrote: > > The first rule of database development is performance, above all other > considerations. > > ======I strongly disagree -- the first rule is to ensure data integrity. > > Susan H. > > From jwcolby at colbyconsulting.com Fri Jul 20 14:38:35 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 15:38:35 -0400 Subject: [AccessD] OT: Deal of the Day In-Reply-To: <004801c7cae5$6b62d830$0301a8c0@HAL9005> Message-ID: <20070720193838.B2281BF3A@smtp-auth.no-ip.com> They bought it at auction for $10? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Friday, July 20, 2007 11:48 AM To: dba-ot at databaseadvisors.com; 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Deal of the Day Today at Fry's: GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... $149.00. How do they make any money on this? Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Fri Jul 20 14:39:36 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 15:39:36 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> Message-ID: <20070720193939.A9CB0BE8E@smtp-auth.no-ip.com> LOL, and I somewhat disagree. The first rule is to be useful and usable. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 20, 2007 3:06 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships The first rule of database development is performance, above all other considerations. ======I strongly disagree -- the first rule is to ensure data integrity. Susan H. -- 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 Jul 20 14:54:35 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Fri, 20 Jul 2007 14:54:35 -0500 Subject: [AccessD] One-to-One relationships Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CA8@xlivmbx35.aig.com> If it was performance above all we'd all be working with non-normalized flat databases. Joins cost time = reduce performance. But as we all know normalization is about having good data, not about getting at it as fast as possible. Just like Susan said. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 3:40 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships LOL, and I somewhat disagree. The first rule is to be useful and usable. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 20, 2007 3:06 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships The first rule of database development is performance, above all other considerations. ======I strongly disagree -- the first rule is to ensure data integrity. 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 martyconnelly at shaw.ca Fri Jul 20 15:36:33 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Fri, 20 Jul 2007 13:36:33 -0700 Subject: [AccessD] Math in VBA In-Reply-To: References: Message-ID: <46A11CD1.80705@shaw.ca> If you just need a random 16 byte string how about creating a GUID Private Type GUID Data1 As Long Data2 As Integer Data3 As Integer Data4(7) As Byte End Type Private Declare Function CoCreateGuid Lib "OLE32.DLL" _ (pGuid As GUID) As Long Private Declare Function StringFromGUID2 Lib "OLE32.DLL" (rguid As GUID, _ ByVal lpsz As String, cbMax As Long) As Long 'More GUID routines here ' http://www.trigeminal.com/code/guids.bas Sub testguid() Dim pudtGUID As GUID Dim pstrGUID As String Dim plngRet As Long pstrGUID = String(256, 0) Debug.Print CoCreateGuid(pudtGUID) plngRet = StringFromGUID2(pudtGUID, pstrGUID, Len(pstrGUID)) Debug.Print plngRet Debug.Print "GUID = " & Left(pstrGUID, plngRet) Debug.Print pstrGUID End Sub Mark A Matte wrote: >Thanks Everyone, > >I ended up using a loop to get my powers...before I was the power by 1 for >each record...now I added a new loop to get the actual number if you >calculated out to the nth power. I was in the quadrillions when I finished. > Thanks Again, > >Mark > > Power = Power - 1 > PowerNum = CDec(36) > For PNLoop = 1 To Power - 1 > PowerNum = CDec(PowerNum * CDec(36)) > Next > > > > >>From: "Gustav Brock" >>Reply-To: Access Developers discussion and problem >>solving >>To: >>Subject: Re: [AccessD] Math in VBA >>Date: Thu, 19 Jul 2007 21:25:42 +0200 >> >>Hi Mark >> >>Chris is right. You have to keep the _numeric_ expressions within that of a >>Long if you wish to maintain accuracy. >> >>Thus: >>? CDec(36 ^10) >> 3656158440062980 >>? CDec(36 ^ 5) * CDec(36 ^ 5) >> 3656158440062976 >> >>because CDec(36 ^ 5) = 60466176. >> >>/gustav >> >> >> >>>>>cjeris at fas.harvard.edu 19-07-2007 20:37 >>> >>>>> >>>>> >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Mark A Matte wrote: >> >> >>>ttt = CDec(36 * 36 * 36) >>> >>> >>6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up >>and kick someone in the head for leaving a 16-bit signed integer type in >>a program written after 1995. >> >>Try >>ttt = CDec(36) * CDec(36) * CDec(36) >> >>Also, be careful! >> >> >>>tt = CDec(36 ^ 10) >>> >>> >>That ^ is the _floating_point_ exponentiation operator! The result is >>not the integer 6^20; if you look at tt, you will see that it ends in a >>0, which no power of 6 does. What you get there is the decimal >>conversion of the floating-point exponentiation. >> >>peace, Chris Jeris >> >> -- Marty Connelly Victoria, B.C. Canada From jmhecht at earthlink.net Fri Jul 20 16:00:06 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Fri, 20 Jul 2007 14:00:06 -0700 (GMT-07:00) Subject: [AccessD] OT: Deal of the Day Message-ID: <20503120.1184965206799.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> worst of both worlds -----Original Message----- >From: Jim Hewson >Sent: Jul 20, 2007 9:53 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] OT: Deal of the Day > >We have CompUSA but NO Fry's. > >Jim >jhewson at karta.com > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe Hecht >Sent: Friday, July 20, 2007 11:45 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] OT: Deal of the Day > >cause CompUSA aint around no more ? > >Joe > >Ex compUSA employee > >-----Original Message----- >>From: Rocky Smolin at Beach Access Software >>Sent: Jul 20, 2007 8:48 AM >>To: dba-ot at databaseadvisors.com, 'Access Developers discussion and problem solving' >>Subject: [AccessD] OT: Deal of the Day >> >>Today at Fry's: >> >>GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB >>RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... >> >> >>$149.00. >> >> >>How do they make any money on this? >> >> >>Rocky >> >> >> >> >> >> >>-- >>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 john at winhaven.net Fri Jul 20 16:01:02 2007 From: john at winhaven.net (John Bartow) Date: Fri, 20 Jul 2007 16:01:02 -0500 Subject: [AccessD] version of Access BE issues Message-ID: <024201c7cb11$15da0240$6402a8c0@ScuzzPaq> Has any one had any problems with using an A2k3 FE with A97 BE and then upgrading the BE to A2k3 but not changing the FE? From markamatte at hotmail.com Fri Jul 20 16:13:54 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 20 Jul 2007 21:13:54 +0000 Subject: [AccessD] Math in VBA In-Reply-To: <46A11CD1.80705@shaw.ca> Message-ID: Actually this wasn't about creating a random number...I using some 'big' math to encrypt and decrypt credit card numbers. It worked perfectly. Thanks for all of the help. Mark A. Matte >From: MartyConnelly >Reply-To: Access Developers discussion and problem >solving >To: Access Developers discussion and problem >solving >Subject: Re: [AccessD] Math in VBA >Date: Fri, 20 Jul 2007 13:36:33 -0700 > >If you just need a random 16 byte string how about creating a GUID > >Private Type GUID > Data1 As Long > Data2 As Integer > Data3 As Integer > Data4(7) As Byte >End Type > >Private Declare Function CoCreateGuid Lib "OLE32.DLL" _ > (pGuid As GUID) As Long >Private Declare Function StringFromGUID2 Lib "OLE32.DLL" (rguid As GUID, _ >ByVal lpsz As String, cbMax As Long) As Long > >'More GUID routines here >' http://www.trigeminal.com/code/guids.bas > >Sub testguid() > > Dim pudtGUID As GUID > Dim pstrGUID As String > Dim plngRet As Long > > pstrGUID = String(256, 0) > > Debug.Print CoCreateGuid(pudtGUID) > > plngRet = StringFromGUID2(pudtGUID, pstrGUID, Len(pstrGUID)) > Debug.Print plngRet > Debug.Print "GUID = " & Left(pstrGUID, plngRet) > Debug.Print pstrGUID > >End Sub > >Mark A Matte wrote: > > >Thanks Everyone, > > > >I ended up using a loop to get my powers...before I was the power by 1 >for > >each record...now I added a new loop to get the actual number if you > >calculated out to the nth power. I was in the quadrillions when I >finished. > > Thanks Again, > > > >Mark > > > > Power = Power - 1 > > PowerNum = CDec(36) > > For PNLoop = 1 To Power - 1 > > PowerNum = CDec(PowerNum * CDec(36)) > > Next > > > > > > > > > >>From: "Gustav Brock" > >>Reply-To: Access Developers discussion and problem > >>solving > >>To: > >>Subject: Re: [AccessD] Math in VBA > >>Date: Thu, 19 Jul 2007 21:25:42 +0200 > >> > >>Hi Mark > >> > >>Chris is right. You have to keep the _numeric_ expressions within that >of a > >>Long if you wish to maintain accuracy. > >> > >>Thus: > >>? CDec(36 ^10) > >> 3656158440062980 > >>? CDec(36 ^ 5) * CDec(36 ^ 5) > >> 3656158440062976 > >> > >>because CDec(36 ^ 5) = 60466176. > >> > >>/gustav > >> > >> > >> > >>>>>cjeris at fas.harvard.edu 19-07-2007 20:37 >>> > >>>>> > >>>>> > >>-----BEGIN PGP SIGNED MESSAGE----- > >>Hash: SHA1 > >> > >>Mark A Matte wrote: > >> > >> > >>>ttt = CDec(36 * 36 * 36) > >>> > >>> > >>6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up > >>and kick someone in the head for leaving a 16-bit signed integer type in > >>a program written after 1995. > >> > >>Try > >>ttt = CDec(36) * CDec(36) * CDec(36) > >> > >>Also, be careful! > >> > >> > >>>tt = CDec(36 ^ 10) > >>> > >>> > >>That ^ is the _floating_point_ exponentiation operator! The result is > >>not the integer 6^20; if you look at tt, you will see that it ends in a > >>0, which no power of 6 does. What you get there is the decimal > >>conversion of the floating-point exponentiation. > >> > >>peace, Chris Jeris > >> > >> > >-- >Marty Connelly >Victoria, B.C. >Canada > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 From ssharkins at setel.com Fri Jul 20 16:54:35 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 17:54:35 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707201232k2e4a9920v6f8812c225c27796@mail.gmail.com> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35><006501c7cacb$f129aa80$94b82ad1@SusanOne><29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com><00be01c7cb00$f1f6f280$94b82ad1@SusanOne> <29f585dd0707201232k2e4a9920v6f8812c225c27796@mail.gmail.com> Message-ID: <00e601c7cb18$907e04e0$94b82ad1@SusanOne> See JC???? ;) Now, I do agree that performance is important -- and I'd never force a rule simply for the sake of the rule and I'm perfectly Okay with denormalization for the sake of performance. Susan H. You're quite right, as usual, Susan. The second rule of db dev is performance; the first is integrity. From ssharkins at setel.com Fri Jul 20 16:54:35 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 17:54:35 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720193939.A9CB0BE8E@smtp-auth.no-ip.com> References: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> <20070720193939.A9CB0BE8E@smtp-auth.no-ip.com> Message-ID: <00e701c7cb18$91f6c230$94b82ad1@SusanOne> I'd say that functionality and performance are right up there, but if the integrity's weak, nothing else matters. Susan H. LOL, and I somewhat disagree. The first rule is to be useful and usable. The first rule of database development is performance, above all other considerations. ======I strongly disagree -- the first rule is to ensure data integrity. From ssharkins at setel.com Fri Jul 20 16:54:35 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 17:54:35 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq><00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> Message-ID: <00e801c7cb18$9395a520$94b82ad1@SusanOne> Well, with enough interest, I suppose we could consider a dedicated list for the other larger apps, Word, Excel, and Outlook, and one more for the minor products? But, I don't see anything wrong with lumping them altogether -- if one app seems to become a focus, we could go with a dedicated list later. Susan H. Now that I have a sudden interest in Excel, I strongly agree! From fuller.artful at gmail.com Fri Jul 20 17:26:07 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 18:26:07 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <00e701c7cb18$91f6c230$94b82ad1@SusanOne> References: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> <20070720193939.A9CB0BE8E@smtp-auth.no-ip.com> <00e701c7cb18$91f6c230$94b82ad1@SusanOne> Message-ID: <29f585dd0707201526x48192d10lc8b36381818921f0@mail.gmail.com> Usefulness is in the mind of the beholder, not the design of the database. Usefulness is a front-end problem. I realize that many of us here do both jobs, but IMO they ought to be clearly distinguished. On the on hand you have the database and its design; on the other distant planet you have the user interface and its design. A. On 7/20/07, Susan Harkins wrote: > > I'd say that functionality and performance are right up there, but if the > integrity's weak, nothing else matters. > > Susan H. > > LOL, and I somewhat disagree. The first rule is to be useful and usable. > > > The first rule of database development is performance, above all other > considerations. > From ssharkins at setel.com Fri Jul 20 17:45:34 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 18:45:34 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707201526x48192d10lc8b36381818921f0@mail.gmail.com> References: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne><20070720193939.A9CB0BE8E@smtp-auth.no-ip.com><00e701c7cb18$91f6c230$94b82ad1@SusanOne> <29f585dd0707201526x48192d10lc8b36381818921f0@mail.gmail.com> Message-ID: <010801c7cb1f$c9c39010$94b82ad1@SusanOne> A clever developer can deliver both in Access. ;) Susan H. Usefulness is in the mind of the beholder, not the design of the database. Usefulness is a front-end problem. I realize that many of us here do both jobs, but IMO they ought to be clearly distinguished. On the on hand you have the database and its design; on the other distant planet you have the user interface and its design. From kathryn at bassett.net Fri Jul 20 20:22:23 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Fri, 20 Jul 2007 18:22:23 -0700 Subject: [AccessD] Many2Many try #2 In-Reply-To: <008301c7c8b9$ee78d630$6401a8c0@Kathryn> Message-ID: <009601c7cb35$97f66100$6401a8c0@Kathryn> Maybe the first time there was TMI because I only got one answer suggesting subforms. However, the ultimate goal is to duplicate this in MySql as the server in question doesn't do Access. I'm trying to understand the simplest approach in Access so that I'll be able to do the tranlation to MySql. In understanding my problem, I'm now thinking of these equivalents: tblCSnames = various people tblCScollections = various organizations A person can belong to many organizations. An organization can have many people. Here are the three tables so far. tblCScollections tblCScollectionID int(7) autoincrement, primary key tblCScollectionName varchar(50) populated with 11 collections for testing. tblCSnames tblCSnamesID int(7) autoincrement, primary key tblCSnameslastname varchar(50) tblCSnamesfirstname varchar(50) tblCSnamesMemo text populated with 5 members for testing tblCSjoin tblCSjoinIDcollection foreign key to tblCScollectionID tblCSjoinIDnames foreign key to tblCSnamesID There will only be one John Doe, one Jane Smith, etc, IOW one of each name, and the memo will take case of any explanations needed (and the memo may be empty if no explanation is needed). Don't worry about why, just accept that as fact. That means that all John Does will be tblCSnamesID=1 so I don't need any other fields to define John Doe. Q1) In tblCSjoin do I need tblCSjoinID int(7) autoincrement, primary key - - ? Q2) I will have provided to me a paper list of names that belong to a collection. So I need to make some sort of update query for collectionABC and add all the people who belong to that collection. If the name of a person already exists, then the query needs to figure that out, and update that person's list of collections. A dropdown list of names is not the answer because the list of names populating such a dropdown list would become unwieldly very fast. So the question is what would the sql be for the update query? Q3) One name complication is that it's possible to had a lastname Doe with an empty firstname, so in figuring out if the person already exists, it will have to look for (empty) Doe, John Doe, and Jane Doe. (Does empty always mean null?). Q3) isn't really a question, other than my parenthetical one. -- Kathryn Rhinehart Bassett (Pasadena CA) "Genealogy is my bag" "GH is my soap" kathryn at bassett.net http://bassett.net No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19 Jul 07 6:10 pm From martyconnelly at shaw.ca Sat Jul 21 14:37:26 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Sat, 21 Jul 2007 12:37:26 -0700 Subject: [AccessD] Info: Microsoft Office Access 2007 Runtime download is back again In-Reply-To: <00e801c7cb18$9395a520$94b82ad1@SusanOne> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> <00e801c7cb18$9395a520$94b82ad1@SusanOne> Message-ID: <46A26076.5060601@shaw.ca> The Microsoft Office Access 2007 Runtime enables you to distribute Access 2007 applications to users who do not have the full version of Access 2007 installed on their computers. There is a known bug where some reports don't work in ADPs. A fix missed the build so maybe MS will post a hotfix soon. http://www.microsoft.com/downloads/details.aspx?FamilyId=D9AE78D9-9DC6-4B38-9FA6-2C745A175AED&displaylang=en -- Marty Connelly Victoria, B.C. Canada From shamil at users.mns.ru Sun Jul 22 02:11:32 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Sun, 22 Jul 2007 11:11:32 +0400 Subject: [AccessD] Does MSA2007 behaves well if on a machine with MSA 1997 and MSA 2000 and MSA2003? Message-ID: <000c01c7cc2f$888fc080$6401a8c0@nant> Hi All, Do you know if MSA2007 behaves well if on a machine with MSA 1997 and MSA 2000 and MSA2003 on it? (Of course all the mentioned above MS Access versions will be installed into different folders and in chronological order of their release dates). Thank you. -- Shamil "To live without stress and pressure, to live without shaky ground feeling - our tough times is so far away from everybody?s leisure, as happening a sex between Bluegill and Penguin." IG/SS - 22/07/2007 From miscellany at mvps.org Sun Jul 22 03:43:17 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sun, 22 Jul 2007 20:43:17 +1200 Subject: [AccessD] Does MSA2007 behaves well if on a machine with MSA 1997 and MSA 2000 and MSA2003? In-Reply-To: <000c01c7cc2f$888fc080$6401a8c0@nant> References: <000c01c7cc2f$888fc080$6401a8c0@nant> Message-ID: <46A318A5.7080300@mvps.org> Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and MSA > 2000 and MSA2003 on it? (Of course all the mentioned above MS Access > versions will be installed into different folders and in chronological order > of their release dates). From shamil at users.mns.ru Sun Jul 22 04:03:07 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Sun, 22 Jul 2007 13:03:07 +0400 Subject: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? In-Reply-To: <46A318A5.7080300@mvps.org> Message-ID: <000801c7cc3f$1ec680c0$6401a8c0@nant> Hello Steve, Thank you for your answer! Besides this issue of switching between running (?) instances of different MS Access versions are there any problems with previous version of MS Access or MS Access 2007 getting somehow stuck when working together on the same system? BTW, can one run MS Access 97 program databases on MS Access 2007? (Sorry no time to test here currently and I do not have MS Access 97 installed to make a good test database to run it on MS Access 2007)... Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 22, 2007 12:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and MSA > 2000 and MSA2003 on it? (Of course all the mentioned above MS Access > versions will be installed into different folders and in chronological order > of their release dates). -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Sun Jul 22 07:49:23 2007 From: ssharkins at setel.com (Susan Harkins) Date: Sun, 22 Jul 2007 08:49:23 -0400 Subject: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997 and MSA 2000 and MSA2003? In-Reply-To: <000801c7cc3f$1ec680c0$6401a8c0@nant> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant> Message-ID: <003f01c7cc5e$cad77b20$75b82ad1@SusanOne> Shamil, I have 2002, 2003, and 2007 on the same system. Things are definitely slower and about 1/3 of the time, launching 2003 or 2007 drags the installer into the act. :( So, I have to wait on that. Also, 2007 has usurped some of my shortcuts, but that's no biggee. I've noticed twice now that my system hasn't wanted to respond to a hard boot, so the above problem may be a symptom of my hd going bad and have nothing to do with 2007 -- however, I'm not having any trouble with other software (although I seldom use anything but Office). System is much slower over all though. I had planned to reformat and start over this month, but I've pushed that back to next month. I'm going to install VM so I can have a dedicated OS for 2007 -- I need both Outlook 2003 and 2007 to write about. I'm hoping that will take care of most of my performance problems. Susan H. Hello Steve, Thank you for your answer! Besides this issue of switching between running (?) instances of different MS Access versions are there any problems with previous version of MS Access or MS Access 2007 getting somehow stuck when working together on the same system? BTW, can one run MS Access 97 program databases on MS Access 2007? (Sorry no time to test here currently and I do not have MS Access 97 installed to make a good test database to run it on MS Access 2007)... Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 22, 2007 12:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and > MSA 2000 and MSA2003 on it? (Of course all the mentioned above MS > Access versions will be installed into different folders and in > chronological order > of their release dates). -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 2007/07/21 03:52 PM From robert at servicexp.com Sun Jul 22 12:47:40 2007 From: robert at servicexp.com (Robert) Date: Sun, 22 Jul 2007 13:47:40 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: <003f01c7cc5e$cad77b20$75b82ad1@SusanOne> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant> <003f01c7cc5e$cad77b20$75b82ad1@SusanOne> Message-ID: <002d01c7cc88$66e3eb60$0801a8c0@roberts> IIf(ServOption()=0,>1,ServOption()) This is the criteria in a query. ServOption is a function that returns a long. The query works when ServOption returns a specific option. However if ServOption returns 0, all the records are to be displayed, but doesn't WBR Robert From fuller.artful at gmail.com Sun Jul 22 13:07:06 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 22 Jul 2007 14:07:06 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: <002d01c7cc88$66e3eb60$0801a8c0@roberts> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant> <003f01c7cc5e$cad77b20$75b82ad1@SusanOne> <002d01c7cc88$66e3eb60$0801a8c0@roberts> Message-ID: <29f585dd0707221107n71e2a273pbe29381a0347b585@mail.gmail.com> Just a wag, but that query makes no sense to me. This could be the absence of information, of course, but what you wrote appears non-logical. Maybe you mis-typed, but given what you supplied and breaking it down, I end up with this: IIf( ServOption()=0, >1, ServOption() ) Perhaps that was one accidental keystroke (the ">") -- that's the part that makes no sense IMO. If ServOption() is a static function, then something like this might possibly work: (Assume ServOption() currently returns either zero or three, just to choose some value) SELECT * FROM mytables WHERE ServeOption() = 0 OR = ServeOption() Only one of these ORs can exist so I think that covers the bases. I could be more specific if I knew exactly what criteria ServeOption() was testing, but that's the general idea. hth, Arthur On 7/22/07, Robert wrote: > > > IIf(ServOption()=0,>1,ServOption()) > > This is the criteria in a query. > > ServOption is a function that returns a long. The query works when > ServOption returns a specific option. However if ServOption returns 0, all > the records are to be displayed, but doesn't > > > > > WBR > Robert > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From carbonnb at gmail.com Sun Jul 22 13:24:07 2007 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Sun, 22 Jul 2007 14:24:07 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <00e801c7cb18$9395a520$94b82ad1@SusanOne> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> <00e801c7cb18$9395a520$94b82ad1@SusanOne> Message-ID: On 7/20/07, Susan Harkins wrote: > Well, with enough interest, I suppose we could consider a dedicated list for > the other larger apps, Word, Excel, and Outlook, and one more for the minor > products? But, I don't see anything wrong with lumping them altogether -- if > one app seems to become a focus, we could go with a dedicated list later. That's one of the things that dba-tech is for. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From robert at servicexp.com Sun Jul 22 13:27:13 2007 From: robert at servicexp.com (Robert) Date: Sun, 22 Jul 2007 14:27:13 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: <29f585dd0707221107n71e2a273pbe29381a0347b585@mail.gmail.com> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant><003f01c7cc5e$cad77b20$75b82ad1@SusanOne><002d01c7cc88$66e3eb60$0801a8c0@roberts> <29f585dd0707221107n71e2a273pbe29381a0347b585@mail.gmail.com> Message-ID: <003401c7cc8d$ed3be910$0801a8c0@roberts> Arthur, Ok let me try and clear some things up... :-) IIf(ServOption()=0,>1,ServOption()) is in the criteria area of the saved query it's in. The query is a simple select query that returns records of past services. "ServOption()" returns the type of service rendered, (a long value, representing of the type of service and it's value can be from 2 to whatever.) which the user selected on a form. There is an option to show all service types or a selected type. The selected type works perfectly, but when I need to display all (i.e. >1) the query displays no records. If I hard code >1 it works fine, showing all records... The service type field in the query is numeric.. Clear as mud eh... :-) WBR Robert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 22, 2007 2:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Why doesn't this work? Just a wag, but that query makes no sense to me. This could be the absence of information, of course, but what you wrote appears non-logical. Maybe you mis-typed, but given what you supplied and breaking it down, I end up with this: IIf( ServOption()=0, >1, ServOption() ) Perhaps that was one accidental keystroke (the ">") -- that's the part that makes no sense IMO. If ServOption() is a static function, then something like this might possibly work: (Assume ServOption() currently returns either zero or three, just to choose some value) SELECT * FROM mytables WHERE ServeOption() = 0 OR = ServeOption() Only one of these ORs can exist so I think that covers the bases. I could be more specific if I knew exactly what criteria ServeOption() was testing, but that's the general idea. hth, Arthur On 7/22/07, Robert wrote: > > > IIf(ServOption()=0,>1,ServOption()) > > This is the criteria in a query. > > ServOption is a function that returns a long. The query works when > ServOption returns a specific option. However if ServOption returns 0, > all the records are to be displayed, but doesn't > > > > > WBR > Robert > > > -- > 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 DWUTKA at Marlow.com Sun Jul 22 13:43:57 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Sun, 22 Jul 2007 13:43:57 -0500 Subject: [AccessD] Why doesn't this work? In-Reply-To: <003401c7cc8d$ed3be910$0801a8c0@roberts> Message-ID: The problem is that IIF returns a value, and >1 isn't a value. So when the statement is true, ServOption() is returning a value that is being used as a criteria. Ie, ServOption() returns 3 then the WHERE clause looks like this: WHERE YourField=3 When it returns 0, your getting WHERE YourField=">1" And nothing will fit that criteria. There's two ways you can fix this. One, change your query to this: SELECT Table1.SomeNumber FROM Table1 WHERE SomeNumber Like IIf(ServOption()=0,"*",ServOption()) The other option is to have ServOption actually check the field for you. The above solution is probably best if ServOption only returns one value, but if you want ServOption to return more then one value, the next option would work better. Change ServOption to accept the field as an argument, and have it return true or false: SELECT Table1.SomeNumber FROM Table1 WHERE ServOption([SomeNumber])=True Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert Sent: Sunday, July 22, 2007 1:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Why doesn't this work? Arthur, Ok let me try and clear some things up... :-) IIf(ServOption()=0,>1,ServOption()) is in the criteria area of the saved query it's in. The query is a simple select query that returns records of past services. "ServOption()" returns the type of service rendered, (a long value, representing of the type of service and it's value can be from 2 to whatever.) which the user selected on a form. There is an option to show all service types or a selected type. The selected type works perfectly, but when I need to display all (i.e. >1) the query displays no records. If I hard code >1 it works fine, showing all records... The service type field in the query is numeric.. Clear as mud eh... :-) WBR Robert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 22, 2007 2:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Why doesn't this work? Just a wag, but that query makes no sense to me. This could be the absence of information, of course, but what you wrote appears non-logical. Maybe you mis-typed, but given what you supplied and breaking it down, I end up with this: IIf( ServOption()=0, >1, ServOption() ) Perhaps that was one accidental keystroke (the ">") -- that's the part that makes no sense IMO. If ServOption() is a static function, then something like this might possibly work: (Assume ServOption() currently returns either zero or three, just to choose some value) SELECT * FROM mytables WHERE ServeOption() = 0 OR = ServeOption() Only one of these ORs can exist so I think that covers the bases. I could be more specific if I knew exactly what criteria ServeOption() was testing, but that's the general idea. hth, Arthur On 7/22/07, Robert wrote: > > > IIf(ServOption()=0,>1,ServOption()) > > This is the criteria in a query. > > ServOption is a function that returns a long. The query works when > ServOption returns a specific option. However if ServOption returns 0, > all the records are to be displayed, but doesn't > > > > > WBR > Robert > > > -- > 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From fuller.artful at gmail.com Sun Jul 22 13:49:25 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 22 Jul 2007 14:49:25 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: References: <003401c7cc8d$ed3be910$0801a8c0@roberts> Message-ID: <29f585dd0707221149l7b62dfb7o2d35458b7a5267@mail.gmail.com> Exactly what I was attempting to say, but you did it better, Drew. A. On 7/22/07, Drew Wutka wrote: > > The problem is that IIF returns a value, and >1 isn't a value. So when > the statement is true, ServOption() is returning a value that is being > used as a criteria. > > Ie, ServOption() returns 3 then the WHERE clause looks like this: > > WHERE YourField=3 > > When it returns 0, your getting > > WHERE YourField=">1" > > And nothing will fit that criteria. > > There's two ways you can fix this. One, change your query to this: > > SELECT Table1.SomeNumber > FROM Table1 > WHERE SomeNumber Like IIf(ServOption()=0,"*",ServOption()) > > The other option is to have ServOption actually check the field for you. > The above solution is probably best if ServOption only returns one > value, but if you want ServOption to return more then one value, the > next option would work better. Change ServOption to accept the field as > an argument, and have it return true or false: > > SELECT Table1.SomeNumber > FROM Table1 > WHERE ServOption([SomeNumber])=True > > Drew > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert > Sent: Sunday, July 22, 2007 1:27 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Why doesn't this work? > > Arthur, > Ok let me try and clear some things up... :-) > > IIf(ServOption()=0,>1,ServOption()) is in the criteria area of the saved > query it's in. The query is a simple select query that returns records > of > past services. > > "ServOption()" returns the type of service rendered, (a long value, > representing of the type of service and it's value can be from 2 to > whatever.) which the user selected on a form. > > There is an option to show all service types or a selected type. The > selected type works perfectly, but when I need to display all (i.e. >1) > the > query displays no records. If I hard code >1 it works fine, showing all > records... > > > The service type field in the query is numeric.. > > > Clear as mud eh... :-) > > > WBR > Robert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Sunday, July 22, 2007 2:07 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Why doesn't this work? > > Just a wag, but that query makes no sense to me. This could be the > absence > of information, of course, but what you wrote appears non-logical. Maybe > you > mis-typed, but given what you supplied and breaking it down, I end up > with > this: > > IIf( > ServOption()=0, > >1, > ServOption() > ) > > Perhaps that was one accidental keystroke (the ">") -- that's the part > that > makes no sense IMO. > > If ServOption() is a static function, then something like this might > possibly work: > > (Assume ServOption() currently returns either zero or three, just to > choose > some value) > > SELECT * FROM mytables > WHERE ServeOption() = 0 > OR = ServeOption() > > Only one of these ORs can exist so I think that covers the bases. I > could be > more specific if I knew exactly what criteria ServeOption() was testing, > but > that's the general idea. > > hth, > Arthur > > On 7/22/07, Robert wrote: > > > > > > IIf(ServOption()=0,>1,ServOption()) > > > > This is the criteria in a query. > > > > ServOption is a function that returns a long. The query works when > > ServOption returns a specific option. However if ServOption returns 0, > > > all the records are to be displayed, but doesn't > > > > > > > > > > WBR > > Robert > > > > > > -- > > 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 > The information contained in this transmission is intended only for the > person or entity to which it is addressed and may contain II-VI Proprietary > and/or II-VI BusinessSensitve material. If you are not the intended > recipient, please contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. You are notified that any > review, retransmission, copying, disclosure, dissemination, or other use of, > or taking of any action in reliance upon this information by persons or > entities other than the intended recipient is prohibited. > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From robert at servicexp.com Sun Jul 22 14:44:24 2007 From: robert at servicexp.com (Robert) Date: Sun, 22 Jul 2007 15:44:24 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: References: <003401c7cc8d$ed3be910$0801a8c0@roberts> Message-ID: <003501c7cc98$b5bfa700$0801a8c0@roberts> Guys, Thanks a million for your help, Drew your suggestion worked perfectly.. WBR Robert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Sunday, July 22, 2007 2:44 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Why doesn't this work? The problem is that IIF returns a value, and >1 isn't a value. So when the statement is true, ServOption() is returning a value that is being used as a criteria. Ie, ServOption() returns 3 then the WHERE clause looks like this: WHERE YourField=3 When it returns 0, your getting WHERE YourField=">1" And nothing will fit that criteria. There's two ways you can fix this. One, change your query to this: SELECT Table1.SomeNumber FROM Table1 WHERE SomeNumber Like IIf(ServOption()=0,"*",ServOption()) The other option is to have ServOption actually check the field for you. The above solution is probably best if ServOption only returns one value, but if you want ServOption to return more then one value, the next option would work better. Change ServOption to accept the field as an argument, and have it return true or false: SELECT Table1.SomeNumber FROM Table1 WHERE ServOption([SomeNumber])=True Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert Sent: Sunday, July 22, 2007 1:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Why doesn't this work? Arthur, Ok let me try and clear some things up... :-) IIf(ServOption()=0,>1,ServOption()) is in the criteria area of the saved query it's in. The query is a simple select query that returns records of past services. "ServOption()" returns the type of service rendered, (a long value, representing of the type of service and it's value can be from 2 to whatever.) which the user selected on a form. There is an option to show all service types or a selected type. The selected type works perfectly, but when I need to display all (i.e. >1) the query displays no records. If I hard code >1 it works fine, showing all records... The service type field in the query is numeric.. Clear as mud eh... :-) WBR Robert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 22, 2007 2:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Why doesn't this work? Just a wag, but that query makes no sense to me. This could be the absence of information, of course, but what you wrote appears non-logical. Maybe you mis-typed, but given what you supplied and breaking it down, I end up with this: IIf( ServOption()=0, >1, ServOption() ) Perhaps that was one accidental keystroke (the ">") -- that's the part that makes no sense IMO. If ServOption() is a static function, then something like this might possibly work: (Assume ServOption() currently returns either zero or three, just to choose some value) SELECT * FROM mytables WHERE ServeOption() = 0 OR = ServeOption() Only one of these ORs can exist so I think that covers the bases. I could be more specific if I knew exactly what criteria ServeOption() was testing, but that's the general idea. hth, Arthur On 7/22/07, Robert wrote: > > > IIf(ServOption()=0,>1,ServOption()) > > This is the criteria in a query. > > ServOption is a function that returns a long. The query works when > ServOption returns a specific option. However if ServOption returns 0, > all the records are to be displayed, but doesn't > > > > > WBR > Robert > > > -- > 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Sun Jul 22 15:31:04 2007 From: ssharkins at setel.com (Susan Harkins) Date: Sun, 22 Jul 2007 16:31:04 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq><00bf01c7cb00$f3981f60$94b82ad1@SusanOne><29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com><00e801c7cb18$9395a520$94b82ad1@SusanOne> Message-ID: <003f01c7cc9f$3e462800$6eb62ad1@SusanOne> On 7/20/07, Susan Harkins wrote: > Well, with enough interest, I suppose we could consider a dedicated > list for the other larger apps, Word, Excel, and Outlook, and one more > for the minor products? But, I don't see anything wrong with lumping > them altogether -- if one app seems to become a focus, we could go with a dedicated list later. That's one of the things that dba-tech is for. ======Well, we could say dba-tech is for everything else then -- so why ask for new list ideas? I'm confused. Susan H. From bheid at sc.rr.com Sun Jul 22 18:57:04 2007 From: bheid at sc.rr.com (Bobby Heid) Date: Sun, 22 Jul 2007 19:57:04 -0400 Subject: [AccessD] Access 2007 Run time re-released... Message-ID: <000c01c7ccbc$014c3d00$03e4b700$@rr.com> Found it here: http://accessextra.blogspot.com/2007/07/access-2007-runtime-re-issued-access .html Direct links: Runtime http://www.microsoft.com/downloads/details.aspx?familyid=d9ae78d9-9dc6-4b38- 9fa6-2c745a175aed&displaylang=en&tm Developer extensions http://www.microsoft.com/downloads/details.aspx?FamilyId=D96A8358-ECE4-4BEE- A844-F81856DCEB67&displaylang=en Bobby From bheid at sc.rr.com Sun Jul 22 16:05:58 2007 From: bheid at sc.rr.com (Bobby Heid) Date: Sun, 22 Jul 2007 17:05:58 -0400 Subject: [AccessD] Info: Microsoft Office Access 2007 Runtime download is back again In-Reply-To: <46A26076.5060601@shaw.ca> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> <00e801c7cb18$9395a520$94b82ad1@SusanOne> <46A26076.5060601@shaw.ca> Message-ID: <001401c7cca4$1a216ed0$4e644c70$@rr.com> Now I see your message after I posted about the new runtime... Bobby -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly Sent: Saturday, July 21, 2007 3:37 PM To: Access Developers discussion and problem solving Subject: [AccessD] Info: Microsoft Office Access 2007 Runtime download is back again The Microsoft Office Access 2007 Runtime enables you to distribute Access 2007 applications to users who do not have the full version of Access 2007 installed on their computers. There is a known bug where some reports don't work in ADPs. A fix missed the build so maybe MS will post a hotfix soon. http://www.microsoft.com/downloads/details.aspx?FamilyId=D9AE78D9-9DC6-4B38- 9FA6-2C745A175AED&displaylang=en -- Marty Connelly Victoria, B.C. Canada From bheid at sc.rr.com Sun Jul 22 16:18:52 2007 From: bheid at sc.rr.com (Bobby Heid) Date: Sun, 22 Jul 2007 17:18:52 -0400 Subject: [AccessD] Require password for linked MDB tables In-Reply-To: References: <006801c7c988$f7c3fba0$e74bf2e0$@rr.com> Message-ID: <001501c7cca5$e773e1f0$b65ba5d0$@rr.com> Sorry for the delay in getting back to you, I'm in the middle of installing Vista on my system and do not have everything installed yet. I do not open databases that way, I use something like: Set dbDatabase = Workspaces(0).OpenDatabase(lstrEnterpriseDB, True, False, ";pwd=" & SECUREPW) Where in your case, SECUREPW would be the password that the user entered. I am sure that you could modify your version to include the ';pw=somepassword' functionality. Basically your connection string looks like this (for later versions (not sure of 2007) of Access: Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\My.mdb;Password=SomePassword; Hope this helps, Bobby -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Thursday, July 19, 2007 9:53 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Require password for linked MDB tables But if I use the following to try to link...I get the error (invalid Password): Set tdf = dbs.CreateTableDef("Test") tdf.Connect = ";Database=C:\temp\test.mdb" tdf.SourceTableName = "tblPass" dbs.TableDefs.Append tdf >From: "Bobby Heid" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Require password for linked MDB tables >Date: Wed, 18 Jul 2007 18:14:10 -0400 > >I guess if you asked the user for the password before linking the table, >then it might work. You would have it unlink it after using it. > >Bobby > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Tuesday, July 17, 2007 3:49 PM >To: accessd at databaseadvisors.com >Subject: [AccessD] Require password for linked MDB tables > >Hello All, > >Can I have an MDB linked to a seperate MDB(with password)...and have the >user required to enter just a password to view the linked table each time? > >And is it different in different versions? > >Thanks, > >Mark A. Matte > From carbonnb at gmail.com Sun Jul 22 16:50:07 2007 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Sun, 22 Jul 2007 17:50:07 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <003f01c7cc9f$3e462800$6eb62ad1@SusanOne> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> <00e801c7cb18$9395a520$94b82ad1@SusanOne> <003f01c7cc9f$3e462800$6eb62ad1@SusanOne> Message-ID: On 7/22/07, Susan Harkins wrote: > ======Well, we could say dba-tech is for everything else then -- so why ask > for new list ideas? I'm confused. I was just pointing you to a place for your questions. If there is a "critical mass" for a new list then I'm sure John will discuss it with all involved to make it happen. But yea, tech is for anything that doesn't have it's own list at the moment. Just like OT is for all Off Topic discussions. I think Johns e-mail was in response to a post asking about and ASP or ASP.net list. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From kathryn at bassett.net Sun Jul 22 17:55:38 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Sun, 22 Jul 2007 15:55:38 -0700 Subject: [AccessD] Let me try this another way - please help me understand this? In-Reply-To: <009601c7cb35$97f66100$6401a8c0@Kathryn> Message-ID: <005d01c7ccb3$6c5e4c40$6401a8c0@Kathryn> Maybe a screen capture will get someone to help me. http://www.genealogylibrarycenter.com/images/manymanyrelationship.jpg First, the word foreign in the tblCSjoin bottom field name has been corrected, so ignore that. The word was intended to be in the description. Now, here's my problem. I've only ever done Many-One or One-Many, I've never done a Many-Many and don't know how to join the tables. I've tried some different combos and nothing will turn that One-To-Many into Many-To-Many. And I'm not clear on Enforcing and the Cascading either. A name can belong to many collections. A collection can have many names. There is never going to be two people of the same name. Don't be concerned with why not, just be assured I've got my reasons, and a solution. So, how do I drag the tblCSjoin's foreign key's to the primary keys in the other tables, and what all do I checkmark? I'll get to other question after this part is solved. -- Kathryn Rhinehart Bassett (Pasadena CA) "Genealogy is my bag" "GH is my soap" kathryn at bassett.net http://bassett.net No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 21 Jul 07 3:52 pm From miscellany at mvps.org Sun Jul 22 18:07:27 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 23 Jul 2007 11:07:27 +1200 Subject: [AccessD] Let me try this another way - please help me understand this? In-Reply-To: <005d01c7ccb3$6c5e4c40$6401a8c0@Kathryn> References: <005d01c7ccb3$6c5e4c40$6401a8c0@Kathryn> Message-ID: <46A3E32F.1090905@mvps.org> Kathryn, You may be interested to read this short article... http://accesstips.datamanagementsolutions.biz/many.htm If I correctly understand your example, it seems to me that there should be a one-to-many join between: tblCScollections.tblCScollectionID and tblCSjoin.tblCSjoinIDcollection ... and also a one-to-many relationship between: tblCSnames.tblCSnamesID and tblCSjoin.tblCSjoinIDnames Regards Steve Kathryn Bassett wrote: > Maybe a screen capture will get someone to help me. > http://www.genealogylibrarycenter.com/images/manymanyrelationship.jpg > > First, the word foreign in the tblCSjoin bottom field name has been corrected, so ignore that. The word was intended to be in the description. Now, here's my problem. I've only ever done Many-One or One-Many, I've never done a Many-Many and don't know how to join the tables. I've tried some different combos and nothing will turn that One-To-Many into Many-To-Many. And I'm not clear on Enforcing and the Cascading either. > > A name can belong to many collections. > A collection can have many names. > > There is never going to be two people of the same name. Don't be concerned with why not, just be assured I've got my reasons, and a solution. > > So, how do I drag the tblCSjoin's foreign key's to the primary keys in the other tables, and what all do I checkmark? > > I'll get to other question after this part is solved. > From rockysmolin at bchacc.com Sun Jul 22 18:11:05 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Sun, 22 Jul 2007 16:11:05 -0700 Subject: [AccessD] Remote Assistance Message-ID: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky From rockysmolin at bchacc.com Sun Jul 22 18:29:52 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Sun, 22 Jul 2007 16:29:52 -0700 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <003f01c7cc9f$3e462800$6eb62ad1@SusanOne> Message-ID: <002601c7ccb8$347cee80$0301a8c0@HAL9005> And don't we run into the problem of Automation - that is, I want to do something with Outlook in Access or push some data from Access into and Excel spreadsheet. Which list do I go to? And for others that monitor the list - in order to learn all the stuff that's talked about related to Access they'd have to go to multiple lists. My opinion: the traffic on AccessD isn't that heavy. I use the delete key on threads I'm not interested in. I think more and varied topics on AccessD rather than fragmenting the list into too many topics. IMHO. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Sunday, July 22, 2007 1:31 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Request for new DBA List to discuss specific subjects On 7/20/07, Susan Harkins wrote: > Well, with enough interest, I suppose we could consider a dedicated > list for the other larger apps, Word, Excel, and Outlook, and one more > for the minor products? But, I don't see anything wrong with lumping > them altogether -- if one app seems to become a focus, we could go > with a dedicated list later. That's one of the things that dba-tech is for. ======Well, we could say dba-tech is for everything else then -- so why ask for new list ideas? I'm confused. Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 7/21/2007 3:52 PM From kathryn at bassett.net Sun Jul 22 18:32:42 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Sun, 22 Jul 2007 16:32:42 -0700 Subject: [AccessD] Let me try this another way - please help me understand this? In-Reply-To: <46A3E32F.1090905@mvps.org> Message-ID: <006901c7ccb8$99dd1480$6401a8c0@Kathryn> Steve pointed out the error in my thinking - tho collections and names are many to many, collections to join are many to one - duh! And that link was a good one. Now the question remains of which things I check, but maybe that needs more info. Once I get this working in Access, I have to get it all fixed up in MySql as the server doesn't "do" Access. Kathryn > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > Steve Schapel > Sent: 22 Jul 2007 4:07 pm > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Let me try this another way - please > help me understand this? > > Kathryn, > > You may be interested to read this short article... > http://accesstips.datamanagementsolutions.biz/many.htm > > If I correctly understand your example, it seems to me that > there should be a one-to-many join between: > tblCScollections.tblCScollectionID and > tblCSjoin.tblCSjoinIDcollection ... and also a one-to-many > relationship between: > tblCSnames.tblCSnamesID and tblCSjoin.tblCSjoinIDnames > > Regards > Steve > > > Kathryn Bassett wrote: > > Maybe a screen capture will get someone to help me. > > > http://www.genealogylibrarycenter.com/images/manymanyrelationship.jpg > > > > First, the word foreign in the tblCSjoin bottom field name > has been corrected, so ignore that. The word was intended to > be in the description. Now, here's my problem. I've only ever > done Many-One or One-Many, I've never done a Many-Many and > don't know how to join the tables. I've tried some different > combos and nothing will turn that One-To-Many into > Many-To-Many. And I'm not clear on Enforcing and the Cascading either. > > > > A name can belong to many collections. > > A collection can have many names. > > > > There is never going to be two people of the same name. > Don't be concerned with why not, just be assured I've got my > reasons, and a solution. > > > > So, how do I drag the tblCSjoin's foreign key's to the > primary keys in the other tables, and what all do I checkmark? > > > > I'll get to other question after this part is solved. > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.12/910 - Release > Date: 21 Jul 07 3:52 pm > > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 21 Jul 07 3:52 pm From fuller.artful at gmail.com Sun Jul 22 20:50:02 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 22 Jul 2007 21:50:02 -0400 Subject: [AccessD] Let me try this another way - please help me understand this? In-Reply-To: <006901c7ccb8$99dd1480$6401a8c0@Kathryn> References: <46A3E32F.1090905@mvps.org> <006901c7ccb8$99dd1480$6401a8c0@Kathryn> Message-ID: <29f585dd0707221850n35093b31jf6dcef594b7c7da3@mail.gmail.com> A Many-to-Many is easily resolved, Kath. Given tables A and B with PKs APK and BPK then Create table A2B having (now here comes the controversy (enter JWC LOL)) either an autoNumber or alternatively a compound PK consisting of APK+BPK (both of which columns must be present and not null). In either setup, you're good to go. In the case of MySQL I would go with the compound PK on the associative table, rather than the autonum, but that's strictly because of the behaviour of MySQL rather than a recommendation that can be generalized to all implementations of SQL. A. On 7/22/07, Kathryn Bassett wrote: > > Steve pointed out the error in my thinking - tho collections and names are > many to many, collections to join are many to one - duh! And that link was a > good one. > > Now the question remains of which things I check, but maybe that needs > more info. Once I get this working in Access, I have to get it all fixed up > in MySql as the server doesn't "do" Access. > > Kathryn > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > > Steve Schapel > > Sent: 22 Jul 2007 4:07 pm > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] Let me try this another way - please > > help me understand this? > > > > Kathryn, > > > > You may be interested to read this short article... > > http://accesstips.datamanagementsolutions.biz/many.htm > > > > If I correctly understand your example, it seems to me that > > there should be a one-to-many join between: > > tblCScollections.tblCScollectionID and > > tblCSjoin.tblCSjoinIDcollection ... and also a one-to-many > > relationship between: > > tblCSnames.tblCSnamesID and tblCSjoin.tblCSjoinIDnames > > > > Regards > > Steve > > > > > > Kathryn Bassett wrote: > > > Maybe a screen capture will get someone to help me. > > > > > http://www.genealogylibrarycenter.com/images/manymanyrelationship.jpg > > > > > > First, the word foreign in the tblCSjoin bottom field name > > has been corrected, so ignore that. The word was intended to > > be in the description. Now, here's my problem. I've only ever > > done Many-One or One-Many, I've never done a Many-Many and > > don't know how to join the tables. I've tried some different > > combos and nothing will turn that One-To-Many into > > Many-To-Many. And I'm not clear on Enforcing and the Cascading either. > > > > > > A name can belong to many collections. > > > A collection can have many names. > > > > > > There is never going to be two people of the same name. > > Don't be concerned with why not, just be assured I've got my > > reasons, and a solution. > > > > > > So, how do I drag the tblCSjoin's foreign key's to the > > primary keys in the other tables, and what all do I checkmark? > > > > > > I'll get to other question after this part is solved. > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.12/910 - Release > > Date: 21 Jul 07 3:52 pm > > > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 21 Jul 07 > 3:52 pm > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From thewaddles at sbcglobal.net Sun Jul 22 21:48:50 2007 From: thewaddles at sbcglobal.net (Kevin Waddle) Date: Sun, 22 Jul 2007 19:48:50 -0700 Subject: [AccessD] OT: VB6 datarepeater control and checkboxes (Cross posted) Message-ID: <007301c7ccd4$05f73a90$6600a8c0@TheWaddles> I apologize for the OT post. I am trying to recreate an Access continuous form in a VB6 exe using the datarepeater control. I have created a ActiveX control containing a TextBox and a CheckBox. These are bound to an Access mdb file. I can display and update the textbox but cannot get anything to display properly on the checkboxes. The control will display the checkbox as true only when the record is active. Does anyone have an example using the datarepeater control with a checkbox or another avenue to create a continuous form in VB6? Thank you, Kevin Catscan: a hi-tech device for examining cats. From nd500_lo at charter.net Sun Jul 22 22:44:23 2007 From: nd500_lo at charter.net (Dian) Date: Sun, 22 Jul 2007 20:44:23 -0700 Subject: [AccessD] Remote Assistance In-Reply-To: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> References: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> Message-ID: <000001c7ccdb$c3053130$6400a8c0@dsunit1> I've done the Remote Assistance thing...and the other party CAN, if they know how, see everything and do anything on YOUR machine. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Sunday, July 22, 2007 4:11 PM To: 'Access Developers discussion and problem solving'; dba-ot at databaseadvisors.com; dba-tech-request at databaseadvisors.com Subject: [AccessD] Remote Assistance I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From nd500_lo at charter.net Sun Jul 22 22:45:57 2007 From: nd500_lo at charter.net (Dian) Date: Sun, 22 Jul 2007 20:45:57 -0700 Subject: [AccessD] Remote Assistance In-Reply-To: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> References: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> Message-ID: <000101c7ccdb$fab44210$6400a8c0@dsunit1> OK...whoever STARTS the connection can do that...not the receiver. The receiver loses total control of the machine...sorry...it's late here and I'm tired. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Sunday, July 22, 2007 4:11 PM To: 'Access Developers discussion and problem solving'; dba-ot at databaseadvisors.com; dba-tech-request at databaseadvisors.com Subject: [AccessD] Remote Assistance I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Mon Jul 23 09:45:06 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 23 Jul 2007 07:45:06 -0700 Subject: [AccessD] Remote Assistance In-Reply-To: <000101c7ccdb$fab44210$6400a8c0@dsunit1> Message-ID: <002101c7cd38$0f831520$0301a8c0@HAL9005> OK, I'm connected between two machines now. #2 sent the invitation to #1. #1 accepted and can see everything on #2 screen. But the box labeled "Connection Status" says Connected/Screen View Only. On #1 I can see what's on the screen of #2 but can't figure a way to change anything. DO you know how #1 can get control of #2? TIA Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian Sent: Sunday, July 22, 2007 8:46 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Remote Assistance OK...whoever STARTS the connection can do that...not the receiver. The receiver loses total control of the machine...sorry...it's late here and I'm tired. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Sunday, July 22, 2007 4:11 PM To: 'Access Developers discussion and problem solving'; dba-ot at databaseadvisors.com; dba-tech-request at databaseadvisors.com Subject: [AccessD] Remote Assistance I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.14/912 - Release Date: 7/22/2007 7:02 PM From DWUTKA at Marlow.com Mon Jul 23 10:09:52 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 23 Jul 2007 10:09:52 -0500 Subject: [AccessD] Remote Assistance In-Reply-To: <002101c7cd38$0f831520$0301a8c0@HAL9005> Message-ID: Not sure if you can do that with plain old remote desktop. I know how to take control when you have terminal services running (with a remote desktop interface), you have to go into the terminal services manager snapin, then you just right click on the connected user and select remote control. If you can't get this to work, you could try a web-ex session. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Monday, July 23, 2007 9:45 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Remote Assistance OK, I'm connected between two machines now. #2 sent the invitation to #1. #1 accepted and can see everything on #2 screen. But the box labeled "Connection Status" says Connected/Screen View Only. On #1 I can see what's on the screen of #2 but can't figure a way to change anything. DO you know how #1 can get control of #2? TIA Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian Sent: Sunday, July 22, 2007 8:46 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Remote Assistance OK...whoever STARTS the connection can do that...not the receiver. The receiver loses total control of the machine...sorry...it's late here and I'm tired. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Sunday, July 22, 2007 4:11 PM To: 'Access Developers discussion and problem solving'; dba-ot at databaseadvisors.com; dba-tech-request at databaseadvisors.com Subject: [AccessD] Remote Assistance I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.14/912 - Release Date: 7/22/2007 7:02 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From cfoust at infostatsystems.com Mon Jul 23 10:08:32 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 23 Jul 2007 08:08:32 -0700 Subject: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997 and MSA 2000 and MSA2003? In-Reply-To: <000801c7cc3f$1ec680c0$6401a8c0@nant> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant> Message-ID: Shamil, The other versions work all right, but the big pain is the installer running when you switch back to 2003 or 2007. The 2003 installer doesn't take overly long, but the 2007 installer takes a YEAR!! I've had some problems with some of my earlier dbs in 2007, depending on how creative I had been when I built them. Since I spend so little time in Access, now, I haven't really exercised it. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: Sunday, July 22, 2007 2:03 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997 and MSA 2000 and MSA2003? Hello Steve, Thank you for your answer! Besides this issue of switching between running (?) instances of different MS Access versions are there any problems with previous version of MS Access or MS Access 2007 getting somehow stuck when working together on the same system? BTW, can one run MS Access 97 program databases on MS Access 2007? (Sorry no time to test here currently and I do not have MS Access 97 installed to make a good test database to run it on MS Access 2007)... Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 22, 2007 12:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and > MSA 2000 and MSA2003 on it? (Of course all the mentioned above MS > Access versions will be installed into different folders and in > chronological order > of their release dates). -- 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 john at winhaven.net Mon Jul 23 10:58:06 2007 From: john at winhaven.net (John Bartow) Date: Mon, 23 Jul 2007 10:58:06 -0500 Subject: [AccessD] Remote Assistance In-Reply-To: <002101c7cd38$0f831520$0301a8c0@HAL9005> References: <000101c7ccdb$fab44210$6400a8c0@dsunit1> <002101c7cd38$0f831520$0301a8c0@HAL9005> Message-ID: <054c01c7cd42$43a15290$6402a8c0@ScuzzPaq> Rocky, Please take this off list or resume it on dba-tech. Anyone who likes to respond to questions like this please sub to dba-tech. John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com From cjeris at fas.harvard.edu Mon Jul 23 12:50:47 2007 From: cjeris at fas.harvard.edu (Christopher Jeris) Date: Mon, 23 Jul 2007 13:50:47 -0400 Subject: [AccessD] Can't call methods I've added to a form? Message-ID: <46A4EA77.3070307@fas.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to build a set of forms according to MVC principles, and I think there's something fundamental I don't understand about Access form objects. Everything here is unbound forms, in Access 2002 sp3. I need to have "forms" that serve the same application role but present different user interfaces according to context, so I build a Controller object that creates different Form (view) objects depending on the context. But the Controller needs to tell the view to update itself in certain ways, so I have a method in the form's class like Public Sub InitializeFromBuffer(buffer As DataModelObject) and then the controller's process for opening up the form goes something like Set Me.activeForm = OpenFormByContext(intendedFormClass As String, _ context As ContextInfo) If Not Me.activeForm Is Nothing Then ' it worked Set Me.activeForm.Controller = Me Me.activeForm.InitializeFromBuffer theBuffer ' FAILURE End If Now calling InitializeFromBuffer ... or any other public method I try to add to a Form object ... from outside that Form's own class ... results in an "Application-defined or object-defined error". Is it really not possible to add methods to a Form that get called from outside the Form -- or am I missing something obvious ? I suppose, since adding _properties_ seems to work okay, one kludgy workaround would be to give the Form a property that is its "view proxy object", which is a user-defined class where all the methods I want to add are located, and call methods through the view proxy object ... but I'd rather say what I mean. thanks, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpOp35ICCNV0oGWARAiGDAJ9DwZIZ+eo3V/MsLOxBaT2/Y5wzwACgmb4+ j5Xtsy7ZmlM6bOkXXzOS3QY= =rjCB -----END PGP SIGNATURE----- From jwcolby at colbyconsulting.com Mon Jul 23 13:18:24 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 23 Jul 2007 14:18:24 -0400 Subject: [AccessD] Can't call methods I've added to a form? In-Reply-To: <46A4EA77.3070307@fas.harvard.edu> Message-ID: <20070723181833.72D1AC15C@smtp-auth.no-ip.com> >Now calling InitializeFromBuffer ... or any other public method I try to add to a Form object ... from outside that Form's own class ... results in an "Application-defined or object-defined error". You don't say how you are calling the form's method. You have to specify the form object, then the method so... Forms("MyForm").InitializeFromBuffer SomeParam Alternatively: Dim frm as form set frm=forms("MyForm") frm.InitializeFromBuffer SomeParam Remember that a form's code is a class and you have to get a pointer to that class in order to call a method of the class. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher Jeris Sent: Monday, July 23, 2007 1:51 PM To: accessd at databaseadvisors.com Subject: [AccessD] Can't call methods I've added to a form? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to build a set of forms according to MVC principles, and I think there's something fundamental I don't understand about Access form objects. Everything here is unbound forms, in Access 2002 sp3. I need to have "forms" that serve the same application role but present different user interfaces according to context, so I build a Controller object that creates different Form (view) objects depending on the context. But the Controller needs to tell the view to update itself in certain ways, so I have a method in the form's class like Public Sub InitializeFromBuffer(buffer As DataModelObject) and then the controller's process for opening up the form goes something like Set Me.activeForm = OpenFormByContext(intendedFormClass As String, _ context As ContextInfo) If Not Me.activeForm Is Nothing Then ' it worked Set Me.activeForm.Controller = Me Me.activeForm.InitializeFromBuffer theBuffer ' FAILURE End If Now calling InitializeFromBuffer ... or any other public method I try to add to a Form object ... from outside that Form's own class ... results in an "Application-defined or object-defined error". Is it really not possible to add methods to a Form that get called from outside the Form -- or am I missing something obvious ? I suppose, since adding _properties_ seems to work okay, one kludgy workaround would be to give the Form a property that is its "view proxy object", which is a user-defined class where all the methods I want to add are located, and call methods through the view proxy object ... but I'd rather say what I mean. thanks, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpOp35ICCNV0oGWARAiGDAJ9DwZIZ+eo3V/MsLOxBaT2/Y5wzwACgmb4+ j5Xtsy7ZmlM6bOkXXzOS3QY= =rjCB -----END PGP SIGNATURE----- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From garykjos at gmail.com Mon Jul 23 13:21:15 2007 From: garykjos at gmail.com (Gary Kjos) Date: Mon, 23 Jul 2007 13:21:15 -0500 Subject: [AccessD] OT: VB6 datarepeater control and checkboxes (Cross posted) In-Reply-To: <007301c7ccd4$05f73a90$6600a8c0@TheWaddles> References: <007301c7ccd4$05f73a90$6600a8c0@TheWaddles> Message-ID: Hi Kevin; This question would be appropriate for our VB list. You can subscribe to that list here; http://databaseadvisors.com/mailman/listinfo/dba-vb Gary Kjos AccessD Moderator On 7/22/07, Kevin Waddle wrote: > I apologize for the OT post. > > I am trying to recreate an Access continuous form in a VB6 exe using the > datarepeater control. > > I have created a ActiveX control containing a TextBox and a CheckBox. > These are bound to an Access mdb file. > I can display and update the textbox but cannot get anything to display > properly on the checkboxes. > > The control will display the checkbox as true only when the record is > active. > > Does anyone have an example using the datarepeater control with a checkbox > or another avenue to create a continuous form in VB6? > > Thank you, > Kevin > > > > Catscan: a hi-tech device for examining cats. > > -- > 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 cjeris at fas.harvard.edu Mon Jul 23 13:39:19 2007 From: cjeris at fas.harvard.edu (Christopher Jeris) Date: Mon, 23 Jul 2007 14:39:19 -0400 Subject: [AccessD] Can't call methods I've added to a form? In-Reply-To: <20070723181833.72D1AC15C@smtp-auth.no-ip.com> References: <20070723181833.72D1AC15C@smtp-auth.no-ip.com> Message-ID: <46A4F5D7.8020006@fas.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jwcolby wrote: > You don't say how you are calling the form's method. You have to specify > the form object, then the method so... > > Forms("MyForm").InitializeFromBuffer SomeParam > > Alternatively: > > Dim frm as form > set frm=forms("MyForm") > frm.InitializeFromBuffer SomeParam > > Remember that a form's code is a class and you have to get a pointer to that > class in order to call a method of the class. I constructed a toy example based on your suggestion, and it seems like the actual problem was related to what you're describing: some things were declared Friend that should have been Public. Thanks for your input! peace, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpPXX5ICCNV0oGWARAoEpAJwOlQk6et82vflCKRlw4k/n1WxnjwCfZReN ixeEOhj3eGG7NxpHuqJqO8A= =poCW -----END PGP SIGNATURE----- From bheygood at abestsystems.com Mon Jul 23 14:21:37 2007 From: bheygood at abestsystems.com (Bob Heygood) Date: Mon, 23 Jul 2007 12:21:37 -0700 Subject: [AccessD] OT: Deal of the Day In-Reply-To: <004801c7cae5$6b62d830$0301a8c0@HAL9005> References: <004801c7cae5$6b62d830$0301a8c0@HAL9005> Message-ID: <008101c7cd5e$b09f0560$6401a8c0@speedy> I remember looking at that exact ad and seeing further down on the page Win Vista Something for $$$. How in the hell can they "give" the computer away soo cheap??? Or does Bill G "give" away his OS to some??? Bob Heygood -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Friday, July 20, 2007 8:48 AM To: dba-ot at databaseadvisors.com; 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Deal of the Day Today at Fry's: GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... $149.00. How do they make any money on this? Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Mon Jul 23 14:23:18 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 23 Jul 2007 15:23:18 -0400 Subject: [AccessD] Can't call methods I've added to a form? In-Reply-To: <46A4F5D7.8020006@fas.harvard.edu> Message-ID: <20070723192328.31C12BDB6@smtp-auth.no-ip.com> Glad I could help. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher Jeris Sent: Monday, July 23, 2007 2:39 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Can't call methods I've added to a form? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jwcolby wrote: > You don't say how you are calling the form's method. You have to > specify the form object, then the method so... > > Forms("MyForm").InitializeFromBuffer SomeParam > > Alternatively: > > Dim frm as form > set frm=forms("MyForm") > frm.InitializeFromBuffer SomeParam > > Remember that a form's code is a class and you have to get a pointer > to that class in order to call a method of the class. I constructed a toy example based on your suggestion, and it seems like the actual problem was related to what you're describing: some things were declared Friend that should have been Public. Thanks for your input! peace, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpPXX5ICCNV0oGWARAoEpAJwOlQk6et82vflCKRlw4k/n1WxnjwCfZReN ixeEOhj3eGG7NxpHuqJqO8A= =poCW -----END PGP SIGNATURE----- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From reuben at gfconsultants.com Mon Jul 23 14:35:56 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Mon, 23 Jul 2007 15:35:56 -0400 Subject: [AccessD] check for file in ftp site Message-ID: I am wanting to log into an ftp site, look thru all the txt files (only txt files), and download all files that are new since the last check. The files are all numbered sequentially so I can parse out the numbers to determine what files are new. However, I could use some assistance in looping thru the txt file names. Thanks. Reuben Cummings GFC, LLC 812.523.1017 From shamil at users.mns.ru Mon Jul 23 14:57:01 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Mon, 23 Jul 2007 23:57:01 +0400 Subject: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997and MSA 2000 and MSA2003? In-Reply-To: Message-ID: <001001c7cd63$a3691de0$6401a8c0@nant> Thank you Charlotte! - I'd avoid having MS Access 2003 and 2007 on the same PC.... -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 23, 2007 7:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997and MSA 2000 and MSA2003? Shamil, The other versions work all right, but the big pain is the installer running when you switch back to 2003 or 2007. The 2003 installer doesn't take overly long, but the 2007 installer takes a YEAR!! I've had some problems with some of my earlier dbs in 2007, depending on how creative I had been when I built them. Since I spend so little time in Access, now, I haven't really exercised it. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: Sunday, July 22, 2007 2:03 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997 and MSA 2000 and MSA2003? Hello Steve, Thank you for your answer! Besides this issue of switching between running (?) instances of different MS Access versions are there any problems with previous version of MS Access or MS Access 2007 getting somehow stuck when working together on the same system? BTW, can one run MS Access 97 program databases on MS Access 2007? (Sorry no time to test here currently and I do not have MS Access 97 installed to make a good test database to run it on MS Access 2007)... Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 22, 2007 12:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and > MSA 2000 and MSA2003 on it? (Of course all the mentioned above MS > Access versions will be installed into different folders and in > chronological order > of their release dates). -- 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 markamatte at hotmail.com Mon Jul 23 15:25:01 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Mon, 23 Jul 2007 20:25:01 +0000 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: Sending You a zip file offline. >From: "Reuben Cummings" >Reply-To: Access Developers discussion and problem >solving >To: "AccessD" >Subject: [AccessD] check for file in ftp site >Date: Mon, 23 Jul 2007 15:35:56 -0400 > >I am wanting to log into an ftp site, look thru all the txt files (only txt >files), and download all files that are new since the last check. > >The files are all numbered sequentially so I can parse out the numbers to >determine what files are new. > >However, I could use some assistance in looping thru the txt file names. > >Thanks. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://newlivehotmail.com From darrend at nimble.com.au Mon Jul 23 20:31:58 2007 From: darrend at nimble.com.au (Darren D) Date: Tue, 24 Jul 2007 11:31:58 +1000 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: <200707240131.l6O1Vw7E007197@databaseadvisors.com> Hi Mark Would love to see a copy as well - thanks DD -----Original Message----- From: Mark A Matte [mailto:markamatte at hotmail.com] Sent: Tuesday, 24 July 2007 6:25 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] check for file in ftp site Sending You a zip file offline. >From: "Reuben Cummings" >Reply-To: Access Developers discussion and problem >solving >To: "AccessD" >Subject: [AccessD] check for file in ftp site >Date: Mon, 23 Jul 2007 15:35:56 -0400 > >I am wanting to log into an ftp site, look thru all the txt files (only txt >files), and download all files that are new since the last check. > >The files are all numbered sequentially so I can parse out the numbers to >determine what files are new. > >However, I could use some assistance in looping thru the txt file names. > >Thanks. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://newlivehotmail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From thewaddles at sbcglobal.net Mon Jul 23 20:55:23 2007 From: thewaddles at sbcglobal.net (Kevin Waddle) Date: Mon, 23 Jul 2007 18:55:23 -0700 Subject: [AccessD] OT: VB6 datarepeater control and checkboxes (Crossposted) In-Reply-To: References: <007301c7ccd4$05f73a90$6600a8c0@TheWaddles> Message-ID: <000501c7cd95$b3ab7d10$6600a8c0@TheWaddles> Garry, Thank you. I'll post the question there as soon as my registration is confirmed. Thanks, Kevin c'est la guere -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gary Kjos Sent: Monday, July 23, 2007 11:21 AM To: Access Developers discussion and problem solving Cc: ACCESS-L at peach.ease.lsoft.com Subject: Re: [AccessD] OT: VB6 datarepeater control and checkboxes (Crossposted) Hi Kevin; This question would be appropriate for our VB list. You can subscribe to that list here; http://databaseadvisors.com/mailman/listinfo/dba-vb Gary Kjos AccessD Moderator On 7/22/07, Kevin Waddle wrote: > I apologize for the OT post. > > I am trying to recreate an Access continuous form in a VB6 exe using > the datarepeater control. > > I have created a ActiveX control containing a TextBox and a CheckBox. > These are bound to an Access mdb file. > I can display and update the textbox but cannot get anything to > display properly on the checkboxes. > > The control will display the checkbox as true only when the record is > active. > > Does anyone have an example using the datarepeater control with a > checkbox or another avenue to create a continuous form in VB6? > > Thank you, > Kevin > > > > Catscan: a hi-tech device for examining cats. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- Gary Kjos garykjos at gmail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From reuben at gfconsultants.com Tue Jul 24 09:31:07 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Tue, 24 Jul 2007 10:31:07 -0400 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: Thanks, Mark. Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte > Sent: Monday, July 23, 2007 4:25 PM > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] check for file in ftp site > > > Sending You a zip file offline. > > > >From: "Reuben Cummings" > >Reply-To: Access Developers discussion and problem > >solving > >To: "AccessD" > >Subject: [AccessD] check for file in ftp site > >Date: Mon, 23 Jul 2007 15:35:56 -0400 > > > >I am wanting to log into an ftp site, look thru all the txt > files (only txt > >files), and download all files that are new since the last check. > > > >The files are all numbered sequentially so I can parse out the numbers to > >determine what files are new. > > > >However, I could use some assistance in looping thru the txt file names. > > > >Thanks. > > > >Reuben Cummings > >GFC, LLC > >812.523.1017 > > > > > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.com > > _________________________________________________________________ > http://newlivehotmail.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From doug at starntech.com Tue Jul 24 09:49:10 2007 From: doug at starntech.com (Doug Barnes) Date: Tue, 24 Jul 2007 10:49:10 -0400 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: Would love to see a copy, as well Douglas Barnes Starn Technical Services P.O. Box 1172 15957 Conneaut Lake Road, Suite 7 Meadville, PA 16335 doug at starntech.com P: 814.724.1045 F: 814.337.3460 -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte Sent: Monday, July 23, 2007 4:25 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] check for file in ftp site Sending You a zip file offline. >From: "Reuben Cummings" >Reply-To: Access Developers discussion and problem >solving >To: "AccessD" >Subject: [AccessD] check for file in ftp site >Date: Mon, 23 Jul 2007 15:35:56 -0400 > >I am wanting to log into an ftp site, look thru all the txt files (only txt >files), and download all files that are new since the last check. > >The files are all numbered sequentially so I can parse out the numbers to >determine what files are new. > >However, I could use some assistance in looping thru the txt file names. > >Thanks. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://newlivehotmail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From JHewson at karta.com Tue Jul 24 09:55:26 2007 From: JHewson at karta.com (Jim Hewson) Date: Tue, 24 Jul 2007 09:55:26 -0500 Subject: [AccessD] Primary Key Best Practices Message-ID: I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. From jwcolby at colbyconsulting.com Tue Jul 24 10:04:50 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 24 Jul 2007 11:04:50 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070724150501.001B0BD13@smtp-auth.no-ip.com> LOL, here we go again. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue Jul 24 10:09:58 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 24 Jul 2007 08:09:58 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: There are good arguments for 1. is you're using SQL Server, since you can't update those tables from the FE unless they have a PK. 4. seems to be a justification for 2. rather than a real rule of thumb. An autonumber, etc., will always uniquely identify a row, but if you have to create a unique key on that table anyhow using several fields, that gives you TWO unique keys on the same row, which can be argued about endlessly (and has, here! LOL). 3. ignores the fact that junction/join tables often or perhaps usually use the PKs from the tables being joined to uniquely identify the record and form a natural PK. Just my opinions, of course. ;> Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 7:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue Jul 24 10:10:25 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 24 Jul 2007 08:10:25 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070724150501.001B0BD13@smtp-auth.no-ip.com> References: <20070724150501.001B0BD13@smtp-auth.no-ip.com> Message-ID: Head for the storm cellar, quick!!! Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 8:05 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices LOL, here we go again. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim 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 JHewson at karta.com Tue Jul 24 10:24:23 2007 From: JHewson at karta.com (Jim Hewson) Date: Tue, 24 Jul 2007 10:24:23 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <20070724150501.001B0BD13@smtp-auth.no-ip.com> Message-ID: That's where I'm at now! And the rain is coming in! Jim jhewson at karta.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Tuesday, July 24, 2007 10:10 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Head for the storm cellar, quick!!! Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 8:05 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices LOL, here we go again. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim 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 markamatte at hotmail.com Tue Jul 24 10:25:16 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 24 Jul 2007 15:25:16 +0000 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: Hello All, I am more than happy to send almost anything to almost anyone...but as we are getting back into some of our Netiquette Practices...please send any other "Me Too"'s to me directly...to lessen the List traffic. Thanks, Mark A. Matte P.S...Doug, I sent you a copy already...good luck...its just an ugly scrapped together example. >From: "Doug Barnes" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] check for file in ftp site >Date: Tue, 24 Jul 2007 10:49:10 -0400 > >Would love to see a copy, as well > > >Douglas Barnes > >Starn Technical Services >P.O. Box 1172 >15957 Conneaut Lake Road, Suite 7 >Meadville, PA 16335 > >doug at starntech.com >P: 814.724.1045 >F: 814.337.3460 > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte >Sent: Monday, July 23, 2007 4:25 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] check for file in ftp site > > >Sending You a zip file offline. > > > >From: "Reuben Cummings" > >Reply-To: Access Developers discussion and problem > >solving > >To: "AccessD" > >Subject: [AccessD] check for file in ftp site > >Date: Mon, 23 Jul 2007 15:35:56 -0400 > > > >I am wanting to log into an ftp site, look thru all the txt files (only >txt > >files), and download all files that are new since the last check. > > > >The files are all numbered sequentially so I can parse out the numbers to > >determine what files are new. > > > >However, I could use some assistance in looping thru the txt file names. > > > >Thanks. > > > >Reuben Cummings > >GFC, LLC > >812.523.1017 > > > > > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.com > >_________________________________________________________________ >http://newlivehotmail.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 _________________________________________________________________ Need a brain boost? Recharge with a stimulating game. Play now!? http://club.live.com/home.aspx?icid=club_hotmailtextlink1 From jimdettman at verizon.net Tue Jul 24 10:30:03 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Tue, 24 Jul 2007 11:30:03 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <000301c7ce07$81d373c0$8abea8c0@XPS> Groan...I guess I'll stick my neck out a bit. <<1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table.>> Yes, so a record is always uniquely identified. <<2. PKs should always be an autonumber (Access), Identity (SQL) or GUID.>> I don't agree with that 100%. Surrogate keys are in widespread use and for most tables are used 98% of the time in today's designs, but I think it's really silly to add a surrogate key to a many to many linking table when you already have a FK pair that must be unique and would serve perfectly well as a PK. <<3. Avoid complex PKs such as two PKs from two other tables.>> Don't agree in regards to M-M linking tables. <<4. Avoid complex PKs such as two fields from one table.>> If your in the surrogate key world, this doesn't ever apply. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Tue Jul 24 10:50:24 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 24 Jul 2007 11:50:24 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070724155034.B9365BCC8@smtp-auth.no-ip.com> I always and only use autonumber type PKs. I differentiate between PKs and unique indexes, whereas many people do not. A unique index's job is to prevent the same "unique" data from going into the table twice. A PK's job is to act as a pointer to a specific record and to allow EFFICIENT joins between tables (act as a pointer). Those are two completely different functions, and they BOTH must be addressed, but they do NOT have to be addressed in the same structure. In fact the EFFICIENT join PREVENTS them being addressed in the same structure! Pulling fields from parent / grandparent / greatgrandparent/greatgreatgreatgreatgreat...grandparent tables down into the current table just causes a slew of problems, from performance to update issues. Autoincrement PKs neatly sidestep all of those problems. In my experience, most of those who demand natural keys use "convenience" reasons such as "I can always look in any table and see where the data comes from or who owns the data (lineage). True, but irrelevant. That is laziness, not requirement. I have also heard a lot of arguments like "if parent records are deleted I can still see who the data belongs to". True but irrelevant. That is again laziness (too lazy / sloppy to implement RI). I do not allow parents to be deleted unless children are deleted. I have been doing this a long time and NEVER REQUIRED a natural key, and in fact AFAICR have never built a table with a natural key. Now I will grant there is a gray area such as "colors" where the color is the only "value" field in the table and so "why not" use it as the PK. The answer comes back to speed issues. Integers are faster to deal with inside of a computer when doing things like joins. Thus even in such cases I use autonumber PKs. I can tell you that I have been doing databases since 1995 and have never, in even one case, REQUIRED a natural key. I DO require unique indexes just as anyone else will. Just my opinion, ymmv etc. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue Jul 24 11:14:18 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 24 Jul 2007 09:14:18 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070724155034.B9365BCC8@smtp-auth.no-ip.com> References: <20070724155034.B9365BCC8@smtp-auth.no-ip.com> Message-ID: Yes, John, we know. Now wipe the foam off your lips and lie down quietly until the fit passes. LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 8:50 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I always and only use autonumber type PKs. I differentiate between PKs and unique indexes, whereas many people do not. A unique index's job is to prevent the same "unique" data from going into the table twice. A PK's job is to act as a pointer to a specific record and to allow EFFICIENT joins between tables (act as a pointer). Those are two completely different functions, and they BOTH must be addressed, but they do NOT have to be addressed in the same structure. In fact the EFFICIENT join PREVENTS them being addressed in the same structure! Pulling fields from parent / grandparent / greatgrandparent/greatgreatgreatgreatgreat...grandparent tables down into the current table just causes a slew of problems, from performance to update issues. Autoincrement PKs neatly sidestep all of those problems. In my experience, most of those who demand natural keys use "convenience" reasons such as "I can always look in any table and see where the data comes from or who owns the data (lineage). True, but irrelevant. That is laziness, not requirement. I have also heard a lot of arguments like "if parent records are deleted I can still see who the data belongs to". True but irrelevant. That is again laziness (too lazy / sloppy to implement RI). I do not allow parents to be deleted unless children are deleted. I have been doing this a long time and NEVER REQUIRED a natural key, and in fact AFAICR have never built a table with a natural key. Now I will grant there is a gray area such as "colors" where the color is the only "value" field in the table and so "why not" use it as the PK. The answer comes back to speed issues. Integers are faster to deal with inside of a computer when doing things like joins. Thus even in such cases I use autonumber PKs. I can tell you that I have been doing databases since 1995 and have never, in even one case, REQUIRED a natural key. I DO require unique indexes just as anyone else will. Just my opinion, ymmv etc. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim 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 jwcolby at colbyconsulting.com Tue Jul 24 11:52:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 24 Jul 2007 12:52:23 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070724165233.E45B0BE8D@smtp-auth.no-ip.com> ROTFLMAO. The fit never passes. It just subsides until the moon rises again. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Tuesday, July 24, 2007 12:14 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Yes, John, we know. Now wipe the foam off your lips and lie down quietly until the fit passes. LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 8:50 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I always and only use autonumber type PKs. I differentiate between PKs and unique indexes, whereas many people do not. A unique index's job is to prevent the same "unique" data from going into the table twice. A PK's job is to act as a pointer to a specific record and to allow EFFICIENT joins between tables (act as a pointer). Those are two completely different functions, and they BOTH must be addressed, but they do NOT have to be addressed in the same structure. In fact the EFFICIENT join PREVENTS them being addressed in the same structure! Pulling fields from parent / grandparent / greatgrandparent/greatgreatgreatgreatgreat...grandparent tables down into the current table just causes a slew of problems, from performance to update issues. Autoincrement PKs neatly sidestep all of those problems. In my experience, most of those who demand natural keys use "convenience" reasons such as "I can always look in any table and see where the data comes from or who owns the data (lineage). True, but irrelevant. That is laziness, not requirement. I have also heard a lot of arguments like "if parent records are deleted I can still see who the data belongs to". True but irrelevant. That is again laziness (too lazy / sloppy to implement RI). I do not allow parents to be deleted unless children are deleted. I have been doing this a long time and NEVER REQUIRED a natural key, and in fact AFAICR have never built a table with a natural key. Now I will grant there is a gray area such as "colors" where the color is the only "value" field in the table and so "why not" use it as the PK. The answer comes back to speed issues. Integers are faster to deal with inside of a computer when doing things like joins. Thus even in such cases I use autonumber PKs. I can tell you that I have been doing databases since 1995 and have never, in even one case, REQUIRED a natural key. I DO require unique indexes just as anyone else will. Just my opinion, ymmv etc. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim 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 dwaters at usinternet.com Tue Jul 24 12:01:45 2007 From: dwaters at usinternet.com (Dan Waters) Date: Tue, 24 Jul 2007 12:01:45 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? Message-ID: <004101c7ce14$5117cad0$0200a8c0@danwaters> In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan From jwcolby at colbyconsulting.com Tue Jul 24 12:13:16 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 24 Jul 2007 13:13:16 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <004101c7ce14$5117cad0$0200a8c0@danwaters> Message-ID: <20070724171327.05A92BD62@smtp-auth.no-ip.com> You could reasonably quickly set up a test to find out by building a dynamic query, a string such as select PKID from tblX where (PKID=1 or PKID=2 or...). Add 10 (or 100) at a time and see how far you get. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 1:02 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Number of 'OR's in queries - what's the limit? In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Tue Jul 24 12:31:31 2007 From: dwaters at usinternet.com (Dan Waters) Date: Tue, 24 Jul 2007 12:31:31 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <20070724171327.05A92BD62@smtp-auth.no-ip.com> References: <004101c7ce14$5117cad0$0200a8c0@danwaters> <20070724171327.05A92BD62@smtp-auth.no-ip.com> Message-ID: <004201c7ce18$79e7cd80$0200a8c0@danwaters> That's a good plan! I was hoping to do a customer update within the next half hour though. I was hoping that someone had seen some documentation on this. The number 40 was documented 'somewhere' in Access help. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? You could reasonably quickly set up a test to find out by building a dynamic query, a string such as select PKID from tblX where (PKID=1 or PKID=2 or...). Add 10 (or 100) at a time and see how far you get. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 1:02 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Number of 'OR's in queries - what's the limit? In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan -- 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 markamatte at hotmail.com Tue Jul 24 13:22:36 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 24 Jul 2007 18:22:36 +0000 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <004201c7ce18$79e7cd80$0200a8c0@danwaters> Message-ID: I found it in A97 and A2002...search help for 'Specifications'...in 97 its query specs...and in 2002 its access specs...97 is 40...2002 is 99. I don't have 2003 to look. Good Luck, Mark A. Matte >From: "Dan Waters" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? >Date: Tue, 24 Jul 2007 12:31:31 -0500 > >That's a good plan! I was hoping to do a customer update within the next >half hour though. > >I was hoping that someone had seen some documentation on this. The number >40 was documented 'somewhere' in Access help. > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby >Sent: Tuesday, July 24, 2007 12:13 PM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > >You could reasonably quickly set up a test to find out by building a >dynamic >query, a string such as select PKID from tblX where (PKID=1 or PKID=2 >or...). Add 10 (or 100) at a time and see how far you get. > > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters >Sent: Tuesday, July 24, 2007 1:02 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Number of 'OR's in queries - what's the limit? > >In Access 97, there was a limit of 40 OR words in a query. There is a >limit >in Access 2003, it's >250, but I don't know what it actually is. > >Does anyone know? > >Thanks! >Dan > > > >-- >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 _________________________________________________________________ http://newlivehotmail.com From ebarro at verizon.net Tue Jul 24 13:45:02 2007 From: ebarro at verizon.net (Eric Barro) Date: Tue, 24 Jul 2007 11:45:02 -0700 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <004201c7ce18$79e7cd80$0200a8c0@danwaters> Message-ID: <0JLP007V75EOGYZ0@vms046.mailsrvcs.net> Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with Ors tend to take longer to execute. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? That's a good plan! I was hoping to do a customer update within the next half hour though. I was hoping that someone had seen some documentation on this. The number 40 was documented 'somewhere' in Access help. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? You could reasonably quickly set up a test to find out by building a dynamic query, a string such as select PKID from tblX where (PKID=1 or PKID=2 or...). Add 10 (or 100) at a time and see how far you get. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 1:02 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Number of 'OR's in queries - what's the limit? In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM From ssharkins at setel.com Tue Jul 24 13:47:49 2007 From: ssharkins at setel.com (Susan Harkins) Date: Tue, 24 Jul 2007 14:47:49 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <000301c7ce07$81d373c0$8abea8c0@XPS> References: <000301c7ce07$81d373c0$8abea8c0@XPS> Message-ID: <006c01c7ce23$22f5cda0$dc34fad1@SusanOne> I don't agree with that 100%. Surrogate keys are in widespread use and for most tables are used 98% of the time in today's designs, but I think it's really silly to add a surrogate key to a many to many linking table when you already have a FK pair that must be unique and would serve perfectly well as a PK. ======Other than habit -- consistency can be a good thing. Now to add to your list -- and you can thank Martin Reid for this additional few: PK should be stable. In real life, things do change, hence cascading updates, but use a key that's not prone to change. When using natural keys, choose the key with the fewest fields necessary -- I know that should be a given, but I've seen some that made me shake my head... :( Susan H. From EdTesiny at oasas.state.ny.us Tue Jul 24 14:04:15 2007 From: EdTesiny at oasas.state.ny.us (Tesiny, Ed) Date: Tue, 24 Jul 2007 15:04:15 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: References: <004201c7ce18$79e7cd80$0200a8c0@danwaters> Message-ID: Still looks like 99 in 2003 Ed Tesiny EdTesiny at oasas.state.ny.us > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > Mark A Matte > Sent: Tuesday, July 24, 2007 2:23 PM > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > I found it in A97 and A2002...search help for > 'Specifications'...in 97 its > query specs...and in 2002 its access specs...97 is 40...2002 is 99. > > I don't have 2003 to look. > > Good Luck, > > Mark A. Matte > > > >From: "Dan Waters" > >Reply-To: Access Developers discussion and problem > >solving > >To: "'Access Developers discussion and problem > >solving'" > >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > >Date: Tue, 24 Jul 2007 12:31:31 -0500 > > > >That's a good plan! I was hoping to do a customer update > within the next > >half hour though. > > > >I was hoping that someone had seen some documentation on > this. The number > >40 was documented 'somewhere' in Access help. > > > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > >Sent: Tuesday, July 24, 2007 12:13 PM > >To: 'Access Developers discussion and problem solving' > >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > > >You could reasonably quickly set up a test to find out by building a > >dynamic > >query, a string such as select PKID from tblX where (PKID=1 or PKID=2 > >or...). Add 10 (or 100) at a time and see how far you get. > > > > > >John W. Colby > >Colby Consulting > >www.ColbyConsulting.com > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > >Sent: Tuesday, July 24, 2007 1:02 PM > >To: 'Access Developers discussion and problem solving' > >Subject: [AccessD] Number of 'OR's in queries - what's the limit? > > > >In Access 97, there was a limit of 40 OR words in a query. > There is a > >limit > >in Access 2003, it's >250, but I don't know what it actually is. > > > >Does anyone know? > > > >Thanks! > >Dan > > > > > > > >-- > >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 > > _________________________________________________________________ > http://newlivehotmail.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From dwaters at usinternet.com Tue Jul 24 14:10:05 2007 From: dwaters at usinternet.com (Dan Waters) Date: Tue, 24 Jul 2007 14:10:05 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <0JLP007V75EOGYZ0@vms046.mailsrvcs.net> References: <004201c7ce18$79e7cd80$0200a8c0@danwaters> <0JLP007V75EOGYZ0@vms046.mailsrvcs.net> Message-ID: <005101c7ce26$3ec58680$0200a8c0@danwaters> Perhaps this will bypass the limit altogether! Thanks Eric! Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Tuesday, July 24, 2007 1:45 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with Ors tend to take longer to execute. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? That's a good plan! I was hoping to do a customer update within the next half hour though. I was hoping that someone had seen some documentation on this. The number 40 was documented 'somewhere' in Access help. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? You could reasonably quickly set up a test to find out by building a dynamic query, a string such as select PKID from tblX where (PKID=1 or PKID=2 or...). Add 10 (or 100) at a time and see how far you get. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 1:02 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Number of 'OR's in queries - what's the limit? In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Tue Jul 24 14:10:05 2007 From: dwaters at usinternet.com (Dan Waters) Date: Tue, 24 Jul 2007 14:10:05 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: References: <004201c7ce18$79e7cd80$0200a8c0@danwaters> Message-ID: <005201c7ce26$3f1665a0$0200a8c0@danwaters> 2003 is also 99. But, using WHERE PKID IN (1,2,4,8, ...) looks like there will be no limit. We'll find out. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Tuesday, July 24, 2007 1:23 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? I found it in A97 and A2002...search help for 'Specifications'...in 97 its query specs...and in 2002 its access specs...97 is 40...2002 is 99. I don't have 2003 to look. Good Luck, Mark A. Matte >From: "Dan Waters" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? >Date: Tue, 24 Jul 2007 12:31:31 -0500 > >That's a good plan! I was hoping to do a customer update within the next >half hour though. > >I was hoping that someone had seen some documentation on this. The number >40 was documented 'somewhere' in Access help. > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby >Sent: Tuesday, July 24, 2007 12:13 PM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > >You could reasonably quickly set up a test to find out by building a >dynamic >query, a string such as select PKID from tblX where (PKID=1 or PKID=2 >or...). Add 10 (or 100) at a time and see how far you get. > > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters >Sent: Tuesday, July 24, 2007 1:02 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Number of 'OR's in queries - what's the limit? > >In Access 97, there was a limit of 40 OR words in a query. There is a >limit >in Access 2003, it's >250, but I don't know what it actually is. > >Does anyone know? > >Thanks! >Dan > > > >-- >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 _________________________________________________________________ http://newlivehotmail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jmhecht at earthlink.net Tue Jul 24 16:22:10 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Tue, 24 Jul 2007 14:22:10 -0700 (GMT-07:00) Subject: [AccessD] Primary Key Best Practices Message-ID: <28691268.1185312130566.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> I anm digging a deep hole for this one. Looking out from stuff flying from JC's mountain fortress of code. -----Original Message----- >From: Jim Hewson >Sent: Jul 24, 2007 7:55 AM >To: Access Developers discussion and problem solving >Subject: [AccessD] Primary Key Best Practices > >I need a few good references (preferably electronic) on the Best >Practices for defining Primary Keys (PK) >Here at the office we have had a few heated discussions about primary >keys. >I don't' mean to stir the pot on this list, just curious what others >think. > >1. All tables should have a primary key even though it will not be used >as a foreign key (FK) in another table. >2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. >3. Avoid complex PKs such as two PKs from two other tables. >4. Avoid complex PKs such as two fields from one table. > >You could probably come up with some more. > >Thanks, > >Jim H. > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Tue Jul 24 19:47:55 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 24 Jul 2007 17:47:55 -0700 Subject: [AccessD] Allow Edits Message-ID: <00ba01c7ce55$706e7e60$0301a8c0@HAL9005> Dear List: I have an unbound combo box on a form with a list of employees. If the current user chooses their own name (it's stored in a table, I can do a DLookup) then I allow additions and edits. If they don't choose their own name I set allow additions and edit to false. Works great that far. Problem is that the combo box isn't editable so after a name is chosen which is NOT the current user and AllowEdits is set to False, they can't choose another record. The combo box won't update. I tried putting Me.AllowEdits = True in the click event of the combo box but the click event is firing AFTER the ArfterUpdate event so that's not working. Brute force solution would be to disable all of the text boxes on the form if the chosen user isn't the current user and V.V. But is there a more elegant way? MTIA Rocky From ssharkins at setel.com Tue Jul 24 20:01:24 2007 From: ssharkins at setel.com (Susan Harkins) Date: Tue, 24 Jul 2007 21:01:24 -0400 Subject: [AccessD] Allow Edits In-Reply-To: <00ba01c7ce55$706e7e60$0301a8c0@HAL9005> References: <00ba01c7ce55$706e7e60$0301a8c0@HAL9005> Message-ID: <004501c7ce57$532c7e90$4eb82ad1@SusanOne> Problem is that the combo box isn't editable so after a name is chosen which is NOT the current user and AllowEdits is set to False, they can't choose another record. The combo box won't update. ========If you're inhibiting edits, why would you want to allow one? Susan H. From newsgrps at dalyn.co.nz Tue Jul 24 20:08:52 2007 From: newsgrps at dalyn.co.nz (David Emerson) Date: Wed, 25 Jul 2007 13:08:52 +1200 Subject: [AccessD] Allow Edits In-Reply-To: <004501c7ce57$532c7e90$4eb82ad1@SusanOne> References: <00ba01c7ce55$706e7e60$0301a8c0@HAL9005> <004501c7ce57$532c7e90$4eb82ad1@SusanOne> Message-ID: <20070725010904.OKUK9092.fep01.xtra.co.nz@Dalyn.dalyn.co.nz> Rocky, Put some code on the Enter event of the combo box to allow edits, then on the Exit event determine from the value of the combo box whether to set AllowEdits to true or false. Regards David Emerson Dalyn Software Ltd Wellington, New Zealand At 25/07/2007, you wrote: > >Problem is that the combo box isn't editable so after a name is chosen which >is NOT the current user and AllowEdits is set to False, they can't choose >another record. The combo box won't update. > >========If you're inhibiting edits, why would you want to allow one? > >Susan H. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Tue Jul 24 21:36:21 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 24 Jul 2007 19:36:21 -0700 Subject: [AccessD] Allow Edits In-Reply-To: <004501c7ce57$532c7e90$4eb82ad1@SusanOne> Message-ID: <00c201c7ce64$96757500$0301a8c0@HAL9005> If the person who logged in selects their own name then editing their own information is OK. Otherwise, they can look at anyone else's but not change it. (BTW, legacy application - I wouldn't have done it this way.) Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Tuesday, July 24, 2007 6:01 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Allow Edits Problem is that the combo box isn't editable so after a name is chosen which is NOT the current user and AllowEdits is set to False, they can't choose another record. The combo box won't update. ========If you're inhibiting edits, why would you want to allow one? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM From rockysmolin at bchacc.com Tue Jul 24 21:37:28 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 24 Jul 2007 19:37:28 -0700 Subject: [AccessD] Allow Edits In-Reply-To: <20070725010904.OKUK9092.fep01.xtra.co.nz@Dalyn.dalyn.co.nz> Message-ID: <00c301c7ce64$be484fd0$0301a8c0@HAL9005> David: Perfect! Enter and Exit versus Click and AfterUpdate. Who knew? Thanks so much for the quick response. My bacon been saved again! Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson Sent: Tuesday, July 24, 2007 6:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Allow Edits Rocky, Put some code on the Enter event of the combo box to allow edits, then on the Exit event determine from the value of the combo box whether to set AllowEdits to true or false. Regards David Emerson Dalyn Software Ltd Wellington, New Zealand At 25/07/2007, you wrote: > >Problem is that the combo box isn't editable so after a name is chosen >which is NOT the current user and AllowEdits is set to False, they >can't choose another record. The combo box won't update. > >========If you're inhibiting edits, why would you want to allow one? > >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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM From darrend at nimble.com.au Wed Jul 25 01:55:51 2007 From: darrend at nimble.com.au (Darren D) Date: Wed, 25 Jul 2007 16:55:51 +1000 Subject: [AccessD] Allow Edits In-Reply-To: <00c301c7ce64$be484fd0$0301a8c0@HAL9005> Message-ID: <200707250655.l6P6tmDu022599@databaseadvisors.com> Hi Rocky Glad you got it sorted In these situations where I DO want certain fields to be editable or visible - and others not I setup and interrogate the control's TAG property EG I set up the TAG to say something meaningful like "CanBeEnabled" etc Then in the relevant code I call something like this Private Sub ps_EnableSomeControls() Dim ctl as Control For each ctl in me.controls 'The whole form If ctl.TAG = "CanBeEnabled" then 'you can even set if ctl.type = XXX (EG disable all the combos etc) ctl.enabled = true 'or 'ctl.visible = true Else 'Can write an else here End if Next ctl End sub -----Original Message----- From: Rocky Smolin at Beach Access Software [mailto:rockysmolin at bchacc.com] Sent: Wednesday, 25 July 2007 12:37 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Allow Edits David: Perfect! Enter and Exit versus Click and AfterUpdate. Who knew? Thanks so much for the quick response. My bacon been saved again! Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson Sent: Tuesday, July 24, 2007 6:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Allow Edits Rocky, Put some code on the Enter event of the combo box to allow edits, then on the Exit event determine from the value of the combo box whether to set AllowEdits to true or false. Regards David Emerson Dalyn Software Ltd Wellington, New Zealand At 25/07/2007, you wrote: > >Problem is that the combo box isn't editable so after a name is chosen >which is NOT the current user and AllowEdits is set to False, they >can't choose another record. The combo box won't update. > >========If you're inhibiting edits, why would you want to allow one? > >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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bbruen at unwired.com.au Wed Jul 25 07:11:43 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Wed, 25 Jul 2007 22:11:43 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070724165233.E45B0BE8D@smtp-auth.no-ip.com> References: <20070724165233.E45B0BE8D@smtp-auth.no-ip.com> Message-ID: <200707252211.43659.bbruen@unwired.com.au> On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce From rockysmolin at bchacc.com Wed Jul 25 08:09:38 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Wed, 25 Jul 2007 06:09:38 -0700 Subject: [AccessD] Allow Edits In-Reply-To: <200707250655.l6P6tmDu022599@databaseadvisors.com> Message-ID: <001f01c7cebd$0e44a8f0$0301a8c0@HAL9005> Yeah, I always forget about that TAG property. I've used it before - to allow the user interrupt a long process for example by pressing a key. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D Sent: Tuesday, July 24, 2007 11:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Allow Edits Hi Rocky Glad you got it sorted In these situations where I DO want certain fields to be editable or visible - and others not I setup and interrogate the control's TAG property EG I set up the TAG to say something meaningful like "CanBeEnabled" etc Then in the relevant code I call something like this Private Sub ps_EnableSomeControls() Dim ctl as Control For each ctl in me.controls 'The whole form If ctl.TAG = "CanBeEnabled" then 'you can even set if ctl.type = XXX (EG disable all the combos etc) ctl.enabled = true 'or 'ctl.visible = true Else 'Can write an else here End if Next ctl End sub -----Original Message----- From: Rocky Smolin at Beach Access Software [mailto:rockysmolin at bchacc.com] Sent: Wednesday, 25 July 2007 12:37 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Allow Edits David: Perfect! Enter and Exit versus Click and AfterUpdate. Who knew? Thanks so much for the quick response. My bacon been saved again! Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson Sent: Tuesday, July 24, 2007 6:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Allow Edits Rocky, Put some code on the Enter event of the combo box to allow edits, then on the Exit event determine from the value of the combo box whether to set AllowEdits to true or false. Regards David Emerson Dalyn Software Ltd Wellington, New Zealand At 25/07/2007, you wrote: > >Problem is that the combo box isn't editable so after a name is chosen >which is NOT the current user and AllowEdits is set to False, they >can't choose another record. The combo box won't update. > >========If you're inhibiting edits, why would you want to allow one? > >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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: 7/24/2007 1:50 PM From jwcolby at colbyconsulting.com Wed Jul 25 08:18:02 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 09:18:02 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707252211.43659.bbruen@unwired.com.au> Message-ID: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Bruce, >Any table that does not have a natural primary key is not a pure dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Wed Jul 25 09:14:14 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 10:14:14 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <006c01c7ce23$22f5cda0$dc34fad1@SusanOne> References: <000301c7ce07$81d373c0$8abea8c0@XPS> <006c01c7ce23$22f5cda0$dc34fad1@SusanOne> Message-ID: <00f801c7cec6$14e13b20$8abea8c0@XPS> Susan, True, but in the case of a M to M table your just introducing another column and a index that really is not needed. It seems silly to me to have something like: tblLinking LinkID - Autonumber - PK BookID - Long - CK1A AuthorID - Long - CK1B Instead of tblLinking BookID - Long - PK1A AuthorID - Long - PK1B just for the sake of having an auto number in there. The BookID and AuthorID already form a unique pair and they typically would not be used as a foreign key in another table. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Tuesday, July 24, 2007 2:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I don't agree with that 100%. Surrogate keys are in widespread use and for most tables are used 98% of the time in today's designs, but I think it's really silly to add a surrogate key to a many to many linking table when you already have a FK pair that must be unique and would serve perfectly well as a PK. ======Other than habit -- consistency can be a good thing. Now to add to your list -- and you can thank Martin Reid for this additional few: PK should be stable. In real life, things do change, hence cascading updates, but use a key that's not prone to change. When using natural keys, choose the key with the fewest fields necessary -- I know that should be a given, but I've seen some that made me shake my head... :( Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 09:35:27 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 10:35:27 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Message-ID: <20070725143539.6CA22BD0E@smtp-auth.no-ip.com> >So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. And I forgot to add: 3) Should be efficient, which is where the autoincrement shines. Integers are the basic currency of the modern CPU and as such they are the fastest possible unit of information when doing compares. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure >dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 Jul 25 09:42:00 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 10:42:00 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> References: <200707252211.43659.bbruen@unwired.com.au> <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Message-ID: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> John, <<1) The PK should be stable (NEVER changes). >> Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. <> That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. In theory you cannot have a PK without it being a unique index. That's part of the definition of what a natural PK is. Out of the pool of CK's, you would use the CK that is the most stable, shortest in length, and the least complex (simple vs compound). <> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. Surrogate keys work well in computer systems, but the relational model can be applied to much more then computer systems and the PK as you describe it vs what it is in the relational model are not the same thing. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 cfoust at infostatsystems.com Wed Jul 25 09:57:17 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 07:57:17 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707252211.43659.bbruen@unwired.com.au> References: <20070724165233.E45B0BE8D@smtp-auth.no-ip.com> <200707252211.43659.bbruen@unwired.com.au> Message-ID: Troublemaker!! LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 5:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 09:59:38 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 07:59:38 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> References: <200707252211.43659.bbruen@unwired.com.au><20070725131815.187FDBD8E@smtp-auth.no-ip.com> <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: Jim, I'm going to flag your post for future reference ... and the next time the moon is full! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 25, 2007 7:42 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <<1) The PK should be stable (NEVER changes). >> Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. <> That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. In theory you cannot have a PK without it being a unique index. That's part of the definition of what a natural PK is. Out of the pool of CK's, you would use the CK that is the most stable, shortest in length, and the least complex (simple vs compound). <> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. Surrogate keys work well in computer systems, but the relational model can be applied to much more then computer systems and the PK as you describe it vs what it is in the relational model are not the same thing. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure >dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 setel.com Wed Jul 25 10:17:50 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 25 Jul 2007 11:17:50 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> References: <200707252211.43659.bbruen@unwired.com.au><20070725131815.187FDBD8E@smtp-auth.no-ip.com> <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: <002a01c7cece$f7b5a550$2c34fad1@SusanOne> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. =======If we didn't have reliable systems, we wouldn't be using relational databases. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. =======You have the original model and you have what is currently in practice. If the relational model, as originally devised, can't change, then you're right. But, in practice, it absolutely has changed. Susan H From jwcolby at colbyconsulting.com Wed Jul 25 10:19:00 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 11:19:00 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Jim, >Surrogate keys are nothing more then pointers. Correct!!!!!!!!!!!!!!!!!!!!!!!!!! This is a logical construct Jim. You accept that a PK can be a surrogate, you state that a PK is nothing but a pointer, therefore you accept (and state) that a PK is nothing but a pointer. AND... from the perspective of the child, a FK is nothing but a pointer. Does a table HAVE TO HAVE a PK at all? Not if it has no children. Ergo, what matters from the child's perspective is what the PK is all about, and that is simply a POINTER back to the parent. AND... Since a surrogate key functions as a PK, then... A PK must be nothing but a pointer... > Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. And I don't give a rat's patuty about relational theory, I care about what works. Relational theory says you should normalize to 16 (IIRC) different levels. When was the last time you did that? Do you even UNDERSTAND 9th (or 12th, or 16th) normal form? OK YOU probably do but I don't and don't care that I don't. So day in and day out you (or at least I) ignore relational theory and yet you attempt to flaunt that same theory in the great PK debate for what purpose??? Having the PK change is a no-no. Sorry, it just is. It causes a whole host of issues and given that it doesn't HAVE to change.... >That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. And I don't give a rat's patuty about relational theory, I care about what works. >Surrogates only work in computer systems because we have systems that are reliable. But we do, so what's your point? Natural keys only work (in large systems) because we have systems that are reliable. Imagine trying to manually correct 100 million records where something got corrupted. No easier (without a reliable system). I have NEVER used paper and pencil in a database so who really cares. >To call them a PK in regards to the relational model is simply incorrect. OK, and who cares? I simply do not care about the relational model (in this debate), I care about what works efficiently. I use what works (of the model) and I abandon what is inefficient (natural keys). Natural keys are NOT A REQUIREMENT, you admit that yourself. I still have a PK, it is just a surrogate. If you accept that surrogates do work then why does the insistence in relational model PK being a natural key even matter? You are nitpicking to death stuff that simply does not matter. If you want to insist that the PK HAS TO BE a natural key, then how can you say in the next breath that "I don't object to the use of surrogate keys" C'mon Jim, give it up. I will sign a piece of paper stating whatever you want about PKs and natural keys and relational theory, I simply DO NOT CARE. What I care about is that they are inefficient and cause problems that surrogate keys avoid. Happy? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 25, 2007 10:42 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <<1) The PK should be stable (NEVER changes). >> Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. <> That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. In theory you cannot have a PK without it being a unique index. That's part of the definition of what a natural PK is. Out of the pool of CK's, you would use the CK that is the most stable, shortest in length, and the least complex (simple vs compound). <> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. Surrogate keys work well in computer systems, but the relational model can be applied to much more then computer systems and the PK as you describe it vs what it is in the relational model are not the same thing. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure >dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 john at winhaven.net Wed Jul 25 10:30:32 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 10:30:32 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00f801c7cec6$14e13b20$8abea8c0@XPS> References: <000301c7ce07$81d373c0$8abea8c0@XPS><006c01c7ce23$22f5cda0$dc34fad1@SusanOne> <00f801c7cec6$14e13b20$8abea8c0@XPS> Message-ID: <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> Jim, This is something I haven't seen before and is in my early morning mind, quite brilliant! Are there any drawbacks to doing this? I can't imagine it would be much of a difference (size or performance wise) in any of my applications / databases but it is certainly something worth considering implementing in the future. Always open to technical improvements... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman True, but in the case of a M to M table your just introducing another column and a index that really is not needed. It seems silly to me to have something like: tblLinking LinkID - Autonumber - PK BookID - Long - CK1A AuthorID - Long - CK1B Instead of tblLinking BookID - Long - PK1A AuthorID - Long - PK1B just for the sake of having an auto number in there. The BookID and AuthorID already form a unique pair and they typically would not be used as a foreign key in another table. From john at winhaven.net Wed Jul 25 10:30:32 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 10:30:32 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> References: <200707252211.43659.bbruen@unwired.com.au> <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Message-ID: <010f01c7ced0$bf524db0$6402a8c0@ScuzzPaq> While I agree with you on the subject matter at hand - I don't recall seeing this as criteria for a primary key before. Is this a Colbyism or am I just not quite awake yet? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. From jwelz at hotmail.com Wed Jul 25 10:39:11 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Wed, 25 Jul 2007 09:39:11 -0600 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: Jim: I'm generally with John on this one. The question was about best practices, not relational theory. Every comment you made to John was about relational theory. This is about computer databases; about 'Practices', not 'Theory'. In practice, you can not beat an autonumber for size and speed (performance) in a computer environment. Apply it consistently in conjuction with any other unique indexes on fields or combinations of fields you identify as candidate keys and no user can mess up any more than they possibly could using any other key. None of the 'Theory' comments impact the practical utility and validity of using a unique long or GUID as a primary key. If occasionally you have a key that will likely not be used in a join, at least you retain the flexibilty should the unforseen arise. In terms of additional space wasted for the case where such a key is never used in a join, it is the smallest amout possible for the flexiblity and consistency gained. That sounds like a best practice to me. Regardless of whether anyone agrees with me, it is my practice because it works well. You won't hear from mea again on this topic this year. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Jim Dettman" > >John, > ><<1) The PK should be stable (NEVER changes). >> > > Don' agree with "never". You want it as stable as possible, but there >is >nothing in relational theory that says it can never change. > ><real life or in theory.>> > > That is simply not true. With relational theory, the PK is derived from >the pool of CK's, which is based on the data. In theory you cannot have a >PK without it being a unique index. That's part of the definition of what >a >natural PK is. Out of the pool of CK's, you would use the CK that is the >most stable, shortest in length, and the least complex (simple vs >compound). > ><surrogate key avoids a whole slew of real life problems, and creates none >(in my experience).>> > > Surrogates only work in computer systems because we have systems that >are >reliable. If I gave you pen and paper and had you keep track of data using >the relational model, you'd be in a pretty big mess fairly quick if you >used >surrogate keys. > > I don't object to the use of surrogate keys, but what I do object to is >the apples and oranges approach you use to claim what a PK is and surrogate >keys fit in the relational model. Surrogate keys are nothing more then >pointers. To call them a PK in regards to the relational model is simply >incorrect. > > Surrogate keys work well in computer systems, but the relational model >can >be applied to much more then computer systems and the PK as you describe it >vs what it is in the relational model are not the same thing. > >Jim. _________________________________________________________________ Fight Allergies With Live Search http://search.live.com/results.aspx?q=Remedies+For+Spring+Allergies&mkt=en-ca&FORM=SERNEP From jwcolby at colbyconsulting.com Wed Jul 25 10:46:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 11:46:23 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <010f01c7ced0$bf524db0$6402a8c0@ScuzzPaq> Message-ID: <20070725154636.092FDBCB9@smtp-auth.no-ip.com> John, This is definitely a Colbyism. Basically I make no claim to making any of this stuff up. I am a logical person, I do what works most efficiently whenever I can. Did I make that up? Probably not. It comes from discussions here on this list where any time you expose the PK to view, some idiot wants to use it for some purpose that it is not supposed to be used for (like a "must be in order, with no values missing" number in an accounting system. Obviously we can and do delete records all the time so using the PK for such a rule / purpose guarantees issues whenever the idiot strikes, thus simply NEVER expose it to view. The PK's function (in real life) is exactly and only for use as a pointer from a child back to the parent. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 11:31 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices While I agree with you on the subject matter at hand - I don't recall seeing this as criteria for a primary key before. Is this a Colbyism or am I just not quite awake yet? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 10:48:55 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 11:48:55 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> Jurgen, Why can't I state it in such reasoned and logical terms? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 25, 2007 11:39 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Jim: I'm generally with John on this one. The question was about best practices, not relational theory. Every comment you made to John was about relational theory. This is about computer databases; about 'Practices', not 'Theory'. In practice, you can not beat an autonumber for size and speed (performance) in a computer environment. Apply it consistently in conjuction with any other unique indexes on fields or combinations of fields you identify as candidate keys and no user can mess up any more than they possibly could using any other key. None of the 'Theory' comments impact the practical utility and validity of using a unique long or GUID as a primary key. If occasionally you have a key that will likely not be used in a join, at least you retain the flexibilty should the unforseen arise. In terms of additional space wasted for the case where such a key is never used in a join, it is the smallest amout possible for the flexiblity and consistency gained. That sounds like a best practice to me. Regardless of whether anyone agrees with me, it is my practice because it works well. You won't hear from mea again on this topic this year. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.com From jimdettman at verizon.net Wed Jul 25 10:53:01 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 11:53:01 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <002a01c7cece$f7b5a550$2c34fad1@SusanOne> References: <200707252211.43659.bbruen@unwired.com.au><20070725131815.187FDBD8E@smtp-auth.no-ip.com> <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <002a01c7cece$f7b5a550$2c34fad1@SusanOne> Message-ID: <012401c7ced3$e1e12b00$8abea8c0@XPS> Susan, <> Well the model hasn't changed that I'm aware of, but your right, it has changed in practice. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 11:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. =======If we didn't have reliable systems, we wouldn't be using relational databases. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. =======You have the original model and you have what is currently in practice. If the relational model, as originally devised, can't change, then you're right. But, in practice, it absolutely has changed. Susan H -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Wed Jul 25 11:01:51 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 11:01:51 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> References: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> Message-ID: <013f01c7ced5$1ed88250$6402a8c0@ScuzzPaq> emotional response? too much caffiene? ... ;o) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Jurgen, Why can't I state it in such reasoned and logical terms? John W. Colby From john at winhaven.net Wed Jul 25 11:10:38 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 11:10:38 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725154636.092FDBCB9@smtp-auth.no-ip.com> References: <010f01c7ced0$bf524db0$6402a8c0@ScuzzPaq> <20070725154636.092FDBCB9@smtp-auth.no-ip.com> Message-ID: <014301c7ced6$57f9a450$6402a8c0@ScuzzPaq> LOL! I actually have the same view on PK but have recently had to expose PKs in an application for a client. (Well, I suppose I could have told them NO but then I'd probably not still be working for them.) They implemented a new functionality in their GIS system. Instead of paying me to implement it correctly, they tried to have "local" firm implement the GIS (spatial) portion and retain me to do the "tabular" portion. (The whole thing is ridiculous but when you do government work you come to expect this.) Anyway, I had to expose the PK of certain tables in the interface because the "local" firm apparently doesn't know how to connect to an mdb in order to pull up a combo box in for the staff to choose from. Hence the staff is manually entering the PK to connect the spatial elements to the tabular elements. Wrought with danger is all I can say. I don't think the local firm is working there anymore - so hopefully I get to fix this mess some day }:-p -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby It comes from discussions here on this list where any time you expose the PK to view, some idiot wants to use it for some purpose that it is not supposed to be used for (like a "must be in order, with no values missing" number in an accounting system. Obviously we can and do delete records all the time so using the PK for such a rule / purpose guarantees issues whenever the idiot strikes, thus simply NEVER expose it to view. The PK's function (in real life) is exactly and only for use as a pointer from a child back to the parent. From jwcolby at colbyconsulting.com Wed Jul 25 11:20:03 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 12:20:03 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <013f01c7ced5$1ed88250$6402a8c0@ScuzzPaq> Message-ID: <20070725162016.43DFABD1C@smtp-auth.no-ip.com> Both? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 12:02 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices emotional response? too much caffiene? ... ;o) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Jurgen, Why can't I state it in such reasoned and logical terms? John W. Colby -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 11:41:06 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 09:41:06 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> References: <000301c7ce07$81d373c0$8abea8c0@XPS><006c01c7ce23$22f5cda0$dc34fad1@SusanOne><00f801c7cec6$14e13b20$8abea8c0@XPS> <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> Message-ID: It's usually the approach I use for M to M tables, and the only drawback I can think of is that if you needed a foreign key back to this table, you'd have to use both/all PK fields, not just a single autonumber. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 8:31 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Jim, This is something I haven't seen before and is in my early morning mind, quite brilliant! Are there any drawbacks to doing this? I can't imagine it would be much of a difference (size or performance wise) in any of my applications / databases but it is certainly something worth considering implementing in the future. Always open to technical improvements... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman True, but in the case of a M to M table your just introducing another column and a index that really is not needed. It seems silly to me to have something like: tblLinking LinkID - Autonumber - PK BookID - Long - CK1A AuthorID - Long - CK1B Instead of tblLinking BookID - Long - PK1A AuthorID - Long - PK1B just for the sake of having an auto number in there. The BookID and AuthorID already form a unique pair and they typically would not be used as a foreign key in another table. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Wed Jul 25 11:44:17 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 12:44:17 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725151912.941B1BCEA@smtp-auth.no-ip.com> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: <013601c7cedb$0b91e960$8abea8c0@XPS> John, <> No I don't. A surrogate key is not a primary key in terms of the model. It has no relation to the data what so ever. I agree it's a pointer, but nothing more then that. <> Really? I don't have to have any method of ensuring that each row in a table is unique? <> Yeah, I know you don't as we have been down this road a few times before (something about pig's teats comes to mind). Personally I like to fundamentally understand something as much as possible. It helps me apply things to other areas. <> Because a "primary key" and a "key" don't mean the same things to me. One denotes something that is connected to the data. The other could be anything. As for using a surrogate key, I don't object to them and I use them all the time. But I think it's important to understand that they are a short cut. In this case, the benefits are many and the ramifications few. Does it matter? In a day to day context no. But in understanding how data can be modeled certainly yes. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 11:19 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Jim, >Surrogate keys are nothing more then pointers. Correct!!!!!!!!!!!!!!!!!!!!!!!!!! This is a logical construct Jim. You accept that a PK can be a surrogate, you state that a PK is nothing but a pointer, therefore you accept (and state) that a PK is nothing but a pointer. AND... from the perspective of the child, a FK is nothing but a pointer. Does a table HAVE TO HAVE a PK at all? Not if it has no children. Ergo, what matters from the child's perspective is what the PK is all about, and that is simply a POINTER back to the parent. AND... Since a surrogate key functions as a PK, then... A PK must be nothing but a pointer... > Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. And I don't give a rat's patuty about relational theory, I care about what works. Relational theory says you should normalize to 16 (IIRC) different levels. When was the last time you did that? Do you even UNDERSTAND 9th (or 12th, or 16th) normal form? OK YOU probably do but I don't and don't care that I don't. So day in and day out you (or at least I) ignore relational theory and yet you attempt to flaunt that same theory in the great PK debate for what purpose??? Having the PK change is a no-no. Sorry, it just is. It causes a whole host of issues and given that it doesn't HAVE to change.... >That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. And I don't give a rat's patuty about relational theory, I care about what works. >Surrogates only work in computer systems because we have systems that are reliable. But we do, so what's your point? Natural keys only work (in large systems) because we have systems that are reliable. Imagine trying to manually correct 100 million records where something got corrupted. No easier (without a reliable system). I have NEVER used paper and pencil in a database so who really cares. >To call them a PK in regards to the relational model is simply incorrect. OK, and who cares? I simply do not care about the relational model (in this debate), I care about what works efficiently. I use what works (of the model) and I abandon what is inefficient (natural keys). Natural keys are NOT A REQUIREMENT, you admit that yourself. I still have a PK, it is just a surrogate. If you accept that surrogates do work then why does the insistence in relational model PK being a natural key even matter? You are nitpicking to death stuff that simply does not matter. If you want to insist that the PK HAS TO BE a natural key, then how can you say in the next breath that "I don't object to the use of surrogate keys" C'mon Jim, give it up. I will sign a piece of paper stating whatever you want about PKs and natural keys and relational theory, I simply DO NOT CARE. What I care about is that they are inefficient and cause problems that surrogate keys avoid. Happy? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 25, 2007 10:42 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <<1) The PK should be stable (NEVER changes). >> Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. <> That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. In theory you cannot have a PK without it being a unique index. That's part of the definition of what a natural PK is. Out of the pool of CK's, you would use the CK that is the most stable, shortest in length, and the least complex (simple vs compound). <> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. Surrogate keys work well in computer systems, but the relational model can be applied to much more then computer systems and the PK as you describe it vs what it is in the relational model are not the same thing. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure >dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 cfoust at infostatsystems.com Wed Jul 25 11:42:41 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 09:42:41 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> References: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> Message-ID: Hmmn ... Logical, reasonalbe ... Foaming mouth... I wonder?? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 8:49 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Jurgen, Why can't I state it in such reasoned and logical terms? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 25, 2007 11:39 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Jim: I'm generally with John on this one. The question was about best practices, not relational theory. Every comment you made to John was about relational theory. This is about computer databases; about 'Practices', not 'Theory'. In practice, you can not beat an autonumber for size and speed (performance) in a computer environment. Apply it consistently in conjuction with any other unique indexes on fields or combinations of fields you identify as candidate keys and no user can mess up any more than they possibly could using any other key. None of the 'Theory' comments impact the practical utility and validity of using a unique long or GUID as a primary key. If occasionally you have a key that will likely not be used in a join, at least you retain the flexibilty should the unforseen arise. In terms of additional space wasted for the case where such a key is never used in a join, it is the smallest amout possible for the flexiblity and consistency gained. That sounds like a best practice to me. Regardless of whether anyone agrees with me, it is my practice because it works well. You won't hear from mea again on this topic this year. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.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 Jul 25 11:49:40 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 12:49:40 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: <013701c7cedb$cbd9d980$8abea8c0@XPS> Jurgen, <> Excellent point. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 25, 2007 11:39 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Jim: I'm generally with John on this one. The question was about best practices, not relational theory. Every comment you made to John was about relational theory. This is about computer databases; about 'Practices', not 'Theory'. In practice, you can not beat an autonumber for size and speed (performance) in a computer environment. Apply it consistently in conjuction with any other unique indexes on fields or combinations of fields you identify as candidate keys and no user can mess up any more than they possibly could using any other key. None of the 'Theory' comments impact the practical utility and validity of using a unique long or GUID as a primary key. If occasionally you have a key that will likely not be used in a join, at least you retain the flexibilty should the unforseen arise. In terms of additional space wasted for the case where such a key is never used in a join, it is the smallest amout possible for the flexiblity and consistency gained. That sounds like a best practice to me. Regardless of whether anyone agrees with me, it is my practice because it works well. You won't hear from mea again on this topic this year. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Jim Dettman" > >John, > ><<1) The PK should be stable (NEVER changes). >> > > Don' agree with "never". You want it as stable as possible, but there >is >nothing in relational theory that says it can never change. > ><real life or in theory.>> > > That is simply not true. With relational theory, the PK is derived from >the pool of CK's, which is based on the data. In theory you cannot have a >PK without it being a unique index. That's part of the definition of what >a >natural PK is. Out of the pool of CK's, you would use the CK that is the >most stable, shortest in length, and the least complex (simple vs >compound). > ><surrogate key avoids a whole slew of real life problems, and creates none >(in my experience).>> > > Surrogates only work in computer systems because we have systems that >are >reliable. If I gave you pen and paper and had you keep track of data using >the relational model, you'd be in a pretty big mess fairly quick if you >used >surrogate keys. > > I don't object to the use of surrogate keys, but what I do object to is >the apples and oranges approach you use to claim what a PK is and surrogate >keys fit in the relational model. Surrogate keys are nothing more then >pointers. To call them a PK in regards to the relational model is simply >incorrect. > > Surrogate keys work well in computer systems, but the relational model >can >be applied to much more then computer systems and the PK as you describe it >vs what it is in the relational model are not the same thing. > >Jim. _________________________________________________________________ Fight Allergies With Live Search http://search.live.com/results.aspx?q=Remedies+For+Spring+Allergies&mkt=en-c a&FORM=SERNEP From jimdettman at verizon.net Wed Jul 25 11:51:34 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 12:51:34 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> References: <000301c7ce07$81d373c0$8abea8c0@XPS><006c01c7ce23$22f5cda0$dc34fad1@SusanOne> <00f801c7cec6$14e13b20$8abea8c0@XPS> <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> Message-ID: <013b01c7cedc$0ff09320$8abea8c0@XPS> John, <> I have never found any. I've been forced to do it both ways. Other then to say that there is some additional overhead with the first rather then the second, there is no real difference in terms of outcome. For me, old habits die hard; I still program like I did when my programs needed to run in 64K. As a result, my apps are generally snappier then most. Something like this seems like a no-brainer. In fact, I think doing it the first way actually confuses the design because there is no obvious reason for having it that way. Of course that could just be me. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 11:31 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Jim, This is something I haven't seen before and is in my early morning mind, quite brilliant! Are there any drawbacks to doing this? I can't imagine it would be much of a difference (size or performance wise) in any of my applications / databases but it is certainly something worth considering implementing in the future. Always open to technical improvements... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman True, but in the case of a M to M table your just introducing another column and a index that really is not needed. It seems silly to me to have something like: tblLinking LinkID - Autonumber - PK BookID - Long - CK1A AuthorID - Long - CK1B Instead of tblLinking BookID - Long - PK1A AuthorID - Long - PK1B just for the sake of having an auto number in there. The BookID and AuthorID already form a unique pair and they typically would not be used as a foreign key in another table. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Wed Jul 25 12:12:15 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 25 Jul 2007 13:12:15 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725162016.43DFABD1C@smtp-auth.no-ip.com> References: <013f01c7ced5$1ed88250$6402a8c0@ScuzzPaq> <20070725162016.43DFABD1C@smtp-auth.no-ip.com> Message-ID: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Apparently I have a much different view on this subject than most here. My view has evolved over years in this business, and changed due to increasing complexity of databases. 1. I used to think that ANPKs were the only way to go. Given a dozen or even two dozen tables, it made sense. Given 500 tables plus the low cost of disk space, I no longer agree with that model. As a consequence, I no longer agree that compound PKs are bad that ANPKs are always superior. 2. Any Front End worth its salt can easily pass multiple values to the BE to create a row in some related table. This is not difficult, and if the related table is something so simple as State/Province, containing about 62 rows each of which is uniquely identified by its abbreviation (i.e. SK = Saskatchewan, WY = Wyoming, FL = Florida), then what is gained by storing these as FKs derived from the States/Provinces table? Why not reduce said table to two columns, one being char(2) and the other being varchar(20)? What is gained by this strategy is that a table does not need to be joined in order to obtain the value that interests humans. 3. The aforementioned difficulty cascades to all related tables in the tree. Eventually you find yourself creating surrogate indexes on surrogate indexes in some related table, and it can cascade from there. With 5 or 6 tables, this may not seem an issue, but try 40 tables in a tree and you will get my point. 4. I used to be in the school of ANPKs everywhere but I have since departed, primarily due to the effects created in rich databases (e.g. large databases are a small number of tables with millions of rows; rich databases are a large number of tables with relatively few rows each; it's possible but seldom occurs that a db is both large and rich). In a rich database, I do not have the time to do 20 joins to grab the keys of the related data. I want it NOW, not one minute from now. Correctness of results and speed of retrieval are the most important tests. Disk space, long ago, was the paramount consideration, and caused many of us (including me) to think that ANPKs were the solution. Thanks to a couple of books I read, I have since then shed that illusion. That doesn't mean that I don't like ANPKs. I still love and treasure them. But I have learned that they don't belong in any table where the number of rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the case of a table called State/Provinces, consisting of about 62 rows representing the states in USA and the provinces and territories in Canada. All of these items can be represented uniquely by a two-letter combination. Why on earth would you then introduce an ANPK into this table? It makes NO sense, IMO. It rather exemplifies the ridiculous application of a maxim learned long ago and adhered to since, without further examination. Let's go further. Suppose your firm has 100 products all of which are uniquely identified by three alpha characters. Why would you bother creating an ANPK on said table? IMO it's asinine. You just force me to create joins down the road (as in reporting), while providing me with no real gain in the here and now. You wanna benchmark your index on an ANPK versus mine on a three-letter alpha column? Ok? Let's go. I'll give you half a second maximum, and then let's look at the rewards I get that you don't. After 30 years in the database business, I have only recently come to appreciate the value of compound PKs and PKs that are not necessarily ANPKs. It's taken me a while to realize this, I confess, and I'm sure that many of you will disagree. But having been in the situation of 500 tables some of which have 50 million rows, and 20 joins are required for some query or other, I now understand that ANPKs are stupid in this situation. Far better, and 10 times faster, are meaningful char PKs such as the State/Province example listed above. In a given table, I already have the value "CA" meaning California. I don't need to reference an ANPK to look up this value -- I already have it. This perspective may make sense only to those who work with millions of rows in hundreds of tables. But that pretty much describes where I work. In these circumstances, I would definitely raise red flags wherever ANPKs are introduced in lookup tables, while defending their place in transaction tables. Arthur On 7/25/07, jwcolby wrote: > > Both? > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow > Sent: Wednesday, July 25, 2007 12:02 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Primary Key Best Practices > > emotional response? too much caffiene? ... > ;o) > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > > Jurgen, > > Why can't I state it in such reasoned and logical terms? > > John W. Colby > > -- > 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 jwcolby at colbyconsulting.com Wed Jul 25 12:33:43 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 13:33:43 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <013601c7cedb$0b91e960$8abea8c0@XPS> Message-ID: <20070725173355.613A7BE1C@smtp-auth.no-ip.com> Jim, > No I don't. A surrogate key is not a primary key in terms of the model. But I don't work in the model, I work in the real world. A PK is a PK because the database assigns it the PK symbol, and as such I then use it as a pointer. The PK object in any database system (I use) CAN BE a surrogate so the REAL WORLD accepts that surrogates can be PKs. I don't see you calling up MS and complaining that a PK symbol is assigned to your surrogate PK. It may be called a surrogate key, but in the real world it is called it a surrogate PK. > Really? I don't have to have any method of ensuring that each row in a table is unique? Open SQL Server (or Access). Create a table. Create a unique index on it. You now have NO PK but you do have a unique index, ensuring that each row is unique. So SQL Server at least differentiates between PK and unique index. I know that Access works this way. I suspect that the rest do too. A PK and a unique index are NOT the same thing. You MAY specify that a field is the PK, and as such the database will create a unique index - I acknowledge that it has to do that, but again, the index itself does NOT MAKE the PK, the unique index is a necessary attribute of the PK. Being a PK is not an attribute of a unique index. Let's stop discussing the model. It is not useful, I already signed my life away stating that anything you wish to claim about the model is true, so stop with the model already. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 25, 2007 12:44 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <> No I don't. A surrogate key is not a primary key in terms of the model. It has no relation to the data what so ever. I agree it's a pointer, but nothing more then that. <> Really? I don't have to have any method of ensuring that each row in a table is unique? <> Yeah, I know you don't as we have been down this road a few times before (something about pig's teats comes to mind). Personally I like to fundamentally understand something as much as possible. It helps me apply things to other areas. <> Because a "primary key" and a "key" don't mean the same things to me. One denotes something that is connected to the data. The other could be anything. As for using a surrogate key, I don't object to them and I use them all the time. But I think it's important to understand that they are a short cut. In this case, the benefits are many and the ramifications few. Does it matter? In a day to day context no. But in understanding how data can be modeled certainly yes. Jim. From jwcolby at colbyconsulting.com Wed Jul 25 12:46:29 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 13:46:29 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Message-ID: <20070725174642.69646BE67@smtp-auth.no-ip.com> And you know what Arthur, your logic is flawless. There are a number of cases where there is only a single field in the table and only ever going to be a single field. In those cases I would reluctantly put down my ANPK. IN THOSE cases, the table is really being used as a simple data integrity monitor to force the user to select a valid choice. The two column "with a code" I would not so quickly put down my ANPK. In the case of a product with a 3 char code and a ton of other useful info I absolutely would continue to use an ANPK. The reason is simple, and comes back to join speed. Yea, people MAY memorize all the 3 character codes but just as likely you would be joining your 3 char field to pull more data where I would be joining an integer. But congrats anyway, you have pointed out the (so far) single case where a natural key is as good as an ANPK and causes no further problems. And BTW, disk space is not my primary objection, but rather join speed. No matter whether a lowly PC desktop or a supercomputer, speed is always an issue. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 25, 2007 1:12 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Apparently I have a much different view on this subject than most here. My view has evolved over years in this business, and changed due to increasing complexity of databases. 1. I used to think that ANPKs were the only way to go. Given a dozen or even two dozen tables, it made sense. Given 500 tables plus the low cost of disk space, I no longer agree with that model. As a consequence, I no longer agree that compound PKs are bad that ANPKs are always superior. 2. Any Front End worth its salt can easily pass multiple values to the BE to create a row in some related table. This is not difficult, and if the related table is something so simple as State/Province, containing about 62 rows each of which is uniquely identified by its abbreviation (i.e. SK = Saskatchewan, WY = Wyoming, FL = Florida), then what is gained by storing these as FKs derived from the States/Provinces table? Why not reduce said table to two columns, one being char(2) and the other being varchar(20)? What is gained by this strategy is that a table does not need to be joined in order to obtain the value that interests humans. 3. The aforementioned difficulty cascades to all related tables in the tree. Eventually you find yourself creating surrogate indexes on surrogate indexes in some related table, and it can cascade from there. With 5 or 6 tables, this may not seem an issue, but try 40 tables in a tree and you will get my point. 4. I used to be in the school of ANPKs everywhere but I have since departed, primarily due to the effects created in rich databases (e.g. large databases are a small number of tables with millions of rows; rich databases are a large number of tables with relatively few rows each; it's possible but seldom occurs that a db is both large and rich). In a rich database, I do not have the time to do 20 joins to grab the keys of the related data. I want it NOW, not one minute from now. Correctness of results and speed of retrieval are the most important tests. Disk space, long ago, was the paramount consideration, and caused many of us (including me) to think that ANPKs were the solution. Thanks to a couple of books I read, I have since then shed that illusion. That doesn't mean that I don't like ANPKs. I still love and treasure them. But I have learned that they don't belong in any table where the number of rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the case of a table called State/Provinces, consisting of about 62 rows representing the states in USA and the provinces and territories in Canada. All of these items can be represented uniquely by a two-letter combination. Why on earth would you then introduce an ANPK into this table? It makes NO sense, IMO. It rather exemplifies the ridiculous application of a maxim learned long ago and adhered to since, without further examination. Let's go further. Suppose your firm has 100 products all of which are uniquely identified by three alpha characters. Why would you bother creating an ANPK on said table? IMO it's asinine. You just force me to create joins down the road (as in reporting), while providing me with no real gain in the here and now. You wanna benchmark your index on an ANPK versus mine on a three-letter alpha column? Ok? Let's go. I'll give you half a second maximum, and then let's look at the rewards I get that you don't. After 30 years in the database business, I have only recently come to appreciate the value of compound PKs and PKs that are not necessarily ANPKs. It's taken me a while to realize this, I confess, and I'm sure that many of you will disagree. But having been in the situation of 500 tables some of which have 50 million rows, and 20 joins are required for some query or other, I now understand that ANPKs are stupid in this situation. Far better, and 10 times faster, are meaningful char PKs such as the State/Province example listed above. In a given table, I already have the value "CA" meaning California. I don't need to reference an ANPK to look up this value -- I already have it. This perspective may make sense only to those who work with millions of rows in hundreds of tables. But that pretty much describes where I work. In these circumstances, I would definitely raise red flags wherever ANPKs are introduced in lookup tables, while defending their place in transaction tables. Arthur From john at winhaven.net Wed Jul 25 12:57:47 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 12:57:47 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <013b01c7cedc$0ff09320$8abea8c0@XPS> References: <000301c7ce07$81d373c0$8abea8c0@XPS><006c01c7ce23$22f5cda0$dc34fad1@SusanOne><00f801c7cec6$14e13b20$8abea8c0@XPS><010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> <013b01c7cedc$0ff09320$8abea8c0@XPS> Message-ID: <001f01c7cee5$50decd80$6402a8c0@ScuzzPaq> Well having never thought of this... that may be an indication of my brain capacity! ;o) I would imagine its just a consistency thing, once I start doing something I generally do it consistently unless I have a good reason not to. This seems like a good reason. However, I must await the inevitable drawback which will be pointed out by someone who has thought this through more than I have. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Something like this seems like a no-brainer. In fact, I think doing it the first way actually confuses the design because there is no obvious reason for having it that way. From fuller.artful at gmail.com Wed Jul 25 13:09:52 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 25 Jul 2007 14:09:52 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725174642.69646BE67@smtp-auth.no-ip.com> References: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> <20070725174642.69646BE67@smtp-auth.no-ip.com> Message-ID: <29f585dd0707251109mb8ca6bat9404f3190d0a5f97@mail.gmail.com> Blush! "your logic is flawless." From you, that's truly awesome praise. On 7/25/07, jwcolby wrote: > > And you know what Arthur, your logic is flawless. There are a number of > cases where there is only a single field in the table and only ever going > to > be a single field. In those cases I would reluctantly put down my > ANPK. IN > THOSE cases, the table is really being used as a simple data integrity > monitor to force the user to select a valid choice. The two column "with > a > code" I would not so quickly put down my ANPK. In the case of a product > with a 3 char code and a ton of other useful info I absolutely would > continue to use an ANPK. The reason is simple, and comes back to join > speed. Yea, people MAY memorize all the 3 character codes but just as > likely you would be joining your 3 char field to pull more data where I > would be joining an integer. > > But congrats anyway, you have pointed out the (so far) single case where a > natural key is as good as an ANPK and causes no further problems. > > And BTW, disk space is not my primary objection, but rather join > speed. No > matter whether a lowly PC desktop or a supercomputer, speed is always an > issue. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > From fuller.artful at gmail.com Wed Jul 25 13:57:58 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 25 Jul 2007 14:57:58 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <005101c7ce26$3ec58680$0200a8c0@danwaters> References: <004201c7ce18$79e7cd80$0200a8c0@danwaters> <0JLP007V75EOGYZ0@vms046.mailsrvcs.net> <005101c7ce26$3ec58680$0200a8c0@danwaters> Message-ID: <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> IN() forces a table scan. There's a much hipper way to do this. Given some arbitrary front end that asks you for values and you supply 1, 307, 590, and 12 (which correspond to PKs or FKs of interest), then write these values to a temp table and then do a join to the real table of interest. Even assuming 100 user-supplied values, resulting in 100 rows in the temp table, this is WAY faster than any other known method. Compared to IN(), against a large number of rows, there is no comparison. IN() forces a table scan. The parser is not smart enough to create a temp table of the values supplied, and therefore cannot use the index to find the rows. Instead it walks the entire table. Create the temp table as described above, then do a join to the real table of interest and boink! You've got your rows WAY more quickly than in the other methods. hth, Arthur On 7/24/07, Dan Waters wrote: > > Perhaps this will bypass the limit altogether! > > Thanks Eric! > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro > Sent: Tuesday, July 24, 2007 1:45 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with Ors > tend > to take longer to execute. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 10:32 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > That's a good plan! I was hoping to do a customer update within the next > half hour though. > > I was hoping that someone had seen some documentation on this. The number > 40 was documented 'somewhere' in Access help. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Tuesday, July 24, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > You could reasonably quickly set up a test to find out by building a > dynamic > query, a string such as select PKID from tblX where (PKID=1 or PKID=2 > or...). Add 10 (or 100) at a time and see how far you get. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 1:02 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Number of 'OR's in queries - what's the limit? > > In Access 97, there was a limit of 40 OR words in a query. There is a > limit > in Access 2003, it's >250, but I don't know what it actually is. > > Does anyone know? > > Thanks! > Dan > > > > -- > 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 > 7:45 PM > > > -- > 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 jwcolby at colbyconsulting.com Wed Jul 25 14:13:12 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 15:13:12 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> Message-ID: <20070725191324.A7753BC78@smtp-auth.no-ip.com> Do you need to create an index on the field in the temp table? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 25, 2007 2:58 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? IN() forces a table scan. There's a much hipper way to do this. Given some arbitrary front end that asks you for values and you supply 1, 307, 590, and 12 (which correspond to PKs or FKs of interest), then write these values to a temp table and then do a join to the real table of interest. Even assuming 100 user-supplied values, resulting in 100 rows in the temp table, this is WAY faster than any other known method. Compared to IN(), against a large number of rows, there is no comparison. IN() forces a table scan. The parser is not smart enough to create a temp table of the values supplied, and therefore cannot use the index to find the rows. Instead it walks the entire table. Create the temp table as described above, then do a join to the real table of interest and boink! You've got your rows WAY more quickly than in the other methods. hth, Arthur On 7/24/07, Dan Waters wrote: > > Perhaps this will bypass the limit altogether! > > Thanks Eric! > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro > Sent: Tuesday, July 24, 2007 1:45 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with > Ors tend to take longer to execute. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 10:32 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > That's a good plan! I was hoping to do a customer update within the > next half hour though. > > I was hoping that someone had seen some documentation on this. The > number 40 was documented 'somewhere' in Access help. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Tuesday, July 24, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > You could reasonably quickly set up a test to find out by building a > dynamic query, a string such as select PKID from tblX where (PKID=1 or > PKID=2 or...). Add 10 (or 100) at a time and see how far you get. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 1:02 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Number of 'OR's in queries - what's the limit? > > In Access 97, there was a limit of 40 OR words in a query. There is a > limit in Access 2003, it's >250, but I don't know what it actually is. > > Does anyone know? > > Thanks! > Dan > > > > -- > 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: > 7/23/2007 > 7:45 PM > > > -- > 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 robert at webedb.com Wed Jul 25 14:31:19 2007 From: robert at webedb.com (Robert L. Stewart) Date: Wed, 25 Jul 2007 14:31:19 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <200707251936.l6PJarGv004472@databaseadvisors.com> At 12:00 PM 7/25/2007, you wrote: >Date: Wed, 25 Jul 2007 11:19:00 -0400 >From: "jwcolby" >Subject: Re: [AccessD] Primary Key Best Practices >To: "'Access Developers discussion and problem solving'" > >Message-ID: <20070725151912.941B1BCEA at smtp-auth.no-ip.com> >Content-Type: text/plain; charset="us-ascii" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. Ergo, >what matters from the child's perspective is what the PK is all about, and >that is simply a POINTER back to the parent. AND... Since a surrogate key >functions as a PK, then... A PK must be nothing but a pointer... From john at winhaven.net Wed Jul 25 15:27:19 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 15:27:19 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707251936.l6PJarGv004472@databaseadvisors.com> References: <200707251936.l6PJarGv004472@databaseadvisors.com> Message-ID: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> Good point. And one I glossed over while postulating my responses. I can't remember ever having a table without a PK in any RDBMS. I can't even imagine what data would be stored in an RDBMS that didn't need a PK. This is what is so befuddling to me when it comes to Outlook's contacts... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Wednesday, July 25, 2007 2:31 PM At 12:00 PM 7/25/2007, you wrote: >From: "jwcolby" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. >Ergo, what matters from the child's perspective is what the PK is all >about, and that is simply a POINTER back to the parent. AND... Since a >surrogate key functions as a PK, then... A PK must be nothing but a pointer... From dwaters at usinternet.com Wed Jul 25 15:30:01 2007 From: dwaters at usinternet.com (Dan Waters) Date: Wed, 25 Jul 2007 15:30:01 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> References: <004201c7ce18$79e7cd80$0200a8c0@danwaters><0JLP007V75EOGYZ0@vms046.mailsrvcs.net><005101c7ce26$3ec58680$0200a8c0@danwaters> <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> Message-ID: <002701c7cefa$93e14b70$0200a8c0@danwaters> Hi Arthur, I am using this method to define a query that will be used as the recordsource for a form, and the records must be updateable. Yesterday when I used this, 484 records were included, it was very fast, and the records are updateable. The table currently has about 1000 records, and will top out at roughly 10,000. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 25, 2007 1:58 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? IN() forces a table scan. There's a much hipper way to do this. Given some arbitrary front end that asks you for values and you supply 1, 307, 590, and 12 (which correspond to PKs or FKs of interest), then write these values to a temp table and then do a join to the real table of interest. Even assuming 100 user-supplied values, resulting in 100 rows in the temp table, this is WAY faster than any other known method. Compared to IN(), against a large number of rows, there is no comparison. IN() forces a table scan. The parser is not smart enough to create a temp table of the values supplied, and therefore cannot use the index to find the rows. Instead it walks the entire table. Create the temp table as described above, then do a join to the real table of interest and boink! You've got your rows WAY more quickly than in the other methods. hth, Arthur On 7/24/07, Dan Waters wrote: > > Perhaps this will bypass the limit altogether! > > Thanks Eric! > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro > Sent: Tuesday, July 24, 2007 1:45 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with Ors > tend > to take longer to execute. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 10:32 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > That's a good plan! I was hoping to do a customer update within the next > half hour though. > > I was hoping that someone had seen some documentation on this. The number > 40 was documented 'somewhere' in Access help. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Tuesday, July 24, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > You could reasonably quickly set up a test to find out by building a > dynamic > query, a string such as select PKID from tblX where (PKID=1 or PKID=2 > or...). Add 10 (or 100) at a time and see how far you get. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 1:02 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Number of 'OR's in queries - what's the limit? > > In Access 97, there was a limit of 40 OR words in a query. There is a > limit > in Access 2003, it's >250, but I don't know what it actually is. > > Does anyone know? > > Thanks! > Dan > > > > -- > 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 > 7:45 PM > > > -- > 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 Wed Jul 25 15:56:52 2007 From: ssharkins at gmail.com (Susan Harkins) Date: Wed, 25 Jul 2007 16:56:52 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> References: <200707251936.l6PJarGv004472@databaseadvisors.com> <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> Message-ID: <002001c7cefe$5bc746f0$5cb62ad1@SusanOne> This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? Susan H. From jwelz at hotmail.com Wed Jul 25 16:05:23 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Wed, 25 Jul 2007 15:05:23 -0600 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Message-ID: Arthur: Interesting comments as performance has always been an issue for me. In recognition of some of those concerns I evolved an approach that oviates some of your concerns, but it is hardly a common approach. In the case of displaying State/Province in a form or report, I've always set the primary record source to the parent table record and used a combo bound to the province key to display the province. This is the approach I use for virtually all lookup tables. I even occasionally use a value list row source (gasp!) that is simply a way to limit and validate data that I can't bother to store in a two record table. In the case of forms or reports using province or similar data, no fancy query or join processing (assuming client/server) is required and the join is functionally performed at the combo. Going beyond this, for nearly all smaller lookup tables (up to a couple thousand records), I've found it expedient to pull the common combo data one time with a recordset and getrows and fill the combos with callbacks. For static tables like province, this is pulled on demand the first time required. For semi-static data, i check a single record date time stamp that indicates the last edit/add to a lookup table. If the time stamp is after my last data load, I refresh the array. I don't really see the utilty of displaying 'AL, AK, AB, AZ or AR' in a user's view of the data. My preference is to display the combo with all the information. Rather than placing an edit button by the field to pop a list of choices or allowing a user to enter anything they want and then run a validation routine, a combo keeps a browseable list ready to hand. By using combos for one record to one lookup joins and subforms for one record to many record joins, and in certain cases, listboxes for one to many joins, complex query sources for forms and reports are exceedingly rare. With a just in time approach for subforms and lists, selecting on a numeric PK continues to make sense. My current 47 user database reports 191 tables and performance remains snappy. Since the original question is regarding best practices and what I do is not for everyone, I can see where you have some useful insights. It would be interesting to know what the impact is of one approach over the other in a client/server environment as opposed to a file/server environment. Since I am in a mdb only environment, allowing the form controls to process the joins limiting data requests to the absolute minimum traffic by caching lookup data made the most sense to me. I had benchmarked a few approaches to filling some of my more complex forms using a couple of different data designs and I know that AN PKs remain the only game in town for me. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Arthur Fuller" > >Apparently I have a much different view on this subject than most here. My >view has evolved over years in this business, and changed due to increasing >complexity of databases. > >1. I used to think that ANPKs were the only way to go. Given a dozen or >even >two dozen tables, it made sense. Given 500 tables plus the low cost of disk >space, I no longer agree with that model. As a consequence, I no longer >agree that compound PKs are bad that ANPKs are always superior. > >2. Any Front End worth its salt can easily pass multiple values to the BE >to >create a row in some related table. This is not difficult, and if the >related table is something so simple as State/Province, containing about 62 >rows each of which is uniquely identified by its abbreviation (i.e. SK = >Saskatchewan, WY = Wyoming, FL = Florida), then what is gained by storing >these as FKs derived from the States/Provinces table? Why not reduce said >table to two columns, one being char(2) and the other being varchar(20)? >What is gained by this strategy is that a table does not need to be joined >in order to obtain the value that interests humans. > >3. The aforementioned difficulty cascades to all related tables in the >tree. >Eventually you find yourself creating surrogate indexes on surrogate >indexes >in some related table, and it can cascade from there. With 5 or 6 tables, >this may not seem an issue, but try 40 tables in a tree and you will get my >point. > >4. I used to be in the school of ANPKs everywhere but I have since >departed, >primarily due to the effects created in rich databases (e.g. large >databases >are a small number of tables with millions of rows; rich databases are a >large number of tables with relatively few rows each; it's possible but >seldom occurs that a db is both large and rich). In a rich database, I do >not have the time to do 20 joins to grab the keys of the related data. I >want it NOW, not one minute from now. Correctness of results and speed of >retrieval are the most important tests. Disk space, long ago, was the >paramount consideration, and caused many of us (including me) to think that >ANPKs were the solution. > >Thanks to a couple of books I read, I have since then shed that illusion. >That doesn't mean that I don't like ANPKs. I still love and treasure them. >But I have learned that they don't belong in any table where the number of >rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the >case >of a table called State/Provinces, consisting of about 62 rows representing >the states in USA and the provinces and territories in Canada. All of these >items can be represented uniquely by a two-letter combination. Why on earth >would you then introduce an ANPK into this table? It makes NO sense, IMO. >It >rather exemplifies the ridiculous application of a maxim learned long ago >and adhered to since, without further examination. > >Let's go further. Suppose your firm has 100 products all of which are >uniquely identified by three alpha characters. Why would you bother >creating >an ANPK on said table? IMO it's asinine. You just force me to create joins >down the road (as in reporting), while providing me with no real gain in >the >here and now. You wanna benchmark your index on an ANPK versus mine on a >three-letter alpha column? Ok? Let's go. I'll give you half a second >maximum, and then let's look at the rewards I get that you don't. > >After 30 years in the database business, I have only recently come to >appreciate the value of compound PKs and PKs that are not necessarily >ANPKs. >It's taken me a while to realize this, I confess, and I'm sure that many of >you will disagree. But having been in the situation of 500 tables some of >which have 50 million rows, and 20 joins are required for some query or >other, I now understand that ANPKs are stupid in this situation. Far >better, >and 10 times faster, are meaningful char PKs such as the State/Province >example listed above. In a given table, I already have the value "CA" >meaning California. I don't need to reference an ANPK to look up this value >-- I already have it. > >This perspective may make sense only to those who work with millions of >rows >in hundreds of tables. But that pretty much describes where I work. In >these >circumstances, I would definitely raise red flags wherever ANPKs are >introduced in lookup tables, while defending their place in transaction >tables. > >Arthur _________________________________________________________________ http://liveearth.msn.com From Lambert.Heenan at AIG.com Wed Jul 25 16:10:23 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Wed, 25 Jul 2007 17:10:23 -0400 Subject: [AccessD] Primary Key Best Practices Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> Well, just like a MailItem, a ContactItem has a property called "EntryID" which is of type String. For MailItems this looks like some kind of GUID... 00000000AF9B53E7CCFAD01199D500805FD4C8DA07001D7828CDB8350747AFE9D69E0E90DA1F 00001D15892D000034C8A2AB1EF3564CB0D64DB6AFFDD5C2000009BA2DB10000 And though I have not checked this out, I suspect the EntryID of a ContactItem is of the same form. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 4:57 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 16:43:13 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 14:43:13 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> Message-ID: LOL Not something you'd want to have to remember or type in!! Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Wednesday, July 25, 2007 2:10 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Well, just like a MailItem, a ContactItem has a property called "EntryID" which is of type String. For MailItems this looks like some kind of GUID... 00000000AF9B53E7CCFAD01199D500805FD4C8DA07001D7828CDB8350747AFE9D69E0E90 DA1F 00001D15892D000034C8A2AB1EF3564CB0D64DB6AFFDD5C2000009BA2DB10000 And though I have not checked this out, I suspect the EntryID of a ContactItem is of the same form. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 4:57 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? 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 jwcolby at colbyconsulting.com Wed Jul 25 16:45:54 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 17:45:54 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707251936.l6PJarGv004472@databaseadvisors.com> Message-ID: <20070725214607.338EEBE3C@smtp-auth.no-ip.com> >Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. True, but it does NOT require one for the table to exist in SQL Server. I am simply making a point that the PK is not the unique index. The PK HAS ONE unique index, and it has to have a unique index to be labeled as the PK (by the database engine) but it is NOT JUST A UNIQUE INDEX, it is a pointer to a record that, oh by the way, happens to have a unique index. You can create a table in SQL Server and not label any field or combinations of fields as the PK inside of SQL Server. Make that field an auto increment. DO NOT place a unique index on it. Create 1 million records. Now go link that table to Access and TELL ACCESS that the autonumber field is the PK. Now you can do the deletes and updates. IT IS JUST A POINTER. It does NOT have a unique index in SQL Server, and it is not LABELED as the PK in SQL Server. But the field still (correctly) points to a single record back in SQL Server and can be used to find and delete a record. Now, go into that table in SQL Server and assign some natural key as the PK. Go back to Access. Even though you have not told ACCESS that the natural key is the PK, you can STILL delete a specific record out in SQL Server using the original autonumber. The field is JUST A POINTER. Now go into SQL Server and find a second (and third and fourth) CANDIDATE KEYS and create unique indexes on them. You haven't in any fashion made those candidate keys the PK, all you have done is set up a new unique index. Call it what you want, I don't care. A unique index is NOT a PK and a PK is NOT a unique index. Different things entirely. The FIELD or FIELDS that have a unique index applied to them may be chosen as the PK, but the index itself is NOT THE PK, and the PK IS NOT THE UNIQUE INDEX. The field itself (with or without an index) is the PK, and the contents of the field are used for the lookup to find the matching records in other tables. The unique index does nothing more or less than enforce uniqueness, which of course is a requirement of the CONTENTS of the field(s) that make up the PK, and the unique index is thus FORCED to exist by the database engine (correctly so). Now quote the model all you want, as I said, the model is not of interest to me, reality is of interest to me. Models do exactly that, MODEL REALITY, they are not the complete representation of reality. If they were they would cease to be a model and become the real thing. The model is interesting but it is not complete, and it is being very effectively used to obscure the issues in this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Wednesday, July 25, 2007 3:31 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices At 12:00 PM 7/25/2007, you wrote: >Date: Wed, 25 Jul 2007 11:19:00 -0400 >From: "jwcolby" >Subject: Re: [AccessD] Primary Key Best Practices >To: "'Access Developers discussion and problem solving'" > >Message-ID: <20070725151912.941B1BCEA at smtp-auth.no-ip.com> >Content-Type: text/plain; charset="us-ascii" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. >Ergo, what matters from the child's perspective is what the PK is all >about, and that is simply a POINTER back to the parent. AND... Since a >surrogate key functions as a PK, then... A PK must be nothing but a pointer... -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 16:46:41 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 17:46:41 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> Message-ID: <20070725214654.07370BE08@smtp-auth.no-ip.com> Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 4:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Good point. And one I glossed over while postulating my responses. I can't remember ever having a table without a PK in any RDBMS. I can't even imagine what data would be stored in an RDBMS that didn't need a PK. This is what is so befuddling to me when it comes to Outlook's contacts... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Wednesday, July 25, 2007 2:31 PM At 12:00 PM 7/25/2007, you wrote: >From: "jwcolby" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. >Ergo, what matters from the child's perspective is what the PK is all >about, and that is simply a POINTER back to the parent. AND... Since a >surrogate key functions as a PK, then... A PK must be nothing but a pointer... -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 16:50:15 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 14:50:15 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725214654.07370BE08@smtp-auth.no-ip.com> References: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> <20070725214654.07370BE08@smtp-auth.no-ip.com> Message-ID: You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 4:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Good point. And one I glossed over while postulating my responses. I can't remember ever having a table without a PK in any RDBMS. I can't even imagine what data would be stored in an RDBMS that didn't need a PK. This is what is so befuddling to me when it comes to Outlook's contacts... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Wednesday, July 25, 2007 2:31 PM At 12:00 PM 7/25/2007, you wrote: >From: "jwcolby" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. >Ergo, what matters from the child's perspective is what the PK is all >about, and that is simply a POINTER back to the parent. AND... Since a >surrogate key functions as a PK, then... A PK must be nothing but a pointer... -- 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 john at winhaven.net Wed Jul 25 17:26:44 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 17:26:44 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725214654.07370BE08@smtp-auth.no-ip.com> References: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> <20070725214654.07370BE08@smtp-auth.no-ip.com> Message-ID: <009201c7cf0a$e25e6c50$6402a8c0@ScuzzPaq> OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. From stuart at lexacorp.com.pg Wed Jul 25 18:26:56 2007 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Thu, 26 Jul 2007 09:26:56 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> References: <013f01c7ced5$1ed88250$6402a8c0@ScuzzPaq>, <20070725162016.43DFABD1C@smtp-auth.no-ip.com>, <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Message-ID: <46A7DC40.5047.433D1810@stuart.lexacorp.com.pg> On 25 Jul 2007 at 13:12, Arthur Fuller wrote: > rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the case > of a table called State/Provinces, consisting of about 62 rows representing > the states in USA and the provinces and territories in Canada. All of these > items can be represented uniquely by a two-letter combination. Why on earth > would you then introduce an ANPK into this table? It makes NO sense, IMO. It > rather exemplifies the ridiculous application of a maxim learned long ago > and adhered to since, without further examination. > Now imagine that your system expands and you need to another country in addition to US and Canada - what happens when another country has the same 2 letter abbreviation for one of their states/provinces? > Let's go further. Suppose your firm has 100 products all of which are > uniquely identified by three alpha characters. Why would you bother creating > an ANPK on said table? IMO it's asinine. You just force me to create joins > down the road (as in reporting), while providing me with no real gain in the > here and now. You wanna benchmark your index on an ANPK versus mine on a > three-letter alpha column? Ok? Let's go. I'll give you half a second > maximum, and then let's look at the rewards I get that you don't. > Been there, done that - after a few years, they merged with another firm and the codes had to be changed. Hell of a job to rebuild all the relationships. From ssharkins at gmail.com Wed Jul 25 18:56:09 2007 From: ssharkins at gmail.com (Susan Harkins) Date: Wed, 25 Jul 2007 19:56:09 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> Message-ID: <003e01c7cf17$6467a520$5cb62ad1@SusanOne> That's what I thought. Susan H. Well, just like a MailItem, a ContactItem has a property called "EntryID" which is of type String. For MailItems this looks like some kind of GUID... 00000000AF9B53E7CCFAD01199D500805FD4C8DA07001D7828CDB8350747AFE9D69E0E90DA1F 00001D15892D000034C8A2AB1EF3564CB0D64DB6AFFDD5C2000009BA2DB10000 And though I have not checked this out, I suspect the EntryID of a ContactItem is of the same form. From jwcolby at colbyconsulting.com Wed Jul 25 18:56:29 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 19:56:29 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070725235642.967DABC8F@smtp-auth.no-ip.com> Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com From jwcolby at colbyconsulting.com Wed Jul 25 18:57:01 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 19:57:01 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <009201c7cf0a$e25e6c50$6402a8c0@ScuzzPaq> Message-ID: <20070725235713.D6BA1BC8F@smtp-auth.no-ip.com> There are lots of tables that do not require a PK. Any table without children. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 6:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 19:31:36 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 20:31:36 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <009201c7cf0a$e25e6c50$6402a8c0@ScuzzPaq> Message-ID: <20070726003148.F107EBCA2@smtp-auth.no-ip.com> >Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Of course not, it would not be a relational db if there was not a child table. >Have you ever created a table that didn't have a PK? (when you were done creating it). Yes, but not often. I almost always add the ANPK whether or not I need one. But any table with no children does not require a PK in order to exist and contain data. In order to select it for editing / deletion is another story but it still does not have to contain a field, marked by the database as being a PK, nor does it have to have a unique index on it. ANY field(s) with unique data (candidate key) can be used in a where clause to pull a specific record or set of records for editing or deletion, and it does NOT have to be marked as the PK to do so. We all know what candidate keys are. They are a field or set of fields which taken together CURRENTLY contains data that is unique within that set of fields in that table. We all know that we can take any candidate key and use it as a FK in a child table. It is not marked in the parent as the PK, but the fact that (the data in) it is unique allows us to use that as the FK in the child table. So in fact by this example we can have a table FULL OF candidate keys DOZENS OF THEM if we can discover that many candidate keys. We can intentionally not designate any one of them as the PK, yet in fact we can use any valid candidate key as the FK (pointer back to the parent) in a child table. You can demonstrate that for yourself simply by doing a join on two such tables, or even by building a where clause on such candidate key. The FUNCTIONALITY of the PK is obtained even though no PK is specified in the parent table. That is why it is important to not get hung up on the model! A PK is an artificial construct from the get go. It is a useful construct but is not required to do many of the things that some people here on the list believe it is required for. Given that it is an artificial construct, and given that a surrogate ANPK can be substituted at the drop of a hat for a natural PK, and given that the ANPK solves many problems that are created by a natural PK, I choose in almost every case to use one. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 6:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 20:19:10 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 18:19:10 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725235642.967DABC8F@smtp-auth.no-ip.com> References: <20070725235642.967DABC8F@smtp-auth.no-ip.com> Message-ID: That's cheating, John. From an interface, you need a PK. Why bother to be a stickler about anything if you're going to play directly in the tables? Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 20:54:00 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 21:54:00 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726015413.0FBA8BCF1@smtp-auth.no-ip.com> >That's cheating, John. From an interface, you need a PK. I think you should look at your definition of a PK. I have already demonstrated that even from Access you do NOT have to have a PK. You have to have a candidate key, and you have to lie to Access and TELL ACCESS that some candidate key is the PK, but in fact it doesn't really have to be the PK of the SQL Server table. >Why bother to be a stickler about anything if you're going to play directly in the tables? I do a lot of "playing" directly in the tables. There are TONS of scenarios where direct fiddling in the tables is required - usually by various queries directly manipulating data. Have you not been reading about my application where I do all of this stuff in these huge tables and NEVER look at the data directly. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 9:19 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices That's cheating, John. From an interface, you need a PK. Why bother to be a stickler about anything if you're going to play directly in the tables? Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 developer at ultradnt.com Wed Jul 25 21:37:54 2007 From: developer at ultradnt.com (Steve Conklin) Date: Wed, 25 Jul 2007 22:37:54 -0400 Subject: [AccessD] check for file in ftp site In-Reply-To: References: Message-ID: <007601c7cf2d$fb5e55d0$0200a8c0@ULTRADNT> I don't necessarily want your file, but would rather see here a discussion of technique and maybe a couple lines of the most relevant code. I think more of us benefit that way. There are so many ways to do this - Are you using an API? A 3rd party client? Generating a script to use with the built-in FTP.exe (which is what I normally do) ? Tia, Steve -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Tuesday, July 24, 2007 11:25 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] check for file in ftp site Hello All, I am more than happy to send almost anything to almost anyone...but as we are getting back into some of our Netiquette Practices...please send any other "Me Too"'s to me directly...to lessen the List traffic. Thanks, Mark A. Matte P.S...Doug, I sent you a copy already...good luck...its just an ugly scrapped together example. >From: "Doug Barnes" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] check for file in ftp site >Date: Tue, 24 Jul 2007 10:49:10 -0400 > >Would love to see a copy, as well > > >Douglas Barnes > >Starn Technical Services >P.O. Box 1172 >15957 Conneaut Lake Road, Suite 7 >Meadville, PA 16335 > >doug at starntech.com >P: 814.724.1045 >F: 814.337.3460 > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte >Sent: Monday, July 23, 2007 4:25 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] check for file in ftp site > > >Sending You a zip file offline. > > > >From: "Reuben Cummings" > >Reply-To: Access Developers discussion and problem > >solving > >To: "AccessD" > >Subject: [AccessD] check for file in ftp site > >Date: Mon, 23 Jul 2007 15:35:56 -0400 > > > >I am wanting to log into an ftp site, look thru all the txt files (only >txt > >files), and download all files that are new since the last check. > > > >The files are all numbered sequentially so I can parse out the numbers to > >determine what files are new. > > > >However, I could use some assistance in looping thru the txt file names. > > > >Thanks. > > > >Reuben Cummings > >GFC, LLC > >812.523.1017 > > > > > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.com > >_________________________________________________________________ >http://newlivehotmail.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 _________________________________________________________________ Need a brain boost? Recharge with a stimulating game. Play now! http://club.live.com/home.aspx?icid=club_hotmailtextlink1 From DWUTKA at Marlow.com Wed Jul 25 21:55:19 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Wed, 25 Jul 2007 21:55:19 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Message-ID: >From a bound front end, absolutely agree. There's no reason to have autonumbers in a lookup table... Until you go unbound. When dealing with a lookup table, there's no point in creating data integrity logic to deal with multiple people changing the same record. In a lot of cases, the change may be the same thing, but if the system thinks the pk is 'FL', and one person changes it to FLA, when another tries to change another field in the same record...you get jumbled. In a bound front end, not a problem, Access is going to lock the records for you. In an unbound solution, an autonumber primary key also fixes the problem. This is not to say that the key is used as a foreign key in other tables, it is strictly to maintain a unique id for a record. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 25, 2007 12:12 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Apparently I have a much different view on this subject than most here. My view has evolved over years in this business, and changed due to increasing complexity of databases. 1. I used to think that ANPKs were the only way to go. Given a dozen or even two dozen tables, it made sense. Given 500 tables plus the low cost of disk space, I no longer agree with that model. As a consequence, I no longer agree that compound PKs are bad that ANPKs are always superior. 2. Any Front End worth its salt can easily pass multiple values to the BE to create a row in some related table. This is not difficult, and if the related table is something so simple as State/Province, containing about 62 rows each of which is uniquely identified by its abbreviation (i.e. SK = Saskatchewan, WY = Wyoming, FL = Florida), then what is gained by storing these as FKs derived from the States/Provinces table? Why not reduce said table to two columns, one being char(2) and the other being varchar(20)? What is gained by this strategy is that a table does not need to be joined in order to obtain the value that interests humans. 3. The aforementioned difficulty cascades to all related tables in the tree. Eventually you find yourself creating surrogate indexes on surrogate indexes in some related table, and it can cascade from there. With 5 or 6 tables, this may not seem an issue, but try 40 tables in a tree and you will get my point. 4. I used to be in the school of ANPKs everywhere but I have since departed, primarily due to the effects created in rich databases (e.g. large databases are a small number of tables with millions of rows; rich databases are a large number of tables with relatively few rows each; it's possible but seldom occurs that a db is both large and rich). In a rich database, I do not have the time to do 20 joins to grab the keys of the related data. I want it NOW, not one minute from now. Correctness of results and speed of retrieval are the most important tests. Disk space, long ago, was the paramount consideration, and caused many of us (including me) to think that ANPKs were the solution. Thanks to a couple of books I read, I have since then shed that illusion. That doesn't mean that I don't like ANPKs. I still love and treasure them. But I have learned that they don't belong in any table where the number of rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the case of a table called State/Provinces, consisting of about 62 rows representing the states in USA and the provinces and territories in Canada. All of these items can be represented uniquely by a two-letter combination. Why on earth would you then introduce an ANPK into this table? It makes NO sense, IMO. It rather exemplifies the ridiculous application of a maxim learned long ago and adhered to since, without further examination. Let's go further. Suppose your firm has 100 products all of which are uniquely identified by three alpha characters. Why would you bother creating an ANPK on said table? IMO it's asinine. You just force me to create joins down the road (as in reporting), while providing me with no real gain in the here and now. You wanna benchmark your index on an ANPK versus mine on a three-letter alpha column? Ok? Let's go. I'll give you half a second maximum, and then let's look at the rewards I get that you don't. After 30 years in the database business, I have only recently come to appreciate the value of compound PKs and PKs that are not necessarily ANPKs. It's taken me a while to realize this, I confess, and I'm sure that many of you will disagree. But having been in the situation of 500 tables some of which have 50 million rows, and 20 joins are required for some query or other, I now understand that ANPKs are stupid in this situation. Far better, and 10 times faster, are meaningful char PKs such as the State/Province example listed above. In a given table, I already have the value "CA" meaning California. I don't need to reference an ANPK to look up this value -- I already have it. This perspective may make sense only to those who work with millions of rows in hundreds of tables. But that pretty much describes where I work. In these circumstances, I would definitely raise red flags wherever ANPKs are introduced in lookup tables, while defending their place in transaction tables. Arthur The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Wed Jul 25 22:01:05 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Wed, 25 Jul 2007 22:01:05 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <014301c7ced6$57f9a450$6402a8c0@ScuzzPaq> Message-ID: I have exposed an ANPK, in fact, the system I'm working on at the moment exposes it for the main table. It's a help desk system, and the Request table ID field, "TicketNumber" is an AutoNumber, the primary key, and is what the user sees as their 'ticket number'. As far as the concern of someone saying they have to be sequential...they are sequential. The interface provides NO way to delete a request. In fact, I find I build VERY few systems where I ever delete data. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 11:11 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices LOL! I actually have the same view on PK but have recently had to expose PKs in an application for a client. (Well, I suppose I could have told them NO but then I'd probably not still be working for them.) They implemented a new functionality in their GIS system. Instead of paying me to implement it correctly, they tried to have "local" firm implement the GIS (spatial) portion and retain me to do the "tabular" portion. (The whole thing is ridiculous but when you do government work you come to expect this.) Anyway, I had to expose the PK of certain tables in the interface because the "local" firm apparently doesn't know how to connect to an mdb in order to pull up a combo box in for the staff to choose from. Hence the staff is manually entering the PK to connect the spatial elements to the tabular elements. Wrought with danger is all I can say. I don't think the local firm is working there anymore - so hopefully I get to fix this mess some day }:-p -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby It comes from discussions here on this list where any time you expose the PK to view, some idiot wants to use it for some purpose that it is not supposed to be used for (like a "must be in order, with no values missing" number in an accounting system. Obviously we can and do delete records all the time so using the PK for such a rule / purpose guarantees issues whenever the idiot strikes, thus simply NEVER expose it to view. The PK's function (in real life) is exactly and only for use as a pointer from a child back to the parent. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Wed Jul 25 22:03:14 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Wed, 25 Jul 2007 22:03:14 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <002001c7cefe$5bc746f0$5cb62ad1@SusanOne> Message-ID: Not sure what he was getting at either, they do have id's, they just aren't exposed. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 3:57 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From john at winhaven.net Thu Jul 26 02:43:43 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 02:43:43 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <002001c7cefe$5bc746f0$5cb62ad1@SusanOne> Message-ID: <014301c7cf58$b1f62a00$6402a8c0@ScuzzPaq> They are not easy to work with. Depending on how you access them (CDO, VBA, MAPI) you get a different result. It seems easier to query by every field in the record than by the EntryID. Querying based on PKs is easy. Querying based on EntryIDs is a PITA. If I fill a combo box with EntryID and Fullname, then select a record based on that combo box I'd think it would be easiest to draw any other data fields info from Outlook using the EntryID as the criteria for queries. I'm not seeing it. To use the GetItemFromID method to retrieve data you first have to find the StoreID which is the ID of the folder containing the Contact (or whatever). So you find the item you want and work backward to find the container ID and then go forward again to find the data for the item. I'm at the point where I'm thinking I must have missed something critical. The methods I'm using to do this is no way to work with data. But - I was warned about it here so... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Wednesday, July 25, 2007 10:03 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Not sure what he was getting at either, they do have id's, they just aren't exposed. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 3:57 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? From jimdettman at verizon.net Thu Jul 26 06:28:19 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 26 Jul 2007 07:28:19 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725235642.967DABC8F@smtp-auth.no-ip.com> References: <20070725235642.967DABC8F@smtp-auth.no-ip.com> Message-ID: <00cd01c7cf78$11c31050$8abea8c0@XPS> <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Thu Jul 26 06:33:07 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 26 Jul 2007 07:33:07 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070726003148.F107EBCA2@smtp-auth.no-ip.com> References: <009201c7cf0a$e25e6c50$6402a8c0@ScuzzPaq> <20070726003148.F107EBCA2@smtp-auth.no-ip.com> Message-ID: <00d101c7cf78$bd18e920$8abea8c0@XPS> John, <<>Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Of course not, it would not be a relational db if there was not a child table.>> That is not correct. A "relation" does not refer to the relationship between two tables, it refers to the tables themselves. When designing a relational system, before you can start the normalization process with 1NF, you have to form the relations using the following rules: The relation 1. Describes one entity. 2. Has no duplicate rows; hence there is always a primary key. 3. Columns are unordered. 4. Rows are unordered. Most definitely yes a single table is relational. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 8:32 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Of course not, it would not be a relational db if there was not a child table. >Have you ever created a table that didn't have a PK? (when you were done creating it). Yes, but not often. I almost always add the ANPK whether or not I need one. But any table with no children does not require a PK in order to exist and contain data. In order to select it for editing / deletion is another story but it still does not have to contain a field, marked by the database as being a PK, nor does it have to have a unique index on it. ANY field(s) with unique data (candidate key) can be used in a where clause to pull a specific record or set of records for editing or deletion, and it does NOT have to be marked as the PK to do so. We all know what candidate keys are. They are a field or set of fields which taken together CURRENTLY contains data that is unique within that set of fields in that table. We all know that we can take any candidate key and use it as a FK in a child table. It is not marked in the parent as the PK, but the fact that (the data in) it is unique allows us to use that as the FK in the child table. So in fact by this example we can have a table FULL OF candidate keys DOZENS OF THEM if we can discover that many candidate keys. We can intentionally not designate any one of them as the PK, yet in fact we can use any valid candidate key as the FK (pointer back to the parent) in a child table. You can demonstrate that for yourself simply by doing a join on two such tables, or even by building a where clause on such candidate key. The FUNCTIONALITY of the PK is obtained even though no PK is specified in the parent table. That is why it is important to not get hung up on the model! A PK is an artificial construct from the get go. It is a useful construct but is not required to do many of the things that some people here on the list believe it is required for. Given that it is an artificial construct, and given that a surrogate ANPK can be substituted at the drop of a hat for a natural PK, and given that the ANPK solves many problems that are created by a natural PK, I choose in almost every case to use one. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 6:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. -- 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 jwcolby at colbyconsulting.com Thu Jul 26 07:15:25 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 08:15:25 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00d101c7cf78$bd18e920$8abea8c0@XPS> Message-ID: <20070726121539.6EEC0BD62@smtp-auth.no-ip.com> Well then, there ya go. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:33 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <<>Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Of course not, it would not be a relational db if there was not a child table.>> That is not correct. A "relation" does not refer to the relationship between two tables, it refers to the tables themselves. When designing a relational system, before you can start the normalization process with 1NF, you have to form the relations using the following rules: The relation 1. Describes one entity. 2. Has no duplicate rows; hence there is always a primary key. 3. Columns are unordered. 4. Rows are unordered. Most definitely yes a single table is relational. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 8:32 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >Have you ever created a one table relational database? (OK, smart alecs >- that remained so.) Of course not, it would not be a relational db if there was not a child table. >Have you ever created a table that didn't have a PK? (when you were >done creating it). Yes, but not often. I almost always add the ANPK whether or not I need one. But any table with no children does not require a PK in order to exist and contain data. In order to select it for editing / deletion is another story but it still does not have to contain a field, marked by the database as being a PK, nor does it have to have a unique index on it. ANY field(s) with unique data (candidate key) can be used in a where clause to pull a specific record or set of records for editing or deletion, and it does NOT have to be marked as the PK to do so. We all know what candidate keys are. They are a field or set of fields which taken together CURRENTLY contains data that is unique within that set of fields in that table. We all know that we can take any candidate key and use it as a FK in a child table. It is not marked in the parent as the PK, but the fact that (the data in) it is unique allows us to use that as the FK in the child table. So in fact by this example we can have a table FULL OF candidate keys DOZENS OF THEM if we can discover that many candidate keys. We can intentionally not designate any one of them as the PK, yet in fact we can use any valid candidate key as the FK (pointer back to the parent) in a child table. You can demonstrate that for yourself simply by doing a join on two such tables, or even by building a where clause on such candidate key. The FUNCTIONALITY of the PK is obtained even though no PK is specified in the parent table. That is why it is important to not get hung up on the model! A PK is an artificial construct from the get go. It is a useful construct but is not required to do many of the things that some people here on the list believe it is required for. Given that it is an artificial construct, and given that a surrogate ANPK can be substituted at the drop of a hat for a natural PK, and given that the ANPK solves many problems that are created by a natural PK, I choose in almost every case to use one. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 6:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. -- 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 bbruen at unwired.com.au Thu Jul 26 07:30:03 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Thu, 26 Jul 2007 22:30:03 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> References: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Message-ID: <200707262230.04619.bbruen@unwired.com.au> On Wednesday 25 July 2007 23:18, jwcolby wrote: > Bruce, > > >Any table that does not have a natural primary key is not a pure dataset, > > ... > > No, Any table that does not have a natural primary key CANDIDATE is not a > pure dataset, ... > &< ..... Let me rephrase myself. 1) I'm not talking about indexes. 2) I'm not talking about Access/SQLServer/... tables I was trying to indicate a "best practice". If a tuple in a dataset cannot be uniquely identified by one (or possibly more) natural keys (made up of one or more "natural data" fields of the table), then the table is "badly formed" and further thought should be given to the schema design before any indexes, based on real or surrogate data should be considered. I just thought the quick statement could be a BP "rule" that the OP could have used. I didn't mean to start DBWarLVI. -- regards Bruce From ssharkins at gmail.com Thu Jul 26 07:39:08 2007 From: ssharkins at gmail.com (Susan Harkins) Date: Thu, 26 Jul 2007 08:39:08 -0400 Subject: [AccessD] Menu to Ribbon reference Message-ID: <000001c7cf82$04df9c50$5f32fad1@SusanOne> http://office.microsoft.com/en-au/word/HA100744321033.aspx?pid=CH10048743103 3 The number one complaint I've heard about Office 2007 is the ribbon -- we can't find anything! Well, here's an online reference guide. On dial-up, it took a few minutes to load, but seems to work well enough. Wish I'd found it sooner. ;) If someone's already posted it here, I missed it -- and I apologize for the repeat. Susan H. From jwcolby at colbyconsulting.com Thu Jul 26 07:57:47 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 08:57:47 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00cd01c7cf78$11c31050$8abea8c0@XPS> Message-ID: <20070726125801.16114BD11@smtp-auth.no-ip.com> >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 jwcolby at colbyconsulting.com Thu Jul 26 08:07:05 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 09:07:05 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707262230.04619.bbruen@unwired.com.au> Message-ID: <20070726130719.A728DBDC6@smtp-auth.no-ip.com> Bruce, While the DATA may in fact be badly formed (the table is not!), in real life there are instances where the data is badly formed (there are duplicates) and yet the data is still usable and still used. And while I admire all the "tuple talk", there are way more people in the world (outside of academia) that understand tables, rows and fields. I have read the books, I understand the concepts, but I do not need to talk the model talk and find it more useful not to. And yes, I understand that there are those that treasure their tuples. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Thursday, July 26, 2007 8:30 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 23:18, jwcolby wrote: > Bruce, > > >Any table that does not have a natural primary key is not a pure > >dataset, > > ... > > No, Any table that does not have a natural primary key CANDIDATE is > not a pure dataset, ... > &< ..... Let me rephrase myself. 1) I'm not talking about indexes. 2) I'm not talking about Access/SQLServer/... tables I was trying to indicate a "best practice". If a tuple in a dataset cannot be uniquely identified by one (or possibly more) natural keys (made up of one or more "natural data" fields of the table), then the table is "badly formed" and further thought should be given to the schema design before any indexes, based on real or surrogate data should be considered. I just thought the quick statement could be a BP "rule" that the OP could have used. I didn't mean to start DBWarLVI. -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Thu Jul 26 08:12:22 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Thu, 26 Jul 2007 09:12:22 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <20070725191324.A7753BC78@smtp-auth.no-ip.com> References: <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> <20070725191324.A7753BC78@smtp-auth.no-ip.com> Message-ID: <29f585dd0707260612i1168ab48x1364e553b82d2f1b@mail.gmail.com> No need on the temp table since presumably it will only contain a relatively small number of records (<100, say). But of course the real table needs an index on the column you're examining with the IN() values. A. On 7/25/07, jwcolby wrote: > > Do you need to create an index on the field in the temp table? > > From jimdettman at verizon.net Thu Jul 26 08:32:42 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 26 Jul 2007 09:32:42 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070726125801.16114BD11@smtp-auth.no-ip.com> References: <00cd01c7cf78$11c31050$8abea8c0@XPS> <20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: <003201c7cf89$71ef8420$8abea8c0@XPS> John, All I can say is once again you entirely missed the point. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 8:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 bbruen at unwired.com.au Thu Jul 26 08:33:27 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Thu, 26 Jul 2007 23:33:27 +1000 Subject: [AccessD] Menu to Ribbon reference In-Reply-To: <000001c7cf82$04df9c50$5f32fad1@SusanOne> References: <000001c7cf82$04df9c50$5f32fad1@SusanOne> Message-ID: <200707262333.27477.bbruen@unwired.com.au> On Thursday 26 July 2007 22:39, Susan Harkins wrote: > http://office.microsoft.com/en-au/word/HA100744321033.aspx?pid=CH1004874310 >3 3 > > The number one complaint I've heard about Office 2007 is the ribbon -- we > can't find anything! Well, here's an online reference guide. On dial-up, > it took a few minutes to load, but seems to work well enough. Wish I'd > found it sooner. ;) > > If someone's already posted it here, I missed it -- and I apologize for the > repeat. > > Susan H. Hey, hey! Yes I have seen this site. Here's my take. The ignition switch is now in the back seat ashtray. (You can access the back seat ashtray by getting the 864 bus to Muskgogy) The gear shift is in the the boot. The boot has been replaced by the new improved LSA (Click on the TLA link to discover the new improved glossary) ... ... ... GRRRRRRRRR ... ... LSA - Luggage stowage area. Microsoft now has an improved mechanism for transporting your luggage to wherever you want to go today. Its called the LSA. LSA offers both home and business users a new and improved way to get their luggage into approximately the same geographic location as their customers. Customers will immediately recognize the advantage of these new techniques. [Related topics] ... ... click ... 404:Not found (Still laughing hysterically) -- regards Bruce From ssharkins at gmail.com Thu Jul 26 08:46:34 2007 From: ssharkins at gmail.com (Susan Harkins) Date: Thu, 26 Jul 2007 09:46:34 -0400 Subject: [AccessD] Menu to Ribbon reference In-Reply-To: <200707262333.27477.bbruen@unwired.com.au> References: <000001c7cf82$04df9c50$5f32fad1@SusanOne> <200707262333.27477.bbruen@unwired.com.au> Message-ID: <001e01c7cf8b$6be2d4e0$7232fad1@SusanOne> click ... 404:Not found (Still laughing hysterically) =======Well, I'm so glad I could add to your entertainment! ;) Seriously, it worked Okay for me even though it took a while to load, but then, I didn't look around for long -- just looked up a few things and left. I was frustrated by a few items that wanted to redirect me to another online document. But, overall, it seems to work better than 2007 Help files -- now that leaves me totally frustrated, reading, reading, reading to find out "how" to actually access a feature -- whoever writes that stuff really doesn't understand what users need, and that's a shame. I keep telling them they need me... Susan H. From Jim.Hale at FleetPride.com Thu Jul 26 08:51:05 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 26 Jul 2007 08:51:05 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725151912.941B1BCEA@smtp-auth.no-ip.com> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: LOL And how many times have we heard this from clients particularly when they are justifying bad design or databases that "work" but not really well. I think we have to grant Jim the point that the more we understand relational theory and its nuances the better we can make informed decisions in structuring designs. I am not a slave to relational theory but if I'm going to design away from dogma I want my choice to be an informed one weighing the pros and cons. After all, these programs do purport to be relational so the more we understand where they succeeed or fail the better we become as developers. As a power user I began building "databases" long before I ever heard of relational theory. As I began learning the theory I understood how flawed and unscalable many of my constructs were. Today the databases I build don't religiously follow the gospel according to Codd but are better as I more closely understand and follow the relational model. Assuming that relational theory, at least in the abstract, is a logical internally consistent theory that works and is worth using, it is a "best practice" to implement the theory SUBJECT TO the constraints imposed by the hardware and software platforms being used. Jim Hale *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From mmattys at rochester.rr.com Thu Jul 26 09:04:13 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Thu, 26 Jul 2007 10:04:13 -0400 Subject: [AccessD] Primary Key Best Practices References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: <008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop> >2. Has no duplicate rows; hence there is always a primary key. So then, I should conclude that if there is no PK then I should add one to make the table 'relational' and -in practice- the fastest, most reliable way to do that is to add an AUTONUMBER? LOL!!! Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: "Hale, Jim" To: "Access Developers discussion and problem solving" Sent: Thursday, July 26, 2007 9:51 AM Subject: Re: [AccessD] Primary Key Best Practices > > > what works.> > > LOL And how many times have we heard this from clients particularly when > they are justifying bad design or databases that "work" but not really > well. I think we have to grant Jim the point that the more we understand > relational theory and its nuances the better we can make informed > decisions in structuring designs. I am not a slave to relational theory > but if I'm going to design away from dogma I want my choice to be an > informed one weighing the pros and cons. After all, these programs do > purport to be relational so the more we understand where they succeeed > or fail the better we become as developers. As a power user I began > building "databases" long before I ever heard of relational theory. As I > began learning the theory I understood how flawed and unscalable many of > my constructs were. Today the databases I build don't religiously follow > the gospel according to Codd but are better as I more closely understand > and follow the relational model. Assuming that relational theory, at > least in the abstract, is a logical internally consistent theory that > works and is worth using, it is a "best practice" to implement the > theory SUBJECT TO the constraints imposed by the hardware and software > platforms being used. > > Jim Hale > > > *********************************************************************** > The information transmitted is intended solely for the individual or > entity to which it is addressed and may contain confidential and/or > privileged material. Any review, retransmission, dissemination or > other use of or taking action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. > If you have received this email in error please contact the sender and > delete the material from any computer. As a recipient of this email, > you are responsible for screening its contents and the contents of any > attachments for the presence of viruses. No liability is accepted for > any damages caused by any virus transmitted by this email. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From bbruen at unwired.com.au Thu Jul 26 09:29:17 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Fri, 27 Jul 2007 00:29:17 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: <200707270029.17570.bbruen@unwired.com.au> On Thursday 26 July 2007 23:51, Hale, Jim wrote: 8< > it is a "best practice" to implement the > theory SUBJECT TO the constraints imposed by the hardware and software > platforms being used > 8< and may I permissably add: and communicate those constraints so imposed, in such a way that subsequent enquiring monkeys have at least half a chance -- regards Bruce From jwcolby at colbyconsulting.com Thu Jul 26 09:41:16 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 10:41:16 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707270029.17570.bbruen@unwired.com.au> Message-ID: <20070726144130.BB22CBD43@smtp-auth.no-ip.com> ROTFL. If only! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Thursday, July 26, 2007 10:29 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Thursday 26 July 2007 23:51, Hale, Jim wrote: 8< > it is a "best practice" to implement the theory SUBJECT TO the > constraints imposed by the hardware and software platforms being used > 8< and may I permissably add: and communicate those constraints so imposed, in such a way that subsequent enquiring monkeys have at least half a chance -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bbruen at unwired.com.au Thu Jul 26 09:43:11 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Fri, 27 Jul 2007 00:43:11 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop> Message-ID: <200707270043.11462.bbruen@unwired.com.au> To get banal, lets consider a dataset that consists of one and only one column "NumberOfItemsOrdered". It has, as of this moments snapshot, 234867 rows: 1 4 87 8734 (null) 1 34 six 224 ... 1 Of what possible use it this? Where are the problems? Why are we debating this? -- regards Bruce From markamatte at hotmail.com Thu Jul 26 10:04:40 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 26 Jul 2007 15:04:40 +0000 Subject: [AccessD] check for file in ftp site In-Reply-To: <007601c7cf2d$fb5e55d0$0200a8c0@ULTRADNT> Message-ID: Steve, I am using API calls. I'll send out something later tonight. Thanks, Mark >From: "Steve Conklin" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] check for file in ftp site >Date: Wed, 25 Jul 2007 22:37:54 -0400 > >I don't necessarily want your file, but would rather see here a discussion >of technique and maybe a couple lines of the most relevant code. I think >more of us benefit that way. There are so many ways to do this - Are you >using an API? A 3rd party client? Generating a script to use with the >built-in FTP.exe (which is what I normally do) ? > >Tia, >Steve > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Tuesday, July 24, 2007 11:25 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] check for file in ftp site > >Hello All, > >I am more than happy to send almost anything to almost anyone...but as we >are getting back into some of our Netiquette Practices...please send any >other "Me Too"'s to me directly...to lessen the List traffic. > >Thanks, > >Mark A. Matte > >P.S...Doug, I sent you a copy already...good luck...its just an ugly >scrapped together example. > > > >From: "Doug Barnes" > >Reply-To: Access Developers discussion and problem > >solving > >To: "Access Developers discussion and problem > >solving" > >Subject: Re: [AccessD] check for file in ftp site > >Date: Tue, 24 Jul 2007 10:49:10 -0400 > > > >Would love to see a copy, as well > > > > > >Douglas Barnes > > > >Starn Technical Services > >P.O. Box 1172 > >15957 Conneaut Lake Road, Suite 7 > >Meadville, PA 16335 > > > >doug at starntech.com > >P: 814.724.1045 > >F: 814.337.3460 > > > > > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte > >Sent: Monday, July 23, 2007 4:25 PM > >To: accessd at databaseadvisors.com > >Subject: Re: [AccessD] check for file in ftp site > > > > > >Sending You a zip file offline. > > > > > > >From: "Reuben Cummings" > > >Reply-To: Access Developers discussion and problem > > >solving > > >To: "AccessD" > > >Subject: [AccessD] check for file in ftp site > > >Date: Mon, 23 Jul 2007 15:35:56 -0400 > > > > > >I am wanting to log into an ftp site, look thru all the txt files (only > >txt > > >files), and download all files that are new since the last check. > > > > > >The files are all numbered sequentially so I can parse out the numbers >to > > >determine what files are new. > > > > > >However, I could use some assistance in looping thru the txt file >names. > > > > > >Thanks. > > > > > >Reuben Cummings > > >GFC, LLC > > >812.523.1017 > > > > > > > > > > > >-- > > >AccessD mailing list > > >AccessD at databaseadvisors.com > > >http://databaseadvisors.com/mailman/listinfo/accessd > > >Website: http://www.databaseadvisors.com > > > >_________________________________________________________________ > >http://newlivehotmail.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 > >_________________________________________________________________ >Need a brain boost? Recharge with a stimulating game. Play now! >http://club.live.com/home.aspx?icid=club_hotmailtextlink1 > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Need a brain boost? Recharge with a stimulating game. Play now!? http://club.live.com/home.aspx?icid=club_hotmailtextlink1 From mmattys at rochester.rr.com Thu Jul 26 10:17:23 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Thu, 26 Jul 2007 11:17:23 -0400 Subject: [AccessD] Primary Key Best Practices References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop> <200707270043.11462.bbruen@unwired.com.au> Message-ID: <011a01c7cf98$12359ab0$0202a8c0@Laptop> Is this OT yet? These could possibly be used for: names of pushpins on a map - (all have latitude and longitude) filenames, including Null - (all have a timestamp based upon the vibration of an atom or crystal) [Duplicate timestamps occur after several billion years, but who cares?] Problem: I wouldn't have a problem as long as records are kept of where or when. Otherwise, I can't reliably locate the record by it's name in this column. We are debating this because the records of where or when are not always kept or communicated, as far as we know. Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: "Bruce Bruen" To: "Access Developers discussion and problem solving" Sent: Thursday, July 26, 2007 10:43 AM Subject: Re: [AccessD] Primary Key Best Practices > To get banal, lets consider a dataset that consists of one and only one > column "NumberOfItemsOrdered". It has, as of this moments snapshot, 234867 > rows: > 1 > 4 > 87 > 8734 > (null) > 1 > 34 > six > 224 > ... > 1 > > Of what possible use it this? Where are the problems? Why are we debating > this? > > -- > regards > > Bruce From iggy at nanaimo.ark.com Thu Jul 26 11:06:43 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Thu, 26 Jul 2007 09:06:43 -0700 Subject: [AccessD] Page Orientation 2003 Message-ID: <46A8C693.6040805@nanaimo.ark.com> Hey All Finally made the move to Access2003. I am in the process of converting an Access97 application to Access2003. Code that I have used for years to change the page orientation on a preview report in Access97 no longer seems to work. I have a little freebie DELL printer that came with the machine. If I set the printer default to Landscape then I cannot change it to Portrait when previewing a report and vica versa. I have downloaded examples from Microsoft, I can change the page size but not the orientation. Before I start moving printers around I just thought I would ask, could this be a printer specific problem I am running into here? Thank you. From cfoust at infostatsystems.com Thu Jul 26 11:05:19 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 09:05:19 -0700 Subject: [AccessD] Menu to Ribbon reference In-Reply-To: <001e01c7cf8b$6be2d4e0$7232fad1@SusanOne> References: <000001c7cf82$04df9c50$5f32fad1@SusanOne><200707262333.27477.bbruen@unwired.com.au> <001e01c7cf8b$6be2d4e0$7232fad1@SusanOne> Message-ID: The word wrap must have bitten somebody who wasn't paying attention .... Works just fine for me. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Thursday, July 26, 2007 6:47 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Menu to Ribbon reference click ... 404:Not found (Still laughing hysterically) =======Well, I'm so glad I could add to your entertainment! ;) Seriously, it worked Okay for me even though it took a while to load, but then, I didn't look around for long -- just looked up a few things and left. I was frustrated by a few items that wanted to redirect me to another online document. But, overall, it seems to work better than 2007 Help files -- now that leaves me totally frustrated, reading, reading, reading to find out "how" to actually access a feature -- whoever writes that stuff really doesn't understand what users need, and that's a shame. I keep telling them they need me... Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Thu Jul 26 11:28:05 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 09:28:05 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070726125801.16114BD11@smtp-auth.no-ip.com> References: <00cd01c7cf78$11c31050$8abea8c0@XPS> <20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 DWUTKA at Marlow.com Thu Jul 26 11:38:02 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 26 Jul 2007 11:38:02 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: It's no wonder JWC and I get along so well! ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:28 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From Jim.Hale at FleetPride.com Thu Jul 26 11:45:21 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 26 Jul 2007 11:45:21 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707270029.17570.bbruen@unwired.com.au> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS><20070725151912.941B1BCEA@sm tp-auth.no-ip.com> <200707270029.17570.bbruen@unwired.com.au> Message-ID: LOL, Nah I think it's more fun to figure out the dimensions of a room by running full speed into each wall. At least master Gates seems to think so......... Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Thursday, July 26, 2007 9:29 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Thursday 26 July 2007 23:51, Hale, Jim wrote: 8< > it is a "best practice" to implement the > theory SUBJECT TO the constraints imposed by the hardware and software > platforms being used > 8< and may I permissably add: and communicate those constraints so imposed, in such a way that subsequent enquiring monkeys have at least half a chance -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From jwcolby at colbyconsulting.com Thu Jul 26 11:45:43 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 12:45:43 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726164558.01C08BC72@smtp-auth.no-ip.com> Charlotte, c'mon. I am not willfully misrepresenting anything. You said it could not be done, I showed that it can. Perhaps you are willfully not being specific in what you are saying? Someone states you HAVE TO HAVE A PK to edit a table in SQL Server. That is just plain FALSE. I DEMONSTRATED how it was false. If you don't like that answer then demonstrate HOW IT IS TRUE, do not attempt to claim that I am "willfully misrepresenting" something. I do not see you or anyone else disputing what I said, other than a whimpering "you just misinterpreted" or "you obviously missed the point again". Whimper all you want but don't expect me to sympathize when you do not come up with how my examples are wrong. I learn from this list all the time, but to be honest there is not much to learn from "you misrepresented" or "you obviously missed the point". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 jwcolby at colbyconsulting.com Thu Jul 26 11:46:44 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 12:46:44 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726164658.2690DBD34@smtp-auth.no-ip.com> OMG! DON'T SAY THAT! ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 26, 2007 12:38 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices It's no wonder JWC and I get along so well! ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:28 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Thu Jul 26 11:50:38 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 11:50:38 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00cd01c7cf78$11c31050$8abea8c0@XPS><20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: <024a01c7cfa5$19030410$6402a8c0@ScuzzPaq> LOL! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL From john at winhaven.net Thu Jul 26 11:50:38 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 11:50:38 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <011a01c7cf98$12359ab0$0202a8c0@Laptop> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS><008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop><200707270043.11462.bbruen@unwired.com.au> <011a01c7cf98$12359ab0$0202a8c0@Laptop> Message-ID: <024e01c7cfa5$1b67a800$6402a8c0@ScuzzPaq> LOL! NOW the mapping guy gets into it! ;o) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Michael R Mattys Sent: Thursday, July 26, 2007 10:17 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Is this OT yet? These could possibly be used for: names of pushpins on a map - (all have latitude and longitude) From cfoust at infostatsystems.com Thu Jul 26 11:55:12 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 09:55:12 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070726164558.01C08BC72@smtp-auth.no-ip.com> References: <20070726164558.01C08BC72@smtp-auth.no-ip.com> Message-ID: John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, c'mon. I am not willfully misrepresenting anything. You said it could not be done, I showed that it can. Perhaps you are willfully not being specific in what you are saying? Someone states you HAVE TO HAVE A PK to edit a table in SQL Server. That is just plain FALSE. I DEMONSTRATED how it was false. If you don't like that answer then demonstrate HOW IT IS TRUE, do not attempt to claim that I am "willfully misrepresenting" something. I do not see you or anyone else disputing what I said, other than a whimpering "you just misinterpreted" or "you obviously missed the point again". Whimper all you want but don't expect me to sympathize when you do not come up with how my examples are wrong. I learn from this list all the time, but to be honest there is not much to learn from "you misrepresented" or "you obviously missed the point". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 john at winhaven.net Thu Jul 26 11:55:42 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 11:55:42 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: <025501c7cfa5$cfe2cfd0$6402a8c0@ScuzzPaq> Hence the value of these "discussions" once in awhile. There are many nuances to designing an appropriate application/data structure to best meet the demands of its intended use. I doubt any one here adheres 100% to the Book of Codd. Knowing what experts like you and some of the others involved in this thread have done in addition (or in lieu off) relational theory is of great benefit to many others lurking about (or poking and prodding with questions). I have certainly picked at least one good tip! Thank you all for your input! John B. Now, let's all wipe the foam off and get back to work ;o) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim LOL And how many times have we heard this from clients particularly when they are justifying bad design or databases that "work" but not really well. I think we have to grant Jim the point that the more we understand relational theory and its nuances the better we can make informed decisions in structuring designs. I am not a slave to relational theory but if I'm going to design away from dogma I want my choice to be an informed one weighing the pros and cons. After all, these programs do purport to be relational so the more we understand where they succeeed or fail the better we become as developers. As a power user I began building "databases" long before I ever heard of relational theory. As I began learning the theory I understood how flawed and unscalable many of my constructs were. Today the databases I build don't religiously follow the gospel according to Codd but are better as I more closely understand and follow the relational model. Assuming that relational theory, at least in the abstract, is a logical internally consistent theory that works and is worth using, it is a "best practice" to implement the theory SUBJECT TO the constraints imposed by the hardware and software platforms being used. From DWUTKA at Marlow.com Thu Jul 26 12:09:30 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 26 Jul 2007 12:09:30 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: I have to agree with JWC on this (which means either this thread is done, or the world is going to stop spinning soon....either/or). How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective? A statement was made, JWC showed it was a false statement, and instead of admitting that the statement is false, you are saying it's true because it's true for a user? Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:55 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From ewaldt at gdls.com Thu Jul 26 12:22:03 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 26 Jul 2007 13:22:03 -0400 Subject: [AccessD] Importing from Excel In-Reply-To: Message-ID: Importing from Excel is really simple, of course, if there's a single row of titles, followed by rows of data. In my case, users get two workbooks a week, each having two worksheets; one worksheet has data starting on row 4, the other on row 3 . They are consistent, and I can refer to them by their sheet names (say USA for the first, Can for the second). Once I get to the data row, things are fairly consistent, the exception being that sometimes the data rows stop, a line of information is inserted, and then the data rows start again. Even then, the data columns continue where they left off. If I were to get the workbooks at my desk, I'd use VBA within Excel to combine them into a 3rd sheet, clean them up, and then have Access import the new sheet. However, the people wanting to move the data into Access won't want to do this. I'm looking for favorite methods here. How would you go about doing this strictly from Access? TIA. Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From jwcolby at colbyconsulting.com Thu Jul 26 12:27:40 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 13:27:40 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726172754.275C9BEDD@smtp-auth.no-ip.com> Charlotte, SQL Server cheerfully passes it's abilities along to the outside world. Have you even tried the things I discussed "from the outside"? I suggest that you will be surprised by the answers. I just recreated my simple test table, two fields, char(1). I DID NOT create a PK, nor an index on the table. I went into ACCESS and created a DSN to that database, and linked that table. I just entered data into the table. Do it yourself for crying out loud. It works. NO PK. NO INDEX. Yes, I lied to SQL Server (or more correctly the DSN building wizard) and told it that there was a PK but in actual fact there is not one. I told it that the first field was the PK. Access put a PK symbol on that field. It now tells me (in design view) that there is a "yes, no duplicates" index on that field. I placed this data in the fields A b C d A b C d Access allowed me to enter this data, it stored in SQL Server. I can edit those records where the data is unique, I cannot where the data is not unique. When I attempt to delete one of the duplicate records, BOTH delete. We know why. But in any case, there is no PK (in the data store, SQL Server). I have checked, I did not create any, nor did sql server on Access' request. There are no indexes in SQL Server. And yet Access CAN ADD RECORDS, Access CAN EDIT RECORDS, and Access CAN DELETE RECORDS, Access can even delete the duplicates (both at once). I would like to reiterate that I have tried this stuff, I have PROVEN that your statement is FALSE, SQL Server CAN create tables without a PK, it can accept data into that table, it can update data in that table, and it can delete data in that table, ALL FROM A USER INTERFACE (ACCESS). You (and others as well) make blanket statements about things you have never even tried. I on the other hand have tried it and stand behind my statements with demonstrable facts! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, c'mon. I am not willfully misrepresenting anything. You said it could not be done, I showed that it can. Perhaps you are willfully not being specific in what you are saying? Someone states you HAVE TO HAVE A PK to edit a table in SQL Server. That is just plain FALSE. I DEMONSTRATED how it was false. If you don't like that answer then demonstrate HOW IT IS TRUE, do not attempt to claim that I am "willfully misrepresenting" something. I do not see you or anyone else disputing what I said, other than a whimpering "you just misinterpreted" or "you obviously missed the point again". Whimper all you want but don't expect me to sympathize when you do not come up with how my examples are wrong. I learn from this list all the time, but to be honest there is not much to learn from "you misrepresented" or "you obviously missed the point". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 Lambert.Heenan at AIG.com Thu Jul 26 12:29:53 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Thu, 26 Jul 2007 12:29:53 -0500 Subject: [AccessD] Primary Key Best Practices Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> I do whish this thread would come to an end. It seem to be just fodder for the personality contestants. "How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective?" - because this is an ACCESS database development list, and as far as SQL server goes, we are users (unless like John you have a server farm in the back room and are running the whole show single handed). Ok. So Charlotte initially said "you cannot do X", and then John pounced and said "yes you can". Big deal. Charlotte did not explicitly specify "In Access", and John in his rebuttal kinda sorta forgot to explicitly mention he was working inside SQL server. Big deal again. I repeat, this is an Access developer list. We should be talking about what you can and can't do in Access (which is what Charlotte did). Ok. Compare and contrast with other RDBMS, but do we really need dozens of "she said / he said" messages on a somewhat tired topic? Please deep six it. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 26, 2007 1:10 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices I have to agree with JWC on this (which means either this thread is done, or the world is going to stop spinning soon....either/or). How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective? A statement was made, JWC showed it was a false statement, and instead of admitting that the statement is false, you are saying it's true because it's true for a user? Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:55 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ebarro at verizon.net Thu Jul 26 12:31:16 2007 From: ebarro at verizon.net (Eric Barro) Date: Thu, 26 Jul 2007 10:31:16 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <0JLS000MIRCJL0H0@vms048.mailsrvcs.net> Charlotte, Access developers by default have access to the tables in the database container because by default they are the equivalent of SA in SQL server. Hence when you develop in Access you take the point of view of not only the user but the DBA as well. Both Jim and yourself and many others who use Microsoft Access develop database applications have to deal with tables don't you? Granted, Colby is very passionate about this views and opinions, but he has a valid point and he has provided proof. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 9:55 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, c'mon. I am not willfully misrepresenting anything. You said it could not be done, I showed that it can. Perhaps you are willfully not being specific in what you are saying? Someone states you HAVE TO HAVE A PK to edit a table in SQL Server. That is just plain FALSE. I DEMONSTRATED how it was false. If you don't like that answer then demonstrate HOW IT IS TRUE, do not attempt to claim that I am "willfully misrepresenting" something. I do not see you or anyone else disputing what I said, other than a whimpering "you just misinterpreted" or "you obviously missed the point again". Whimper all you want but don't expect me to sympathize when you do not come up with how my examples are wrong. I learn from this list all the time, but to be honest there is not much to learn from "you misrepresented" or "you obviously missed the point". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.20/919 - Release Date: 7/26/2007 9:56 AM From DWUTKA at Marlow.com Thu Jul 26 12:38:08 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 26 Jul 2007 12:38:08 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> Message-ID: You have a point. However, SQL Server is no longer a dba or IT Department system. You can get SQL Server Express for free, so anyone with a computer with a few gigs of extra drive space can run their own SQL Server databases. As far as this thread goes, I haven't been participating much, but I have been skimming the posts. Ego issues aside, it is a wonderful exchange of theory and practice in regards to databases in general...I think it should go until it runs it's course. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Thursday, July 26, 2007 12:30 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I do whish this thread would come to an end. It seem to be just fodder for the personality contestants. "How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective?" - because this is an ACCESS database development list, and as far as SQL server goes, we are users (unless like John you have a server farm in the back room and are running the whole show single handed). Ok. So Charlotte initially said "you cannot do X", and then John pounced and said "yes you can". Big deal. Charlotte did not explicitly specify "In Access", and John in his rebuttal kinda sorta forgot to explicitly mention he was working inside SQL server. Big deal again. I repeat, this is an Access developer list. We should be talking about what you can and can't do in Access (which is what Charlotte did). Ok. Compare and contrast with other RDBMS, but do we really need dozens of "she said / he said" messages on a somewhat tired topic? Please deep six it. Lambert The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwcolby at colbyconsulting.com Thu Jul 26 12:41:58 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 13:41:58 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726174212.D575FBEF8@smtp-auth.no-ip.com> And it isn't even true for a user!!! And why do I get in full flaming mode? Because of people making completely unsubstantiated claims. People tend to accept what they have been told and never have occasion to or need to test whether in fact it is true. The problem becomes when they dogmatically insist that what they were told is true without ever actually trying it. It happens that I work all the time in tables of raw data directly imported in to sql server. I know the reality because I see it demonstrated to me. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 26, 2007 1:10 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices I have to agree with JWC on this (which means either this thread is done, or the world is going to stop spinning soon....either/or). How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective? A statement was made, JWC showed it was a false statement, and instead of admitting that the statement is false, you are saying it's true because it's true for a user? Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:55 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From listmaster at databaseadvisors.com Thu Jul 26 12:59:31 2007 From: listmaster at databaseadvisors.com (Bryan Carbonnell) Date: Thu, 26 Jul 2007 13:59:31 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> Message-ID: On 7/26/07, Heenan, Lambert wrote: > I do whish this thread would come to an end. It seem to be just fodder for > the personality contestants. > > "How can you defend your position by stating on a DATABASE development list > that your arguments are from a user prospective?" - because this is an > ACCESS database development list, and as far as SQL server goes, we are > users (unless like John you have a server farm in the back room and are > running the whole show single handed). > > Ok. So Charlotte initially said "you cannot do X", and then John pounced and > said "yes you can". > > Big deal. Charlotte did not explicitly specify "In Access", and John in his > rebuttal kinda sorta forgot to explicitly mention he was working inside SQL > server. Big deal again. > > I repeat, this is an Access developer list. We should be talking about what > you can and can't do in Access (which is what Charlotte did). Ok. Compare > and contrast with other RDBMS, but do we really need dozens of "she said / > he said" messages on a somewhat tired topic? > > Please deep six it. These kinds of comments should NEVER go to the list. They should ALWAYS be addressed to one of our moderators. It has been said time and time again, DO NOT TAKE THIS KIND OF REQUEST UPON YOURSELF. That's what we have moderators for. Your friendly neghbourhood (and slightly pissed) Listmaster, Bryan Carbonnell - listmaster at databaseadvisors.com From robert at webedb.com Thu Jul 26 13:04:13 2007 From: robert at webedb.com (Robert L. Stewart) Date: Thu, 26 Jul 2007 13:04:13 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <200707261810.l6QIAQwq006122@databaseadvisors.com> I have watched all the flaming and was surprised at the lack of intelligence and total stubborness in some of it. I do not know if what I do is best practice or not. But, I will go with consistency. In a transactional database, all tables have a surrogate, autonumbering primary key. They also have one or more unique indexes on the candidate key or keys. Also, indexes on all foreign key columns. In a data warehouse or data mart, all dimension tables will have a single column primary key inherited from the source primary table. All fact tables will have multiple columns that make up the primary key. There are no snowflakes. It is a true star schema. Best practice or not, as long as I am consistent in my designs, I will always know how to use it properly. And, I can always explain it to the monkeys that come after. Robert From john at winhaven.net Thu Jul 26 13:14:40 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 13:14:40 -0500 Subject: [AccessD] Primary Key Best Practices - MODERATOR NOTICE In-Reply-To: References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> Message-ID: <028901c7cfb0$d5ff98c0$6402a8c0@ScuzzPaq> Please - let's keep this as civil as possible. It's a good discussion and I pointed that out earlier today but it has been degrading ever since. You're all good people with opinions - let's remember that... Or I'll have to sick the list master on you all! ;o) From jwcolby at colbyconsulting.com Thu Jul 26 13:21:44 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 14:21:44 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707261810.l6QIAQwq006122@databaseadvisors.com> Message-ID: <20070726182158.B2C0CBCDD@smtp-auth.no-ip.com> Robert, I know nothing about data warehouses. Would you define fact table and explain why the PK is a natural key? I assume that it has to do with speed but beyond that could you explain the concepts a little? I am just looking to learn something here about a subject I know nothing about. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Thursday, July 26, 2007 2:04 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices I have watched all the flaming and was surprised at the lack of intelligence and total stubborness in some of it. I do not know if what I do is best practice or not. But, I will go with consistency. In a transactional database, all tables have a surrogate, autonumbering primary key. They also have one or more unique indexes on the candidate key or keys. Also, indexes on all foreign key columns. In a data warehouse or data mart, all dimension tables will have a single column primary key inherited from the source primary table. All fact tables will have multiple columns that make up the primary key. There are no snowflakes. It is a true star schema. Best practice or not, as long as I am consistent in my designs, I will always know how to use it properly. And, I can always explain it to the monkeys that come after. Robert -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Thu Jul 26 13:31:16 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 11:31:16 -0700 Subject: [AccessD] Data Warehouse (Was: Primary Key Best Practices) In-Reply-To: <200707261810.l6QIAQwq006122@databaseadvisors.com> References: <200707261810.l6QIAQwq006122@databaseadvisors.com> Message-ID: Can you give an example of a typical dimension table and what you mean by the source primary table? I've worked primarily with date dimensions using the date as the PK. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Thursday, July 26, 2007 11:04 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices I have watched all the flaming and was surprised at the lack of intelligence and total stubborness in some of it. I do not know if what I do is best practice or not. But, I will go with consistency. In a transactional database, all tables have a surrogate, autonumbering primary key. They also have one or more unique indexes on the candidate key or keys. Also, indexes on all foreign key columns. In a data warehouse or data mart, all dimension tables will have a single column primary key inherited from the source primary table. All fact tables will have multiple columns that make up the primary key. There are no snowflakes. It is a true star schema. Best practice or not, as long as I am consistent in my designs, I will always know how to use it properly. And, I can always explain it to the monkeys that come after. Robert -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Thu Jul 26 13:33:30 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 13:33:30 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707261810.l6QIAQwq006122@databaseadvisors.com> References: <200707261810.l6QIAQwq006122@databaseadvisors.com> Message-ID: <029c01c7cfb3$784b60d0$6402a8c0@ScuzzPaq> Great points! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart In a transactional database, all tables have a surrogate, autonumbering primary key. They also have one or more unique indexes on the candidate key or keys. Also, indexes on all foreign key columns. In a data warehouse or data mart, all dimension tables will have a single column primary key inherited from the source primary table. All fact tables will have multiple columns that make up the primary key. There are no snowflakes. It is a true star schema. From martyconnelly at shaw.ca Thu Jul 26 13:40:09 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 26 Jul 2007 11:40:09 -0700 Subject: [AccessD] Menu to Ribbon reference In-Reply-To: <000001c7cf82$04df9c50$5f32fad1@SusanOne> References: <000001c7cf82$04df9c50$5f32fad1@SusanOne> Message-ID: <46A8EA89.5080909@shaw.ca> Here is a $15 cheat for Word 2007 There are a couple of others out there. Addin for Office 2003 menus to Office 2007 http://news.office-watch.com/t/n.aspx?a=502 Here is a download I got from Allen Browne's Links that might help Access Menu/Toolbar to Ribbon Excel workbook from Microsoft, It matches all previous Access 2003 menu and toolbar items to the new ribbon locations. http://office.microsoft.com/search/redir.aspx?AssetID=AM101757761033 Susan Harkins wrote: >http://office.microsoft.com/en-au/word/HA100744321033.aspx?pid=CH10048743103 >3 > >The number one complaint I've heard about Office 2007 is the ribbon -- we >can't find anything! Well, here's an online reference guide. On dial-up, it >took a few minutes to load, but seems to work well enough. Wish I'd found it >sooner. ;) > >If someone's already posted it here, I missed it -- and I apologize for the >repeat. > >Susan H. > > > -- Marty Connelly Victoria, B.C. Canada From ewaldt at gdls.com Thu Jul 26 14:34:51 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 26 Jul 2007 15:34:51 -0400 Subject: [AccessD] Importing from Excel In-Reply-To: Message-ID: I wrote the code below, which works really well and I'm very happy with it. This is code for Excel, though. What I need to do is the following: 1. Have the user find the Excel file (I can do this). 2. Have the code below apply to the Excel file (Don't know how to do this from within Access). 3. Have Access run the import process on the new worksheet (Not sure how to have it do that specific sheet; can it work on a workbook already in memory without saving the Excel file first?). 4. Do more processing of the data (I have this set up). So I really need help with #2 and maybe #3 above. Of course #2 is using the Excel object model, and that has to be taken into consideration. Any help? Thanks. Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems ---------------------------------------------------------- Sub PrepForImport() ' Created 7/26/2007 by ewaldt Dim intLastRow As Integer Dim intCount As Integer Dim intNewRow As Integer Dim oCell As Object Sheets.Add Sheets("Sheet1").Name = "ToImport" Sheets("ToImport").Select 'Copy only rows where column B = "A" intNewRow = 1 For Each oCell In Sheets("GDLS-SHC").Range("B:B") If oCell.Formula = "A" Then oCell.EntireRow.Copy ActiveSheet.Paste Destination:=Worksheets("ToImport").Range("A" & intNewRow) intNewRow = intNewRow + 1 End If Next oCell For Each oCell In Sheets("GDLS-C").Range("B:B") If oCell.Formula = "A" Then oCell.EntireRow.Copy ActiveSheet.Paste Destination:=Worksheets("ToImport").Range("A" & intNewRow) intNewRow = intNewRow + 1 End If Next oCell 'Check for non-numeric in Pounds and Grams For Each oCell In Sheets("ToImport").Range("C1:D" & intNewRow - 1) If Not IsNumeric(oCell.Formula) Then oCell.Formula = 0 End If Next oCell End Sub This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From mmattys at rochester.rr.com Thu Jul 26 14:53:20 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Thu, 26 Jul 2007 15:53:20 -0400 Subject: [AccessD] Importing from Excel References: Message-ID: <022b01c7cfbe$a0923220$0202a8c0@Laptop> It might be easiest to import the file to Access using DoCmd Dim xlApp As Excel.Application Dim xlWB As Excel.Workbook Dim xlWS As Excel.Worksheet Dim MyRange As Excel.Range Set xlApp = New Excel.Application Set xlWB = xlApp.Workbooks.Add("C:\MyTemplate.xlt") Set db = CurrentDb Set xlWS = xlWB.Sheets("ToImport") With xlWS .Select Set rs = db.OpenRecordset("tblFromFile") .Cells(1, 1).CopyFromRecordset rs End With Set xlWS = Nothing Set rs = Nothing Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: To: Sent: Thursday, July 26, 2007 3:34 PM Subject: Re: [AccessD] Importing from Excel >I wrote the code below, which works really well and I'm very happy with > it. This is code for Excel, though. What I need to do is the following: > > 1. Have the user find the Excel file (I can do this). > 2. Have the code below apply to the Excel file (Don't know how to do this > from within Access). > 3. Have Access run the import process on the new worksheet (Not sure how > to have it do that specific sheet; can it work on a workbook already in > memory without saving the Excel file first?). > 4. Do more processing of the data (I have this set up). > > So I really need help with #2 and maybe #3 above. Of course #2 is using > the Excel object model, and that has to be taken into consideration. > > Any help? Thanks. > > Thomas F. Ewald > Stryker Mass Properties > General Dynamics Land Systems > > ---------------------------------------------------------- > Sub PrepForImport() > > ' Created 7/26/2007 by ewaldt > > Dim intLastRow As Integer > Dim intCount As Integer > Dim intNewRow As Integer > Dim oCell As Object > > Sheets.Add > Sheets("Sheet1").Name = "ToImport" > Sheets("ToImport").Select > > 'Copy only rows where column B = "A" > intNewRow = 1 > > For Each oCell In Sheets("GDLS-SHC").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste > Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > > For Each oCell In Sheets("GDLS-C").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste > Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > > 'Check for non-numeric in Pounds and Grams > For Each oCell In Sheets("ToImport").Range("C1:D" & intNewRow - 1) > If Not IsNumeric(oCell.Formula) Then > oCell.Formula = 0 > End If > Next oCell > > End Sub > > > > This is an e-mail from General Dynamics Land Systems. It is for the > intended recipient only and may contain confidential and privileged > information. No one else may read, print, store, copy, forward or act in > reliance on it or its attachments. If you are not the intended recipient, > please return this message to the sender and delete the message and any > attachments from your computer. Your cooperation is appreciated. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From markamatte at hotmail.com Thu Jul 26 15:18:14 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 26 Jul 2007 20:18:14 +0000 Subject: [AccessD] Importing from Excel In-Reply-To: Message-ID: I'm not sure exactly what you are asking...but #2 sounds like you want to do some formatting? If so...below is some code I use to format a spreadsheet (from within Access), that is actually created from an exported Access report. If I missed the point...sorry, let me know and I'll try again. Good Luck, Mark A. Matte P.S...the formatting is based on a recordset within the db. With appExcel .Workbooks.Open strpathTemp1, 0 '.Visible = True 'just to watch the sheet .ActiveSheet.Name = strReport .Range("A1:AC1").Select .Selection.Font.Bold = True .Selection.Font.Name = "Arial" .Selection.Font.Size = 12 Do Until MyRst.NoMatch Counter = Counter + 1 .Cells(1, Counter) = MyRst!Reas_cd If MyRst![View] = 0 Then .Cells(1, Counter).Font.Color = 255 MyRst.FindNext strSQL Loop .Columns.AutoFit .Rows.AutoFit .Columns.Borders.Color = vbBlack .ActiveWorkbook.Save End With appExcel.Quit >From: ewaldt at gdls.com >Reply-To: Access Developers discussion and problem >solving >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Importing from Excel >Date: Thu, 26 Jul 2007 15:34:51 -0400 > >I wrote the code below, which works really well and I'm very happy with >it. This is code for Excel, though. What I need to do is the following: > >1. Have the user find the Excel file (I can do this). >2. Have the code below apply to the Excel file (Don't know how to do this >from within Access). >3. Have Access run the import process on the new worksheet (Not sure how >to have it do that specific sheet; can it work on a workbook already in >memory without saving the Excel file first?). >4. Do more processing of the data (I have this set up). > >So I really need help with #2 and maybe #3 above. Of course #2 is using >the Excel object model, and that has to be taken into consideration. > >Any help? Thanks. > >Thomas F. Ewald >Stryker Mass Properties >General Dynamics Land Systems > >---------------------------------------------------------- >Sub PrepForImport() > >' Created 7/26/2007 by ewaldt > >Dim intLastRow As Integer >Dim intCount As Integer >Dim intNewRow As Integer >Dim oCell As Object > > Sheets.Add > Sheets("Sheet1").Name = "ToImport" > Sheets("ToImport").Select > >'Copy only rows where column B = "A" > intNewRow = 1 > > For Each oCell In Sheets("GDLS-SHC").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste >Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > > For Each oCell In Sheets("GDLS-C").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste >Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > >'Check for non-numeric in Pounds and Grams > For Each oCell In Sheets("ToImport").Range("C1:D" & intNewRow - 1) > If Not IsNumeric(oCell.Formula) Then > oCell.Formula = 0 > End If > Next oCell > >End Sub > > > >This is an e-mail from General Dynamics Land Systems. It is for the >intended recipient only and may contain confidential and privileged >information. No one else may read, print, store, copy, forward or act in >reliance on it or its attachments. If you are not the intended recipient, >please return this message to the sender and delete the message and any >attachments from your computer. Your cooperation is appreciated. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01 From Jim.Hale at FleetPride.com Thu Jul 26 15:22:01 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 26 Jul 2007 15:22:01 -0500 Subject: [AccessD] Importing from Excel In-Reply-To: References: Message-ID: Using offset you can "walk" a spreadsheet to create a record applying different tests to the cell as needed: Jim Hale Do While Not IsEmpty(ActiveCell) rstbase.AddNew 'create records in output table For x = 0 To 16 If x < 4 Then rstbase.Fields(x) = .ActiveCell.Offset(0, x) 'change sign on Jan-Dec revenue If x > 3 Then If rstbase.Fields("rptline") = 4100 Then rstbase.Fields(x) = -Round(.ActiveCell.Offset(0, x), 3) ElseIf rstbase.Fields("rptline") = 4110 Then rstbase.Fields(x) = -Round(.ActiveCell.Offset(0, x), 3) ElseIf rstbase.Fields("rptline") = 4120 Then rstbase.Fields(x) = -Round(.ActiveCell.Offset(0, x), 3) ElseIf rstbase.Fields("rptline") = 4130 Then rstbase.Fields(x) = -Round(.ActiveCell.Offset(0, x), 3) ElseIf rstbase.Fields("rptline") = 15000 Then rstbase.Fields(x) = Round(.ActiveCell.Offset(0, x), 3) Else rstbase.Fields(x) = Round(.ActiveCell.Offset(0, x), 3) End If End If Next x If Not rstbase.Fields("rptline") = 0 Then rstbase.Update *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From martyconnelly at shaw.ca Thu Jul 26 15:26:06 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 26 Jul 2007 13:26:06 -0700 Subject: [AccessD] Importing from Excel In-Reply-To: References: Message-ID: <46A9035E.6080405@shaw.ca> Couple of other ways avoiding full Excel Application startup You can also open an Excel Spreadsheet using the JET OLE DB Provider to read into a Access table, removing the header record oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _ "Data Source=c:\somepath\mySpreadsheet.xls;" & _ "Extended Properties=""Excel 8.0;HDR=Yes""" Where "HDR=Yes" means that there is a header row in the cell range (or named range), so the provider will not include the first row of the selection into the recordset. If "HDR=No", then the provider will include the first row of the cell range (or named ranged) into the recordset. Sample mbd here http://support.microsoft.com/default.aspx?scid=kb;en-us;278973 or here is some sample VBA code to link a csv text file or optionally a xls file from Access Public Function LinkExternalFileADO(ByVal strTextFileName As String, _ ByVal strLinkTable As String, _ ByVal strLinkSpecRange As String, _ Optional blnXL As Boolean) As Boolean 'Created by Charlotte Foust 'drops and relinks the temp table 'and returns a boolean value for 'the success of the operation 'last modified 7/5/2001 'Sample call: LinkTextFileADO("MyTable.tab","MyTable","MyTable Spec") ' LinkTextFileADO("MySheet.xls","MySheet","MyRange",True) On Error GoTo Proc_err Dim cat As ADOX.Catalog Dim cnn As ADODB.Connection Dim errsCnn As ADODB.Errors Dim errCurr As ADODB.Error 'initialize the return value LinkExternalFileADO = True 'initialize the object variables Set cnn = CurrentProject.Connection Set cat = New ADOX.Catalog cat.ActiveConnection = cnn Set errsCnn = cnn.Errors errsCnn.Clear 'if the file exists, try to link it If strLinkTable <> "" Then 'If no path was included, use the current path If InStr(strTextFileName, "\") = 0 Then strTextFileName = CurrentProject.Path & "\" & strTextFileName End If 'InStr(strTextFileName, "\") = 0 'if the file exists then ... If Dir(strTextFileName) <> "" Then On Error Resume Next 'delete the existing table link cat.Tables.Delete strLinkTable On Error GoTo Proc_err 'link either a text file or an Excel spreadsheet If Not blnXL Then 'create a new link to the text file DoCmd.TransferText acLinkDelim, strLinkSpecRange, _ strLinkTable, strTextFileName Else 'If Not blnXL 'create a new link to the Excel file DoCmd.TransferSpreadsheet acLink, acSpreadsheetTypeExcel9, _ strLinkTable, strTextFileName, True, strLinkSpecRange End If 'Not blnXL Else 'If Dir(strTextFileName) <> "" 'not a valid filename or path LinkExternalFileADO = False End If 'Dir(strTextFileName) <> "" End If Proc_exit: 'cleanup and exit On Error Resume Next Set cat = Nothing Set errsCnn = Nothing Set errCurr = Nothing Set cnn = Nothing Exit Function Proc_err: If errsCnn.Count > 0 Then For Each errCurr In errsCnn MsgBox "Error #" & errCurr.Number & "--" & errCurr.Description _ & vbCrLf & CurrentProject.Name & ".LinkTextFileADO" Next errCurr errsCnn.Clear End If If Err <> 0 Then MsgBox Err.Number & "--" & Err.Description & vbCr _ & " in LinkTextFileADO", vbOKOnly End If LinkExternalFileADO = False Resume Proc_exit End Function 'LinkExternalFileADO(ByVal strTextFileName As String, _ ByVal strLinkTable As String, _ ByVal strLinkSpecRange As String, _ Optional blnXL As Boolean) As Boolean ewaldt at gdls.com wrote: >I wrote the code below, which works really well and I'm very happy with >it. This is code for Excel, though. What I need to do is the following: > >1. Have the user find the Excel file (I can do this). >2. Have the code below apply to the Excel file (Don't know how to do this >from within Access). >3. Have Access run the import process on the new worksheet (Not sure how >to have it do that specific sheet; can it work on a workbook already in >memory without saving the Excel file first?). >4. Do more processing of the data (I have this set up). > >So I really need help with #2 and maybe #3 above. Of course #2 is using >the Excel object model, and that has to be taken into consideration. > >Any help? Thanks. > >Thomas F. Ewald >Stryker Mass Properties >General Dynamics Land Systems > >---------------------------------------------------------- >Sub PrepForImport() > >' Created 7/26/2007 by ewaldt > >Dim intLastRow As Integer >Dim intCount As Integer >Dim intNewRow As Integer >Dim oCell As Object > > Sheets.Add > Sheets("Sheet1").Name = "ToImport" > Sheets("ToImport").Select > >'Copy only rows where column B = "A" > intNewRow = 1 > > For Each oCell In Sheets("GDLS-SHC").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste >Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > > For Each oCell In Sheets("GDLS-C").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste >Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > >'Check for non-numeric in Pounds and Grams > For Each oCell In Sheets("ToImport").Range("C1:D" & intNewRow - 1) > If Not IsNumeric(oCell.Formula) Then > oCell.Formula = 0 > End If > Next oCell > >End Sub > > > -- Marty Connelly Victoria, B.C. Canada From robert at webedb.com Thu Jul 26 15:38:53 2007 From: robert at webedb.com (Robert L. Stewart) Date: Thu, 26 Jul 2007 15:38:53 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <200707262040.l6QKeNDF018504@databaseadvisors.com> Sure... A fact table is, 99.9% of the time, something that is additive. In other words, math of some type will or has been done to it. For example sales of products by customer. The PK would be the sales date, customer key and product key. The dimensions would be the date dimension, customers, and products. A dimension table is totally denormalized. all the data math has already been done on the date in a date dimension table. The day, year, month, etc. are all separate columns. In the customer, all of the addresses, phones, email, etc are included. In the products, all of the vendor information would be included. No joins past the dimension itself. If there are, they are called snowflakes and they usually severely affect the performance of teh mart/warehouse. Robert At 03:18 PM 7/26/2007, you wrote: >Date: Thu, 26 Jul 2007 14:21:44 -0400 >From: "jwcolby" >Subject: Re: [AccessD] Primary Key Best Practices >To: "'Access Developers discussion and problem solving'" > >Message-ID: <20070726182158.B2C0CBCDD at smtp-auth.no-ip.com> >Content-Type: text/plain; charset="us-ascii" > >Robert, > >I know nothing about data warehouses. Would you define fact table and >explain why the PK is a natural key? I assume that it has to do with speed >but beyond that could you explain the concepts a little? > >I am just looking to learn something here about a subject I know nothing >about. > >John W. Colby >Colby Consulting >www.ColbyConsulting.com From martyconnelly at shaw.ca Thu Jul 26 15:51:25 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 26 Jul 2007 13:51:25 -0700 Subject: [AccessD] Data Warehouse (Was: Primary Key Best Practices) In-Reply-To: References: <200707261810.l6QIAQwq006122@databaseadvisors.com> Message-ID: <46A9094D.2080000@shaw.ca> Here is a quick overview, think cubes and hypercubes for storage not 2-D Tables http://en.wikipedia.org/wiki/OLAP_cube Yup Codd got into this too. Charlotte Foust wrote: > Can you give an example of a typical dimension table and what you mean >by the source primary table? I've worked primarily with date dimensions >using the date as the PK. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. >Stewart >Sent: Thursday, July 26, 2007 11:04 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Primary Key Best Practices > >I have watched all the flaming and was surprised at the lack of >intelligence and total stubborness in some of it. > >I do not know if what I do is best practice or not. But, I will go with >consistency. > >In a transactional database, all tables have a surrogate, autonumbering >primary key. They also have one or more unique indexes on the candidate >key or keys. Also, indexes on all foreign key columns. > >In a data warehouse or data mart, all dimension tables will have a >single column primary key inherited from the source primary table. >All fact tables will have multiple columns that make up the primary key. >There are no snowflakes. It is a true star schema. > >Best practice or not, as long as I am consistent in my designs, I will >always know how to use it properly. And, I can always explain it to the >monkeys that come after. > >Robert > > -- Marty Connelly Victoria, B.C. Canada From ewaldt at gdls.com Thu Jul 26 15:58:28 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 26 Jul 2007 16:58:28 -0400 Subject: [AccessD] Importing from Excel In-Reply-To: Message-ID: Thanks, Mark (and others). That's close. What I want to know is how to apply Excel-oriented code to Excel from within Access. Is that what your code does? It looks like it does, since it references Excel objects like workbooks, cells, etc. I'll try putting my code into your context. Thanks, again. Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems Message: 17 Date: Thu, 26 Jul 2007 20:18:14 +0000 From: "Mark A Matte" Subject: Re: [AccessD] Importing from Excel To: accessd at databaseadvisors.com Message-ID: Content-Type: text/plain; format=flowed I'm not sure exactly what you are asking...but #2 sounds like you want to do some formatting? If so...below is some code I use to format a spreadsheet (from within Access), that is actually created from an exported Access report. If I missed the point...sorry, let me know and I'll try again. Good Luck, Mark A. Matte P.S...the formatting is based on a recordset within the db. [Code here] This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From cfoust at infostatsystems.com Thu Jul 26 15:59:09 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 13:59:09 -0700 Subject: [AccessD] Data Warehouse (Was: Primary Key Best Practices) In-Reply-To: <46A9094D.2080000@shaw.ca> References: <200707261810.l6QIAQwq006122@databaseadvisors.com> <46A9094D.2080000@shaw.ca> Message-ID: Yes, and I have several of Ralph Kimball's books on Data Warehouse design and I've built a few, but what I was looking for was an explanation of how a dimension table inherits a single column PK "from the source primary table." I assume it means that all the distinct values for that column that exist in the primary table have a matching PK in the dimension table, but it took me a while to sort it out to that, and I've *worked* with the things! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly Sent: Thursday, July 26, 2007 1:51 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Data Warehouse (Was: Primary Key Best Practices) Here is a quick overview, think cubes and hypercubes for storage not 2-D Tables http://en.wikipedia.org/wiki/OLAP_cube Yup Codd got into this too. Charlotte Foust wrote: > Can you give an example of a typical dimension table and what you mean >by the source primary table? I've worked primarily with date >dimensions using the date as the PK. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. >Stewart >Sent: Thursday, July 26, 2007 11:04 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Primary Key Best Practices > >I have watched all the flaming and was surprised at the lack of >intelligence and total stubborness in some of it. > >I do not know if what I do is best practice or not. But, I will go with >consistency. > >In a transactional database, all tables have a surrogate, autonumbering >primary key. They also have one or more unique indexes on the candidate >key or keys. Also, indexes on all foreign key columns. > >In a data warehouse or data mart, all dimension tables will have a >single column primary key inherited from the source primary table. >All fact tables will have multiple columns that make up the primary key. >There are no snowflakes. It is a true star schema. > >Best practice or not, as long as I am consistent in my designs, I will >always know how to use it properly. And, I can always explain it to the >monkeys that come after. > >Robert > > -- Marty Connelly Victoria, B.C. Canada -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From anitatiedemann at gmail.com Thu Jul 26 21:26:51 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Fri, 27 Jul 2007 12:26:51 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00cd01c7cf78$11c31050$8abea8c0@XPS> <20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: Charlotte, You rock. On 7/27/07, Charlotte Foust wrote: > > Ah, yes, the classic AccessD method for conquering opposition: > willfully misinterpret the responses, deny them any validity, and > declare yourself the winner! Widely used by Colby and by Drew on > occasion. It amounts to "never mind if we're saying much the same > thing, you're WRONG!!" LOL > > Charlotte Foust > > From nd500_lo at charter.net Thu Jul 26 21:43:57 2007 From: nd500_lo at charter.net (Dian) Date: Thu, 26 Jul 2007 19:43:57 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00cd01c7cf78$11c31050$8abea8c0@XPS><20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: <000001c7cff7$fb2a8cd0$6400a8c0@dsunit1> I'll drink to that... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 26, 2007 7:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Charlotte, You rock. On 7/27/07, Charlotte Foust wrote: > > Ah, yes, the classic AccessD method for conquering opposition: > willfully misinterpret the responses, deny them any validity, and > declare yourself the winner! Widely used by Colby and by Drew on > occasion. It amounts to "never mind if we're saying much the same > thing, you're WRONG!!" LOL > > Charlotte Foust > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From mmattys at rochester.rr.com Thu Jul 26 22:06:04 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Thu, 26 Jul 2007 23:06:04 -0400 Subject: [AccessD] Page Orientation 2003 References: <46A8C693.6040805@nanaimo.ark.com> Message-ID: <001001c7cffb$14595c10$0202a8c0@Laptop> Tony, What error are you getting? What happens when you set the printing prefs before opening Access? What size page are you using? Printer capabilities? Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: "Tony Septav" To: "Access Developers discussion and problem solving" Sent: Thursday, July 26, 2007 12:06 PM Subject: [AccessD] Page Orientation 2003 > Hey All > Finally made the move to Access2003. > I am in the process of converting an Access97 application to Access2003. > Code that I have used for years to change the page orientation on a > preview report in Access97 no longer seems to work. I have a little > freebie DELL printer that came with the machine. If I set the printer > default to Landscape then I cannot change it to Portrait when previewing > a report and vica versa. I have downloaded examples from Microsoft, I > can change the page size but not the orientation. Before I start moving > printers around I just thought I would ask, could this be a printer > specific problem I am running into here? > Thank you. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 26 22:19:21 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 23:19:21 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <000001c7cff7$fb2a8cd0$6400a8c0@dsunit1> Message-ID: <20070727031936.09CF7BCE5@smtp-auth.no-ip.com> LOL. OK ok, I give in. Charlotte rocks, and is quite correct on all counts. I hereby swear to never again willfully misrepresent her responses. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian Sent: Thursday, July 26, 2007 10:44 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I'll drink to that... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 26, 2007 7:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Charlotte, You rock. On 7/27/07, Charlotte Foust wrote: > > Ah, yes, the classic AccessD method for conquering opposition: > willfully misinterpret the responses, deny them any validity, and > declare yourself the winner! Widely used by Colby and by Drew on > occasion. It amounts to "never mind if we're saying much the same > thing, you're WRONG!!" LOL > > Charlotte Foust > > -- 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 anitatiedemann at gmail.com Fri Jul 27 00:09:19 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Fri, 27 Jul 2007 15:09:19 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070727031936.09CF7BCE5@smtp-auth.no-ip.com> References: <000001c7cff7$fb2a8cd0$6400a8c0@dsunit1> <20070727031936.09CF7BCE5@smtp-auth.no-ip.com> Message-ID: On a totally off-topic note - after all it is Friday. Congratulations on becoming a father John. I checked out your website. Your kids look adorable. Anita On 7/27/07, jwcolby wrote: > > LOL. > > OK ok, I give in. Charlotte rocks, and is quite correct on all counts. I > hereby swear to never again willfully misrepresent her responses. > > ;-) > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian > Sent: Thursday, July 26, 2007 10:44 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Primary Key Best Practices > > I'll drink to that... > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith > Sent: Thursday, July 26, 2007 7:27 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Primary Key Best Practices > > Charlotte, > You rock. > > > On 7/27/07, Charlotte Foust wrote: > > > > Ah, yes, the classic AccessD method for conquering opposition: > > willfully misinterpret the responses, deny them any validity, and > > declare yourself the winner! Widely used by Colby and by Drew on > > occasion. It amounts to "never mind if we're saying much the same > > thing, you're WRONG!!" LOL > > > > Charlotte Foust > > > > > -- > 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 jwcolby at colbyconsulting.com Fri Jul 27 00:30:12 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 27 Jul 2007 01:30:12 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070727053027.AF074BBF6@smtp-auth.no-ip.com> LOL. They don't look like that at all any more. Robbie is a skinny handsome little guy of 6 years old and Allie is now 4. I really should get some updated photos up there. And thanks, being their father is a gift like no other. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Friday, July 27, 2007 1:09 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On a totally off-topic note - after all it is Friday. Congratulations on becoming a father John. I checked out your website. Your kids look adorable. Anita On 7/27/07, jwcolby wrote: > > LOL. > > OK ok, I give in. Charlotte rocks, and is quite correct on all > counts. I hereby swear to never again willfully misrepresent her responses. > > ;-) > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian > Sent: Thursday, July 26, 2007 10:44 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Primary Key Best Practices > > I'll drink to that... > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith > Sent: Thursday, July 26, 2007 7:27 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Primary Key Best Practices > > Charlotte, > You rock. > > > On 7/27/07, Charlotte Foust wrote: > > > > Ah, yes, the classic AccessD method for conquering opposition: > > willfully misinterpret the responses, deny them any validity, and > > declare yourself the winner! Widely used by Colby and by Drew on > > occasion. It amounts to "never mind if we're saying much the same > > thing, you're WRONG!!" LOL > > > > Charlotte Foust > > > > > -- > 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 shamil at users.mns.ru Fri Jul 27 03:28:33 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Fri, 27 Jul 2007 12:28:33 +0400 Subject: [AccessD] Urgent request for a quick tip: How to switch off "View or function is not updatable because the modification affects multiple base tables" Message-ID: <000001c7d028$1ecc8e60$6401a8c0@nant> Hi All, I have an issue with MS SQL 2005/Express here: I wanted to create a stored procedure definition for it, which uses insert against non updatable query. When I'm trying to create such a stored procedure I (obviously) get "View or function 'xxxx' is not updatable because the modification affects multiple base tables" MS SQL 2000 doesn't give me this message and quietly creates my stored procedure. I currently to not care that the stored procedure I wanted to create in MS SQL 2005/Express uses non-updatable query - IOW I just need to save my SP in MS SQL 2005 and proceed with the next tasks... I guess there should be a way to suppress the message mentioned above but I do not know currently how. Could you please give me some hints? (I'm looking in parallel in docs/google)... Of course I can just comment inserts/updates used in my SP against non-updatable queries but I do not want to go this (easy) way.... Thanks. -- Shamil From Gustav at cactus.dk Fri Jul 27 06:12:35 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Fri, 27 Jul 2007 13:12:35 +0200 Subject: [AccessD] Importing from Excel Message-ID: Hi Thomas You can open Excel from Access and run a series of Excel "macros" (VBA functions in Excel). Look up an intro here: http://databaseadvisors.com/mailman/htdig/accessd/2003-March/002956.html /gustav >>> ewaldt at gdls.com 26-07-2007 22:58 >>> Thanks, Mark (and others). That's close. What I want to know is how to apply Excel-oriented code to Excel from within Access. Is that what your code does? It looks like it does, since it references Excel objects like workbooks, cells, etc. I'll try putting my code into your context. Thanks, again. Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems From iggy at nanaimo.ark.com Fri Jul 27 08:15:09 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Fri, 27 Jul 2007 06:15:09 -0700 Subject: [AccessD] Page Orientation 2003 Message-ID: <46A9EFDD.80004@nanaimo.ark.com> Hey Michael Thanks No error messages. I think it has to be a printer problem or I am missing a turn off/turn on setting in Access2003. If I set the printer (Dell Photo Printer 720) preferences, to letter 8 1/2 by 11, portrait. Then go into the design mode for a report (in Access98) that was set to letter and landscape, select page setup the orientaion is set to portrait and if I click landscape then exit (and don't do anything) and go back in, it is back to portrait and vice a versa if I set preferences to landscape and open a report that was set to portrait. I tried the code below for 2003, I downloaded from Microsoft, but it doesn't fire off the orientation setting still stays as portrait. Dim rpt As Access.Report Dim prtr As Access.Printer Set Application.Printer = Nothing Set prtr = Application.Printer 'Set the default printer's orientation to landscape prtr.Orientation = acPRORLandscape 'Set the default printer's paper size to legal prtr.PaperSize = acPRPSLegal 'Print Preview the Client Report DoCmd.OpenReport "client", acPreview Set rpt = Reports("client") 'Set the Printer property of the report to the 'Application.Printer object Set rpt.Printer = prtr 'Uncomment the following line if you wish to save the object 'with the current settings 'DoCmd.Save acReport, "Client" I hope I have not pulled off a "bonehead" manuever in my upgrading. Thanks Again From fuller.artful at gmail.com Fri Jul 27 08:46:10 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 27 Jul 2007 09:46:10 -0400 Subject: [AccessD] Page Orientation 2003 In-Reply-To: <46A9EFDD.80004@nanaimo.ark.com> References: <46A9EFDD.80004@nanaimo.ark.com> Message-ID: <29f585dd0707270646i59cf7032r4a8d874fe478ab05@mail.gmail.com> Isn't this the famous bug that concerns the setting of the AutoCorrect Spellcheck thing? On 7/27/07, Tony Septav wrote: > > Hey Michael > Thanks > No error messages. > I think it has to be a printer problem or > I am missing a turn off/turn on setting in Access2003. > > If I set the printer (Dell Photo Printer 720) preferences, to letter 8 > 1/2 by 11, portrait. > Then go into the design mode for a report (in Access98) that was set to > letter and landscape, select page setup the orientaion is set to > portrait and if I click landscape then exit (and don't do anything) and > go back in, it is back to portrait and vice a versa if I set > preferences to landscape and open a report that was set to portrait. > > I tried the code below for 2003, I downloaded from Microsoft, but it > doesn't fire off the orientation setting still stays as portrait. > > Dim rpt As Access.Report > Dim prtr As Access.Printer > > Set Application.Printer = Nothing > Set prtr = Application.Printer > > 'Set the default printer's orientation to landscape > prtr.Orientation = acPRORLandscape > > 'Set the default printer's paper size to legal > prtr.PaperSize = acPRPSLegal > > 'Print Preview the Client Report > DoCmd.OpenReport "client", acPreview > Set rpt = Reports("client") > > 'Set the Printer property of the report to the > 'Application.Printer object > Set rpt.Printer = prtr > > 'Uncomment the following line if you wish to save the object > 'with the current settings > 'DoCmd.Save acReport, "Client" > > I hope I have not pulled off a "bonehead" manuever in my upgrading. > > Thanks Again > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From iggy at nanaimo.ark.com Fri Jul 27 08:46:30 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Fri, 27 Jul 2007 06:46:30 -0700 Subject: [AccessD] Page Orientation Solved Message-ID: <46A9F736.9010206@nanaimo.ark.com> Hey All Looks like it is the printer. Tried creating new reports same problem. Then the "Duh light" came on switched the default printer to the Fax printer and set preferences to 8 1/2 by 11 and portrait. Was able to preview reports in landscape and portrait, changed paper sizes etc. Glad it was this simple, thought I was going to have to redo all the reports. Thanks. From cfoust at infostatsystems.com Fri Jul 27 10:01:22 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 27 Jul 2007 08:01:22 -0700 Subject: [AccessD] Page Orientation Solved In-Reply-To: <46A9F736.9010206@nanaimo.ark.com> References: <46A9F736.9010206@nanaimo.ark.com> Message-ID: It's a well-known issue that printer settings don't get saved appropriately when no specific printer is the selected. That's the reason we built code in our applications to set the page orientation and paper size when we formatted the report for print. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Tony Septav Sent: Friday, July 27, 2007 6:46 AM To: Access Developers discussion and problem solving Subject: [AccessD] Page Orientation Solved Hey All Looks like it is the printer. Tried creating new reports same problem. Then the "Duh light" came on switched the default printer to the Fax printer and set preferences to 8 1/2 by 11 and portrait. Was able to preview reports in landscape and portrait, changed paper sizes etc. Glad it was this simple, thought I was going to have to redo all the reports. Thanks. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Fri Jul 27 10:11:49 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 27 Jul 2007 15:11:49 +0000 Subject: [AccessD] Page Orientation 2003 In-Reply-To: <46A9EFDD.80004@nanaimo.ark.com> Message-ID: Sounds like an issue we had here...except minus Access. Are you having the same problem printing from IE...or from word...if so...you might have the wrong drivers loaded fro the printer... Good Luck, Mark >From: Tony Septav >Reply-To: Access Developers discussion and problem >solving >To: Access Developers discussion and problem >solving >Subject: [AccessD] Page Orientation 2003 >Date: Fri, 27 Jul 2007 06:15:09 -0700 > >Hey Michael >Thanks >No error messages. >I think it has to be a printer problem or >I am missing a turn off/turn on setting in Access2003. > >If I set the printer (Dell Photo Printer 720) preferences, to letter 8 >1/2 by 11, portrait. >Then go into the design mode for a report (in Access98) that was set to >letter and landscape, select page setup the orientaion is set to >portrait and if I click landscape then exit (and don't do anything) and >go back in, it is back to portrait and vice a versa if I set >preferences to landscape and open a report that was set to portrait. > >I tried the code below for 2003, I downloaded from Microsoft, but it >doesn't fire off the orientation setting still stays as portrait. > > Dim rpt As Access.Report > Dim prtr As Access.Printer > > Set Application.Printer = Nothing > Set prtr = Application.Printer > > 'Set the default printer's orientation to landscape > prtr.Orientation = acPRORLandscape > > 'Set the default printer's paper size to legal > prtr.PaperSize = acPRPSLegal > > 'Print Preview the Client Report > DoCmd.OpenReport "client", acPreview > Set rpt = Reports("client") > > 'Set the Printer property of the report to the > 'Application.Printer object > Set rpt.Printer = prtr > > 'Uncomment the following line if you wish to save the object > 'with the current settings > 'DoCmd.Save acReport, "Client" > >I hope I have not pulled off a "bonehead" manuever in my upgrading. > >Thanks Again > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01 From rockysmolin at bchacc.com Fri Jul 27 10:39:21 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 27 Jul 2007 08:39:21 -0700 Subject: [AccessD] Turning off A2007 Menus Message-ID: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> I am developing an app for a client in A2003 but he is using A2007. And (it's a legacy app) there are custom menus. Even when he turns off the toolbars, the menu is like an inch high. Take up a lot of real estate. Is there a way to reduce the vertical height of this menu? Or turn it off - he's OK with losing the custom menus because you can get to all the functions in the app through command buttons anyway. MTIA Rocky From iggy at nanaimo.ark.com Fri Jul 27 11:56:15 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Fri, 27 Jul 2007 09:56:15 -0700 Subject: [AccessD] Page Orientation 2003 Message-ID: <46AA23AF.304@nanaimo.ark.com> Thanks All Wasn't satisified with using the FAX printer so I re-installed the Dell printer and put back in my old Access97 printer setup code, and I am back up and running. I know I know, "Well why didn't you think of doing that in the first place you dummy?, stop wasting bandwidth!". Guess I can blame it on getting old and panicking to meet a Monday deadline. From robert at webedb.com Fri Jul 27 13:12:42 2007 From: robert at webedb.com (Robert L. Stewart) Date: Fri, 27 Jul 2007 13:12:42 -0500 Subject: [AccessD] Data Warehouse In-Reply-To: References: Message-ID: <200707271816.l6RIGOLF009816@databaseadvisors.com> Charlotte, In the case of a customer dimension, it would be the customer primary key from the customer table in the source. The problem comes from having multiple sources. Then you have to use a surrogate key and store the source primary key in a column along with the source name. Sorry, I have been doing it for so long, it is second nature. So, I do not really think about it. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Thu, 26 Jul 2007 13:59:09 -0700 >From: "Charlotte Foust" >Subject: Re: [AccessD] Data Warehouse (Was: Primary Key Best > Practices) >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >Yes, and I have several of Ralph Kimball's books on Data Warehouse >design and I've built a few, but what I was looking for was an >explanation of how a dimension table inherits a single column PK "from >the source primary table." I assume it means that all the distinct >values for that column that exist in the primary table have a matching >PK in the dimension table, but it took me a while to sort it out to >that, and I've *worked* with the things! > >Charlotte Foust From robert at webedb.com Fri Jul 27 13:18:53 2007 From: robert at webedb.com (Robert L. Stewart) Date: Fri, 27 Jul 2007 13:18:53 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <200707271821.l6RILNHP010961@databaseadvisors.com> Continuing off topic... My youngest son called me last night and told me that I am going to to be a grandfather. I called my fiance and told her that she was going to be a grandmother. It was the first time I have heard her speechless. She said she was too young to be a grandmother. :-) She will finally be here after all the waiting and government bull on August 14 from Yoshkar-Ola, Russia. She has a 7 year old daughter. My first. I have 3 sons 27, 22, and 22 from my first marriage. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 15:09:19 +1000 >From: "Anita Smith" >Subject: Re: [AccessD] Primary Key Best Practices >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >On a totally off-topic note - after all it is Friday. >Congratulations on becoming a father John. I checked out your website. Your >kids look adorable. From robert at webedb.com Fri Jul 27 13:21:08 2007 From: robert at webedb.com (Robert L. Stewart) Date: Fri, 27 Jul 2007 13:21:08 -0500 Subject: [AccessD] Urgent request for a quick tip In-Reply-To: References: Message-ID: <200707271823.l6RINTTx011667@databaseadvisors.com> Sorry Shamil, but commenting it out is the best you can do. They fixed the bug that allowed you to do it in 2000. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 12:28:33 +0400 >From: "Shamil Salakhetdinov" >Subject: [AccessD] Urgent request for a quick tip: How to switch off > "View or function is not updatable because the modification affects > multiple base tables" >To: "'Access-D'" >Message-ID: <000001c7d028$1ecc8e60$6401a8c0 at nant> >Content-Type: text/plain; charset="iso-8859-1" > >Hi All, > >I have an issue with MS SQL 2005/Express here: I wanted to create a stored >procedure definition for it, which uses insert against non updatable query. >When I'm trying to create such a stored procedure I (obviously) get > >"View or function 'xxxx' is not updatable because the modification affects >multiple base tables" > >MS SQL 2000 doesn't give me this message and quietly creates my stored >procedure. > >I currently to not care that the stored procedure I wanted to create in MS >SQL 2005/Express uses non-updatable query - IOW I just need to save my SP in >MS SQL 2005 and proceed with the next tasks... > >I guess there should be a way to suppress the message mentioned above but I >do not know currently how. > >Could you please give me some hints? (I'm looking in parallel in >docs/google)... > >Of course I can just comment inserts/updates used in my SP against >non-updatable queries but I do not want to go this (easy) way.... > >Thanks. > >-- >Shamil From jwcolby at colbyconsulting.com Fri Jul 27 13:40:04 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 27 Jul 2007 14:40:04 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707271821.l6RILNHP010961@databaseadvisors.com> Message-ID: <20070727184005.371B7BD3D@smtp-auth.no-ip.com> Congrats on the grandchild and congrats on you fianc?e finally getting here. Write us when she finally gets through immigration and it is all over. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Friday, July 27, 2007 2:19 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Continuing off topic... My youngest son called me last night and told me that I am going to to be a grandfather. I called my fiance and told her that she was going to be a grandmother. It was the first time I have heard her speechless. She said she was too young to be a grandmother. :-) She will finally be here after all the waiting and government bull on August 14 from Yoshkar-Ola, Russia. She has a 7 year old daughter. My first. I have 3 sons 27, 22, and 22 from my first marriage. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 15:09:19 +1000 >From: "Anita Smith" >Subject: Re: [AccessD] Primary Key Best Practices >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >On a totally off-topic note - after all it is Friday. >Congratulations on becoming a father John. I checked out your website. >Your kids look adorable. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From martyconnelly at shaw.ca Fri Jul 27 13:47:39 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Fri, 27 Jul 2007 11:47:39 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> Message-ID: <46AA3DCB.5000501@shaw.ca> If the "ribbon" takes up too much room, it's easy to hide. Just right-click on one of the ribbon tabs and choose: "Minimize the Ribbon." If you want quick access to a button found on one of the ribbons, just right-click on the button and choose: "Add to Quick Access Toolbar." Alternatively, you can get a list of all options and customize the "Quick Access Toolbar." You can easily add dozens of buttons to the toolbar. Rocky Smolin at Beach Access Software wrote: >I am developing an app for a client in A2003 but he is using A2007. And >(it's a legacy app) there are custom menus. Even when he turns off the >toolbars, the menu is like an inch high. Take up a lot of real estate. Is >there a way to reduce the vertical height of this menu? Or turn it off - >he's OK with losing the custom menus because you can get to all the >functions in the app through command buttons anyway. > >MTIA > >Rocky > > > > > > > > -- Marty Connelly Victoria, B.C. Canada From rockysmolin at bchacc.com Fri Jul 27 13:55:17 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 27 Jul 2007 11:55:17 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070727184005.371B7BD3D@smtp-auth.no-ip.com> Message-ID: <009501c7d07f$ac8c5350$0301a8c0@HAL9005> Pictures! WE WANT PICTURES!!! Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 27, 2007 11:40 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Congrats on the grandchild and congrats on you fianc?e finally getting here. Write us when she finally gets through immigration and it is all over. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Friday, July 27, 2007 2:19 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Continuing off topic... My youngest son called me last night and told me that I am going to to be a grandfather. I called my fiance and told her that she was going to be a grandmother. It was the first time I have heard her speechless. She said she was too young to be a grandmother. :-) She will finally be here after all the waiting and government bull on August 14 from Yoshkar-Ola, Russia. She has a 7 year old daughter. My first. I have 3 sons 27, 22, and 22 from my first marriage. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 15:09:19 +1000 >From: "Anita Smith" >Subject: Re: [AccessD] Primary Key Best Practices >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >On a totally off-topic note - after all it is Friday. >Congratulations on becoming a father John. I checked out your website. >Your kids look adorable. -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/921 - Release Date: 7/26/2007 11:16 PM From rockysmolin at bchacc.com Fri Jul 27 14:09:38 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 27 Jul 2007 12:09:38 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA3DCB.5000501@shaw.ca> Message-ID: <009a01c7d081$adc33ac0$0301a8c0@HAL9005> Thanks. Will forward. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly Sent: Friday, July 27, 2007 11:48 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Turning off A2007 Menus If the "ribbon" takes up too much room, it's easy to hide. Just right-click on one of the ribbon tabs and choose: "Minimize the Ribbon." If you want quick access to a button found on one of the ribbons, just right-click on the button and choose: "Add to Quick Access Toolbar." Alternatively, you can get a list of all options and customize the "Quick Access Toolbar." You can easily add dozens of buttons to the toolbar. Rocky Smolin at Beach Access Software wrote: >I am developing an app for a client in A2003 but he is using A2007. >And (it's a legacy app) there are custom menus. Even when he turns off >the toolbars, the menu is like an inch high. Take up a lot of real >estate. Is there a way to reduce the vertical height of this menu? Or >turn it off - he's OK with losing the custom menus because you can get >to all the functions in the app through command buttons anyway. > >MTIA > >Rocky > > > > > > > > -- Marty Connelly Victoria, B.C. Canada -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/921 - Release Date: 7/26/2007 11:16 PM From fuller.artful at gmail.com Fri Jul 27 14:40:15 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 27 Jul 2007 15:40:15 -0400 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA3DCB.5000501@shaw.ca> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> <46AA3DCB.5000501@shaw.ca> Message-ID: <29f585dd0707271240w6d43fbet80ef9043e7b434d4@mail.gmail.com> You may just have persuaded me to re-install Access 2007. On 7/27/07, MartyConnelly wrote: > > If the "ribbon" takes up too much room, it's easy to hide. > Just right-click on one of the ribbon tabs and choose: > "Minimize the Ribbon." If you want quick access to a button > found on one of the ribbons, just right-click on the button > and choose: "Add to Quick Access Toolbar." Alternatively, > you can get a list of all options and customize the "Quick > Access Toolbar." You can easily add dozens of buttons to the > toolbar. > From mwp.reid at qub.ac.uk Fri Jul 27 14:53:25 2007 From: mwp.reid at qub.ac.uk (Martin W Reid) Date: Fri, 27 Jul 2007 20:53:25 +0100 Subject: [AccessD] Ribbon X Message-ID: Friend of mine has developed a developer add in. See http://pschmid.net/blog/2006/10/09/58 Its not free. Martin Martin Reid Telephone: 02890974465 ________________________________________ From: accessd-bounces at databaseadvisors.com [accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software [rockysmolin at bchacc.com] Sent: 27 July 2007 20:09 To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Turning off A2007 Menus Thanks. Will forward. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly Sent: Friday, July 27, 2007 11:48 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Turning off A2007 Menus If the "ribbon" takes up too much room, it's easy to hide. Just right-click on one of the ribbon tabs and choose: "Minimize the Ribbon." If you want quick access to a button found on one of the ribbons, just right-click on the button and choose: "Add to Quick Access Toolbar." Alternatively, you can get a list of all options and customize the "Quick Access Toolbar." You can easily add dozens of buttons to the toolbar. Rocky Smolin at Beach Access Software wrote: >I am developing an app for a client in A2003 but he is using A2007. >And (it's a legacy app) there are custom menus. Even when he turns off >the toolbars, the menu is like an inch high. Take up a lot of real >estate. Is there a way to reduce the vertical height of this menu? Or >turn it off - he's OK with losing the custom menus because you can get >to all the functions in the app through command buttons anyway. > >MTIA > >Rocky > > > > > > > > -- Marty Connelly Victoria, B.C. Canada -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/921 - Release Date: 7/26/2007 11:16 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Fri Jul 27 15:27:55 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 28 Jul 2007 08:27:55 +1200 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> Message-ID: <46AA554B.6020908@mvps.org> Rocky, It is very easy to hide the Ribbon and use your custom menus in Access 2007. Some instructions about this here: http://blog.datamanagementsolutions.biz/2007/07/custom-toolbars-2007.html Regards Steve Rocky Smolin at Beach Access Software wrote: > I am developing an app for a client in A2003 but he is using A2007. And > (it's a legacy app) there are custom menus. Even when he turns off the > toolbars, the menu is like an inch high. Take up a lot of real estate. Is > there a way to reduce the vertical height of this menu? Or turn it off - > he's OK with losing the custom menus because you can get to all the > functions in the app through command buttons anyway. From miscellany at mvps.org Fri Jul 27 16:03:45 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 28 Jul 2007 09:03:45 +1200 Subject: [AccessD] Creating HTML file Message-ID: <46AA5DB1.1010000@mvps.org> Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve From ebarro at verizon.net Fri Jul 27 16:17:18 2007 From: ebarro at verizon.net (Eric Barro) Date: Fri, 27 Jul 2007 14:17:18 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> Message-ID: <0JLU00BORWHWHFH5@vms044.mailsrvcs.net> Steve, Grab any HTML editor that generates HTML (preferably drag and drop) and design your page and save it as an HTML file. And then you can open it with Notepad and use the generated HTML source code. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Fri Jul 27 16:20:31 2007 From: john at winhaven.net (John Bartow) Date: Fri, 27 Jul 2007 16:20:31 -0500 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> References: <46AA5DB1.1010000@mvps.org> Message-ID: <055b01c7d093$f76b4200$6402a8c0@ScuzzPaq> I've tried without success. So essentially I'm replying to add full to the fire. I still want to do this. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Fri Jul 27 16:40:44 2007 From: john at winhaven.net (John Bartow) Date: Fri, 27 Jul 2007 16:40:44 -0500 Subject: [AccessD] HTML from Access Report (was mistakenly stolen from: Creating HTML file) In-Reply-To: <0JLU00BORWHWHFH5@vms044.mailsrvcs.net> References: <46AA5DB1.1010000@mvps.org> <0JLU00BORWHWHFH5@vms044.mailsrvcs.net> Message-ID: <056501c7d096$ca011990$6402a8c0@ScuzzPaq> Hi Eric, I guess I'm not after quite the same thing as Steve (so sorry I chimed in on your thread Steve, I'll rename mine). I had tried something of this sort with A97 and it didn't work. Now obviously things have changed a lot since then but could you please elaborate a bit on this. What I wish to do is to run a process that creates static html pages from data stored in the database and places them into a folder (which is used by FrontPage). There two approaches I have considered: Write out a text file and use FP VBA to manipulate it into using the default css theme. Or (since I know the css tags) embed the tags directly into the data output from Access. (I would prefer this as I have no desire to learn FP's object model, as it is a dead horse now). I was thinking (hoping, really) that I could do this with a report and use labels (or eventually a lookup table and text fields) to embed the html/css code. I would then output these reports to the folder of choice using the windows generic text only printer. Any thoughts on this? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Friday, July 27, 2007 4:17 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Creating HTML file Steve, Grab any HTML editor that generates HTML (preferably drag and drop) and design your page and save it as an HTML file. And then you can open it with Notepad and use the generated HTML source code. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. 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 rockysmolin at bchacc.com Fri Jul 27 16:43:22 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 27 Jul 2007 14:43:22 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA554B.6020908@mvps.org> Message-ID: <00c201c7d097$27aae9e0$0301a8c0@HAL9005> Thanks Steve. I'll forward to the client. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 1:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Turning off A2007 Menus Rocky, It is very easy to hide the Ribbon and use your custom menus in Access 2007. Some instructions about this here: http://blog.datamanagementsolutions.biz/2007/07/custom-toolbars-2007.html Regards Steve Rocky Smolin at Beach Access Software wrote: > I am developing an app for a client in A2003 but he is using A2007. > And (it's a legacy app) there are custom menus. Even when he turns > off the toolbars, the menu is like an inch high. Take up a lot of > real estate. Is there a way to reduce the vertical height of this > menu? Or turn it off - he's OK with losing the custom menus because > you can get to all the functions in the app through command buttons anyway. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/921 - Release Date: 7/26/2007 11:16 PM From krosenstiel at comcast.net Fri Jul 27 16:45:42 2007 From: krosenstiel at comcast.net (Karen Rosenstiel) Date: Fri, 27 Jul 2007 14:45:42 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> Message-ID: <200707272145.l6RLjYgq003194@databaseadvisors.com> I've done lots of work in (X)HTML, but never in this way. Why can't you design a template that can then be filled by a database? (AKA ASP or PHP) You need a lot of header information to make a good web page and a touch of JavaScript to add some class. Regards, Karen Rosenstiel Seattle WA USA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From martyconnelly at shaw.ca Fri Jul 27 17:11:04 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Fri, 27 Jul 2007 15:11:04 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA554B.6020908@mvps.org> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> <46AA554B.6020908@mvps.org> Message-ID: <46AA6D78.2040609@shaw.ca> This method applies to the particular database opened as opposed to method for Access platform overall that I stated. So choose your poison. There must be a way to do in VBA code. Steve Schapel wrote: >Rocky, > >It is very easy to hide the Ribbon and use your custom menus in Access >2007. Some instructions about this here: >http://blog.datamanagementsolutions.biz/2007/07/custom-toolbars-2007.html > >Regards >Steve > > >Rocky Smolin at Beach Access Software wrote: > > >>I am developing an app for a client in A2003 but he is using A2007. And >>(it's a legacy app) there are custom menus. Even when he turns off the >>toolbars, the menu is like an inch high. Take up a lot of real estate. Is >>there a way to reduce the vertical height of this menu? Or turn it off - >>he's OK with losing the custom menus because you can get to all the >>functions in the app through command buttons anyway. >> >> -- Marty Connelly Victoria, B.C. Canada From nd500_lo at charter.net Fri Jul 27 17:19:51 2007 From: nd500_lo at charter.net (Dian) Date: Fri, 27 Jul 2007 15:19:51 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707271821.l6RILNHP010961@databaseadvisors.com> References: <200707271821.l6RILNHP010961@databaseadvisors.com> Message-ID: <000301c7d09c$407a7030$6400a8c0@dsunit1> Congratulations on all of the exciting new experiences on your horizon! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Friday, July 27, 2007 11:19 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Continuing off topic... My youngest son called me last night and told me that I am going to to be a grandfather. I called my fiance and told her that she was going to be a grandmother. It was the first time I have heard her speechless. She said she was too young to be a grandmother. :-) She will finally be here after all the waiting and government bull on August 14 from Yoshkar-Ola, Russia. She has a 7 year old daughter. My first. I have 3 sons 27, 22, and 22 from my first marriage. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 15:09:19 +1000 >From: "Anita Smith" >Subject: Re: [AccessD] Primary Key Best Practices >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >On a totally off-topic note - after all it is Friday. >Congratulations on becoming a father John. I checked out your website. >Your kids look adorable. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ebarro at verizon.net Fri Jul 27 17:48:47 2007 From: ebarro at verizon.net (Eric Barro) Date: Fri, 27 Jul 2007 15:48:47 -0700 Subject: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) In-Reply-To: <056501c7d096$ca011990$6402a8c0@ScuzzPaq> Message-ID: <0JLV00MHY0QGZ6AE@vms040.mailsrvcs.net> John/Steve, Here's the code I used a while back when I was still developing in Access 97. If I was doing this today I'd probably re-write the code and make it more modular and use cascading style sheets for formatting. The basic format for any HTML file is... Page Title I would not hard-code any javascript or css but instead link to them at runtime as I've shown above in the section. Pay special attention to the construct """. In most cases you can use "'" instead. ---------------------------------------------------------------------------- ------------------------ Private Sub CreateHTMLFile(strHTMLFileName As String, strImage1 As String, strImage2 As String, strDesc1 As String, strDesc2 As String, strInsured As String, strPolicy As String) Open strHTMLFileName For Output As #1 Print #1, "" Print #1, "" Print #1, "" Print #1, "Photo Template" Print #1, "" Print #1, "" Print #1, "" Print #1, "
" Print #1, "
" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "
" Print #1, "
" & strInsured & "
" Print #1, "
" Print #1, "
" Print #1, "
" & strPolicy & "
" Print #1, "
" Print #1, "
" Print #1, "
" Print #1, "
" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" 'Print #1, "" ' Print #1, "" ' Print #1, "" ' Print #1, "" 'Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "
  
 " & strDesc1 & " 
   
  
 " & strDesc2 & " 
" Print #1, "
" Print #1, "" Print #1, "" Close #1 End Sub ---------------------------------------------------------------------------- ------------------------ Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Friday, July 27, 2007 2:41 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) Hi Eric, I guess I'm not after quite the same thing as Steve (so sorry I chimed in on your thread Steve, I'll rename mine). I had tried something of this sort with A97 and it didn't work. Now obviously things have changed a lot since then but could you please elaborate a bit on this. What I wish to do is to run a process that creates static html pages from data stored in the database and places them into a folder (which is used by FrontPage). There two approaches I have considered: Write out a text file and use FP VBA to manipulate it into using the default css theme. Or (since I know the css tags) embed the tags directly into the data output from Access. (I would prefer this as I have no desire to learn FP's object model, as it is a dead horse now). I was thinking (hoping, really) that I could do this with a report and use labels (or eventually a lookup table and text fields) to embed the html/css code. I would then output these reports to the folder of choice using the windows generic text only printer. Any thoughts on this? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Friday, July 27, 2007 4:17 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Creating HTML file Steve, Grab any HTML editor that generates HTML (preferably drag and drop) and design your page and save it as an HTML file. And then you can open it with Notepad and use the generated HTML source code. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/922 - Release Date: 7/27/2007 6:08 AM From martyconnelly at shaw.ca Fri Jul 27 18:02:35 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Fri, 27 Jul 2007 16:02:35 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> References: <46AA5DB1.1010000@mvps.org> Message-ID: <46AA798B.1060706@shaw.ca> Here is how I write out an HTML file with contained javascript (so ignore it ) To put a basic table into HTML http://www.w3schools.com/html/html_tables.asp You may be able to do easier via Bind Data Island to HTML Elements. http://www.w3schools.com/xml/tryit.asp?filename=cd_catalog_island_thead Function createhtmlroute(strStreetAddressFrom As String, strStreetAddressTo As String, lVersion As Long) As String Dim strHTML As String strHTML = "" strHTML = strHTML & "Route Microsoft To Area 51 Virtual Earth Map" ' strHTML = strHTML & "" 'When your page has referenced the map control, set up the call to display a default map by completing a LoadMap ( ) method call: 'try newer Virtual Earth control 4.0 Beta If lVersion Then strHTML = strHTML & vbCrLf & " " Else strHTML = strHTML & vbCrLf & " " End If ' strHTML = strHTML & vbCrLf & "" strHTML = strHTML & vbCrLf & "" 'Last, you display the map: strHTML = strHTML & vbCrLf & "" strHTML = strHTML & vbCrLf & "
" strHTML = strHTML & vbCrLf & " Delay for Route Info: mouseover way stations " strHTML = strHTML & vbCrLf & "" strHTML = strHTML & vbCrLf & "" WriteFile CurrentDBDir & "route.html", strHTML createhtmlroute = strHTML End Function Sub WriteFile(ByVal sFileName As String, ByVal sContents As String) ' Dump XML or html String to File for debugging Dim fhFile As Integer fhFile = FreeFile ' Debug.Print "Length of string=" & Len(sContents) Open sFileName For Output As #fhFile Print #fhFile, sContents; Close #fhFile Debug.Print "Out File" & sFileName End Sub Steve Schapel wrote: >Hi. I am just about to do something I have never tried before. I need >to create a static web page from Access data. Using OutputTo from a >report has too many problems. Using DoCmd.TransferText acExportHTML >doesn't give me the formatting flexibility that I need. Therefore I've >decided to try to loop through a recordset and build the html file in >code. Main problem being that my html skills are minimal. Has anyone >done this type of thing? Any tips? Thanks. > >Regards >Steve > > -- Marty Connelly Victoria, B.C. Canada From dw-murphy at cox.net Fri Jul 27 18:27:21 2007 From: dw-murphy at cox.net (Doug Murphy) Date: Fri, 27 Jul 2007 16:27:21 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> Message-ID: <002b01c7d0a5$ae586b80$0200a8c0@murphy3234aaf1> Hi Steve, I do this quite a bit. What I do is to create the skeleton of the html page in my html editor, Dream Weaver. I embed tags in the page where I want Access to insert specific current data, like the date the page was updated. The tag I use looks like an html comment, i.e., "" The text part of the tag allows me to insert in that spot. I then use this file as a template. When I want to create a page I open the template file from Access and open a new file to output to. The routine then iterates trough the template file, inserting data where required and then outputting the lines to the output file. For this application the majority of the data goes into a table so I put a tag where the table goes and input data from a record set into the table with the appropriate table, table row and cell tags. I got the basic routine from some one on this list several years ago. The routine I use follows. ---Code follows--- Sub sWriteHTMLReport(strTemplateFile As String, strFinalReportFile As String, rst As DAO.Recordset) Dim intFFIn As Integer Dim intFFOut As Integer Dim strLine As String Dim iCount As Integer Dim sField As String 'Get Free File Handle for working with template.html intFFIn = FreeFile 'Open temp.htm for read only using Free File handle Open strTemplateFile For Input Access Read As #intFFIn 'Get Free File Handle for working with report.html ' report.html is the output file intFFOut = FreeFile 'Open report.html for writing Open strFinalReportFile For Output Access Write As #intFFOut 'Do 'Insert update date Do ' Read Line from template.html Input #intFFIn, strLine ' If Line = then date goes here If strLine = "" Then ' Exit Loop strLine = "(Last Updated: " & Format(Date, "mmmm dd, yyyy") & ")" ' If Line = " Then ' Exit Loop Exit Do ' End If End If ' Write Line to report.html Print #intFFOut, strLine 'Loop While Not EOF ' just to make sure that you don't get errors if you Loop While Not (EOF(intFFIn)) 'forget to add the comment 'open Data recordset 'Recordset passed instead of opening her to make it a bit more generic 'Do Do ' Build OutPutString by iterating through the field collection and adding fields to the string strLine = "" For iCount = 0 To rst.Fields.Count - 1 'Check to see if the field is null and if so put in a Line break If IsNull(rst.Fields(iCount).Value) Then sField = "
" Else sField = rst.Fields(iCount).Value End If strLine = strLine & "" & sField & "" Next iCount 'Trim off the last strLine = Mid(strLine, 1, Len(strLine) - 5) 'Add the end of row tag strLine = strLine & "" ' write output string to report.html Print #intFFOut, strLine ' Move to Next Record rst.MoveNext 'loop while there are still records in the recordset Loop While Not (rst.EOF) 'do while not End Of template.html (the condition needs to go at the top in case you forgot to add the comment) Do While Not (EOF(intFFIn)) ' Read Line from template.html Input #intFFIn, strLine ' Write Line to report.html Print #intFFOut, strLine 'Loop Loop ' 'Close Report.html 'Close template.html Close End Sub ----End code---------- If you just want to insert a few pieces of data in specific locations you could just copy the template file into a string and use replace to locate the tags and insert the values. After inserting all data you would save the string to a new file. Hope this helps. I don't remember who helped me out, but am glad to share. Doug -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Fri Jul 27 19:41:28 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 28 Jul 2007 12:41:28 +1200 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA6D78.2040609@shaw.ca> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> <46AA554B.6020908@mvps.org> <46AA6D78.2040609@shaw.ca> Message-ID: <46AA90B8.4070106@mvps.org> That's right, Marty. I was just relating to the specific case of wanting to use custom menus within a specific application running in Access 2007. Regards Steve MartyConnelly wrote: > This method applies to the particular database opened as opposed to method > for Access platform overall that I stated. So choose your poison. > There must be a way to do in VBA code. From miscellany at mvps.org Sat Jul 28 04:01:57 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 28 Jul 2007 21:01:57 +1200 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> References: <46AA5DB1.1010000@mvps.org> Message-ID: <46AB0605.8060706@mvps.org> My sincere thanks to everyone who contributed to this thread. I pieced together a lot of the information you gave, plus a bit of "trial and error", and I am happy to say that I have now achieved what I wanted. Regards Steve From DWUTKA at Marlow.com Sat Jul 28 19:55:25 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Sat, 28 Jul 2007 19:55:25 -0500 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> Message-ID: I know I'm late to the party on this, but why must it be a static web page. Making dynamic pages with asp is a snap. Create the HTML in any editor you want. Then save it as an ASP page. <% Dim cnn Dim rs Dim strSQL Set cnn=server.createobject("ADODB.Connection") Set rs=server.createobject("ADODB.Connecion") strSQL="Your SQL string to get the data... 'Then connect the cnn, and open the recordset %> You now have a recordset open in asp. To use this, you can just put asp in the middle of the HTML. For example, if you have:

The current value is 1

And you want to make that 1 a value from your recordset:

The current value is <%=rs.fields("NumericValue").value%>

Whalla. You can also do conditional formatting: <% if rs.fields("SomeField").value="SomeValue"%>

Some paragraph in the HTML document

<%else%>

Some other paragraph

<%end if%> You can also loop this way, for example, if you want a table with your data: <%Do until rs.EOF=True%> <%For i=0 to 4 'just assuming 5 fields%> <%next%> <%rs.movenext%> <%loop%>
<%=rs.fields(i).Value%>
You mentioned Frontpage, one of the handy things about Front page is that if you select something in the 'design view', when you switch to the HTML view, the HTML of the selected area will be highlighted too. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From ebarro at verizon.net Sat Jul 28 20:30:02 2007 From: ebarro at verizon.net (Eric Barro) Date: Sat, 28 Jul 2007 18:30:02 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: Message-ID: <0JLX00K962U4VBB5@vms044.mailsrvcs.net> Probably because an ASP page needs a web server in order to process and display the pages whereas a straight HTML page can be displayed directly by the browser without a need for a web server. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Saturday, July 28, 2007 5:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Creating HTML file I know I'm late to the party on this, but why must it be a static web page. Making dynamic pages with asp is a snap. Create the HTML in any editor you want. Then save it as an ASP page. <% Dim cnn Dim rs Dim strSQL Set cnn=server.createobject("ADODB.Connection") Set rs=server.createobject("ADODB.Connecion") strSQL="Your SQL string to get the data... 'Then connect the cnn, and open the recordset %> You now have a recordset open in asp. To use this, you can just put asp in the middle of the HTML. For example, if you have:

The current value is 1

And you want to make that 1 a value from your recordset:

The current value is <%=rs.fields("NumericValue").value%>

Whalla. You can also do conditional formatting: <% if rs.fields("SomeField").value="SomeValue"%>

Some paragraph in the HTML document

<%else%>

Some other paragraph

<%end if%> You can also loop this way, for example, if you want a table with your data: <%Do until rs.EOF=True%> <%For i=0 to 4 'just assuming 5 fields%> <%next%> <%rs.movenext%> <%loop%>
<%=rs.fields(i).Value%>
You mentioned Frontpage, one of the handy things about Front page is that if you select something in the 'design view', when you switch to the HTML view, the HTML of the selected area will be highlighted too. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/923 - Release Date: 7/27/2007 6:01 PM From ebarro at verizon.net Sat Jul 28 20:33:17 2007 From: ebarro at verizon.net (Eric Barro) Date: Sat, 28 Jul 2007 18:33:17 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: Message-ID: <0JLX00MUA2ZFZ65I@vms040.mailsrvcs.net> If you go this route don't forget to clean up with the following code. Otherwise you don't release the allocated memory and resources back to the server. <% rs.Close Set rs = Nothing cnn.Close Set cnn = Nothing %> -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Saturday, July 28, 2007 5:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Creating HTML file I know I'm late to the party on this, but why must it be a static web page. Making dynamic pages with asp is a snap. Create the HTML in any editor you want. Then save it as an ASP page. <% Dim cnn Dim rs Dim strSQL Set cnn=server.createobject("ADODB.Connection") Set rs=server.createobject("ADODB.Connecion") strSQL="Your SQL string to get the data... 'Then connect the cnn, and open the recordset %> You now have a recordset open in asp. To use this, you can just put asp in the middle of the HTML. For example, if you have:

The current value is 1

And you want to make that 1 a value from your recordset:

The current value is <%=rs.fields("NumericValue").value%>

Whalla. You can also do conditional formatting: <% if rs.fields("SomeField").value="SomeValue"%>

Some paragraph in the HTML document

<%else%>

Some other paragraph

<%end if%> You can also loop this way, for example, if you want a table with your data: <%Do until rs.EOF=True%> <%For i=0 to 4 'just assuming 5 fields%> <%next%> <%rs.movenext%> <%loop%>
<%=rs.fields(i).Value%>
You mentioned Frontpage, one of the handy things about Front page is that if you select something in the 'design view', when you switch to the HTML view, the HTML of the selected area will be highlighted too. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/923 - Release Date: 7/27/2007 6:01 PM From BarbaraRyan at cox.net Sun Jul 29 10:31:17 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Sun, 29 Jul 2007 11:31:17 -0400 Subject: [AccessD] Grid Control Message-ID: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> I would like to use a data grid control in Access for data entry. Any suggestions? Free is best :-) Thanks, Barb Ryan From accessd at shaw.ca Sun Jul 29 12:32:12 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 29 Jul 2007 10:32:12 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <0JLY00KBTB66VOV2@l-daemon> Well said Charlotte. To give ground is dishonorable and it death before dishonor. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 9:28 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 kost36 at otenet.gr Sun Jul 29 12:57:07 2007 From: kost36 at otenet.gr (Kostas Konstantinidis) Date: Sun, 29 Jul 2007 20:57:07 +0300 Subject: [AccessD] Captioning attachments in msaccess 2007.. In-Reply-To: <6C1791BC61725F44A28C24208026A511126301@karta-exc-int.Karta.com> References: <023901c79eae$2fd7abf0$6401a8c0@kost36><000501c79f60$d003df60$03b0d355@minster33c3r25><6C1791BC61725F44A28C24208026A51112629C@karta-exc-int.Karta.com><128ED29B1D0C4920AA783BECC6E0551B@kost36PC> <6C1791BC61725F44A28C24208026A511126301@karta-exc-int.Karta.com> Message-ID: <978550B175D04FA8BCDBBCFA4BB74CCE@kost36PC> is that possible with any way to get different captions for different attachment images? Thank you /kostas From DWUTKA at Marlow.com Sun Jul 29 15:00:13 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Sun, 29 Jul 2007 15:00:13 -0500 Subject: [AccessD] Creating HTML file In-Reply-To: <0JLX00K962U4VBB5@vms044.mailsrvcs.net> Message-ID: That is true, but every Windows OS since 98 has a webserver in it. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Saturday, July 28, 2007 8:30 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Creating HTML file Probably because an ASP page needs a web server in order to process and display the pages whereas a straight HTML page can be displayed directly by the browser without a need for a web server. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Saturday, July 28, 2007 5:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Creating HTML file I know I'm late to the party on this, but why must it be a static web page. Making dynamic pages with asp is a snap. Create the HTML in any editor you want. Then save it as an ASP page. <% Dim cnn Dim rs Dim strSQL Set cnn=server.createobject("ADODB.Connection") Set rs=server.createobject("ADODB.Connecion") strSQL="Your SQL string to get the data... 'Then connect the cnn, and open the recordset %> You now have a recordset open in asp. To use this, you can just put asp in the middle of the HTML. For example, if you have:

The current value is 1

And you want to make that 1 a value from your recordset:

The current value is <%=rs.fields("NumericValue").value%>

Whalla. You can also do conditional formatting: <% if rs.fields("SomeField").value="SomeValue"%>

Some paragraph in the HTML document

<%else%>

Some other paragraph

<%end if%> You can also loop this way, for example, if you want a table with your data: <%Do until rs.EOF=True%> <%For i=0 to 4 'just assuming 5 fields%> <%next%> <%rs.movenext%> <%loop%>
<%=rs.fields(i).Value%>
You mentioned Frontpage, one of the handy things about Front page is that if you select something in the 'design view', when you switch to the HTML view, the HTML of the selected area will be highlighted too. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/923 - Release Date: 7/27/2007 6:01 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From miscellany at mvps.org Sun Jul 29 15:44:49 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 30 Jul 2007 08:44:49 +1200 Subject: [AccessD] Creating HTML file In-Reply-To: References: Message-ID: <46ACFC41.5030305@mvps.org> Drew, I think it is very difficult to generalise, as the specific requirements will vary so much from case to case. In my situation, which prompted my original question in this thread, I am working with a distributed application, the users of which have all sorts of different circumstances. The reports in question contain data which changes very infrequently. For me, the desired outcome was for the users of my application to be able to export on demand, their data from their local desktop application to static html pages, and then to incorporate these pages into their own websites in whichever way they see fit. Therefore, in my case, dynamic pages and ASP don't come into the picture at all. On the other hand, your suggestion may well be very applicable in another scenario. Regards Steve Drew Wutka wrote: > That is true, but every Windows OS since 98 has a webserver in it. > From martyconnelly at shaw.ca Sun Jul 29 16:17:23 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Sun, 29 Jul 2007 14:17:23 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46ACFC41.5030305@mvps.org> References: <46ACFC41.5030305@mvps.org> Message-ID: <46AD03E3.9010508@shaw.ca> Windows Home versions doesn't have IIS or webserver available If you do Dynamic SQL queries you will need a lot of vbscript code in your html to protect against SQL Injection attacks. I would also use at least Jet Version 8.0 that allows sandbox protection against illegal functions inside the SQL string Steve Schapel wrote: >Drew, > >I think it is very difficult to generalise, as the specific requirements >will vary so much from case to case. In my situation, which prompted my >original question in this thread, I am working with a distributed >application, the users of which have all sorts of different >circumstances. The reports in question contain data which changes very >infrequently. For me, the desired outcome was for the users of my >application to be able to export on demand, their data from their local >desktop application to static html pages, and then to incorporate these >pages into their own websites in whichever way they see fit. Therefore, >in my case, dynamic pages and ASP don't come into the picture at all. >On the other hand, your suggestion may well be very applicable in >another scenario. > >Regards >Steve > >Drew Wutka wrote: > > >>That is true, but every Windows OS since 98 has a webserver in it. >> >> >> -- Marty Connelly Victoria, B.C. Canada From john at winhaven.net Sun Jul 29 16:52:46 2007 From: john at winhaven.net (John Bartow) Date: Sun, 29 Jul 2007 16:52:46 -0500 Subject: [AccessD] Creating HTML file In-Reply-To: References: <46AA5DB1.1010000@mvps.org> Message-ID: <009901c7d22a$cdc33410$6402a8c0@ScuzzPaq> Drew, Its all a matter of customer scope, needs, focus and budget. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Saturday, July 28, 2007 7:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Creating HTML file I know I'm late to the party on this, but why must it be a static web page. From john at winhaven.net Sun Jul 29 16:52:46 2007 From: john at winhaven.net (John Bartow) Date: Sun, 29 Jul 2007 16:52:46 -0500 Subject: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) In-Reply-To: <0JLV00MHY0QGZ6AE@vms040.mailsrvcs.net> References: <056501c7d096$ca011990$6402a8c0@ScuzzPaq> <0JLV00MHY0QGZ6AE@vms040.mailsrvcs.net> Message-ID: <009801c7d22a$cd2853a0$6402a8c0@ScuzzPaq> Eric, Thank You. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Friday, July 27, 2007 5:49 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) John/Steve, Here's the code I used a while back when I was still developing in Access 97. If I was doing this today I'd probably re-write the code and make it more modular and use cascading style sheets for formatting. The basic format for any HTML file is... Page Title I would not hard-code any javascript or css but instead link to them at runtime as I've shown above in the section. Pay special attention to the construct """. In most cases you can use "'" instead. ---------------------------------------------------------------------------- ------------------------ Private Sub CreateHTMLFile(strHTMLFileName As String, strImage1 As String, strImage2 As String, strDesc1 As String, strDesc2 As String, strInsured As String, strPolicy As String) Open strHTMLFileName For Output As #1 Print #1, "" Print #1, "" Print #1, "" Print #1, "Photo Template" Print #1, "" Print #1, "" Print #1, "" Print #1, "
" Print #1, "
" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "
" Print #1, "
" & strInsured & "
" Print #1, "
" Print #1, "
" Print #1, "
" & strPolicy & "
" Print #1, "
" Print #1, "
" Print #1, "
" Print #1, "
" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" 'Print #1, "" ' Print #1, "" ' Print #1, "" ' Print #1, "" 'Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "
  
 " & strDesc1 & " 
   
  
 " & strDesc2 & " 
" Print #1, "
" Print #1, "" Print #1, "" Close #1 End Sub ---------------------------------------------------------------------------- ------------------------ Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Friday, July 27, 2007 2:41 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) Hi Eric, I guess I'm not after quite the same thing as Steve (so sorry I chimed in on your thread Steve, I'll rename mine). I had tried something of this sort with A97 and it didn't work. Now obviously things have changed a lot since then but could you please elaborate a bit on this. What I wish to do is to run a process that creates static html pages from data stored in the database and places them into a folder (which is used by FrontPage). There two approaches I have considered: Write out a text file and use FP VBA to manipulate it into using the default css theme. Or (since I know the css tags) embed the tags directly into the data output from Access. (I would prefer this as I have no desire to learn FP's object model, as it is a dead horse now). I was thinking (hoping, really) that I could do this with a report and use labels (or eventually a lookup table and text fields) to embed the html/css code. I would then output these reports to the folder of choice using the windows generic text only printer. Any thoughts on this? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Friday, July 27, 2007 4:17 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Creating HTML file Steve, Grab any HTML editor that generates HTML (preferably drag and drop) and design your page and save it as an HTML file. And then you can open it with Notepad and use the generated HTML source code. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/922 - Release Date: 7/27/2007 6:08 AM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From darrend at nimble.com.au Sun Jul 29 18:29:33 2007 From: darrend at nimble.com.au (Darren D) Date: Mon, 30 Jul 2007 09:29:33 +1000 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files Message-ID: <200707292358.l6TNwXBk026421@databaseadvisors.com> Hi all I am calling a batch file from my access app The batch file just 'merges' a few files into one big file and then gives it a name This is the batch file - Very basic - 1 liner - copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt mynewcoolcombinedfile.XML Pretty basic - but the combining leaves a small ascii type square as the very very last character - Like this ---> Anyone know how to stop this from happening? Or even better - How to 'build' or merge a few files into one big file - from VBA Or even better still - How to insert Text eg Merge "This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into OneCoolFile.XML Many thanks in advance DD From prodevmg at yahoo.com Sun Jul 29 21:18:32 2007 From: prodevmg at yahoo.com (Lonnie Johnson) Date: Sun, 29 Jul 2007 19:18:32 -0700 (PDT) Subject: [AccessD] Grid Control Message-ID: <500485.19239.qm@web33109.mail.mud.yahoo.com> A subform in datasheet or continuous form view will not do? May God bless you beyond your imagination! Lonnie Johnson ProDev, Professional Development of MS Access Databases Visit me at ==> http://www.prodev.us ----- Original Message ---- From: Barbara Ryan To: Access List Sent: Sunday, July 29, 2007 10:31:17 AM Subject: [AccessD] Grid Control I would like to use a data grid control in Access for data entry. Any suggestions? Free is best :-) Thanks, Barb Ryan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ From shamil at users.mns.ru Mon Jul 30 05:47:25 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Mon, 30 Jul 2007 14:47:25 +0400 Subject: [AccessD] Going CRUD way... Message-ID: <002401c7d297$04913bb0$6401a8c0@nant> Hi All, It looks like we haven't yet have here CRUD vs. (mainly) dynamic manually written SQL vs. metadata-driven application (frameworks) development debate? Or did I miss it? Anyway my question is what do you prefer to use when developing applications against MS SQL backend:? - 1) CRUD SPs based approach to work with base tables + custom SPs(views, UDFs,...) to implement custom functionality - and SPs only "visible to outer world"? - 2) dynamic SQL - DAO, ADO, ADO.NET (mainly) manually written etc. with or without SPs (views, UDFs,...)? - 3) metadata driven (flexible) dynamic SQL approach? - 4) you do not use not the first not the second not the third approach - you do use a "mixture" of them IOW you just write code to implement custom functionality and whatever approach to use in every certain case you usually decide as you go... - 5) something else (please add other useful approached I missed to mention here)... Thank you. -- Shamil From accessd666 at yahoo.com Mon Jul 30 07:05:43 2007 From: accessd666 at yahoo.com (Sad Der) Date: Mon, 30 Jul 2007 05:05:43 -0700 (PDT) Subject: [AccessD] Run Access as a service? Message-ID: <591325.22663.qm@web31604.mail.mud.yahoo.com> Hi, Is it possible to run an access db as a serice? I've created something that creates a HTML report. By pressing a button I send the report by mail. I want to do this every evening by using a timed loop. TIA Regards, Sander ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From fuller.artful at gmail.com Mon Jul 30 08:01:44 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 30 Jul 2007 09:01:44 -0400 Subject: [AccessD] Going CRUD way... In-Reply-To: <002401c7d297$04913bb0$6401a8c0@nant> References: <002401c7d297$04913bb0$6401a8c0@nant> Message-ID: <29f585dd0707300601r5b3e66cbl547e0b4c53c66e18@mail.gmail.com> Since you wrote this to the AccessD list, I'll begin there with my response. I'm currently doing an ADP for a riding stable (which will soon be for sale, so if any listers have any friends with riding stables... LOL). The general approach in it is forms bound to views. (Nobody but me gets to talk directly to tables.) Some of the views use table-UDFs to simplify joins. All of the combo-boxes and list-boxes use named queries (views) to retrieve their contents. This app is simple, so there's not much need for complicated sprocs, except here and there. These fall mainly in the Reports realm; a dialog box opens, requests parameters such as "Horse", Start Date and End Date, then invokes the report which invokes the sproc and passes the parameters, so you end up with a cross-tab report showing the particular horse's activities ( group lesson, private lesson, sem-private lesson, injury day, etc.) during the date range. In the larger scheme of things, I use ERwin. Its code-gen capabilities are totally wonderful. It has a template language built-in which will generate your CRUD code automatically, and even give you a choice between returning a rowset and a set out OUTPUT parameters. I hadn't realized the benefit of the latter strategy until I worked on a large project with my friend Dejan Sunderic (who wrote a great book about SQL 2005). That type of sproc is useful only when you want exactly one record back, but if you're searching millions of rows, it's demonstrably faster than returning a rowset. You don't even need a timer to note the difference. In Access, there are significant advantages to using views as the data source, IMO, not the least of which is how easily subforms behave. Access does the dirty work for you. You just create a subform based on a view, plonk it onto a master form, and Access handles the plumbing. It couldn't be easier, and in addition you insulate the actual tables. Suppose that your app contains a form that only selected people (let's call them Managers) ought to see. So in SQL you create a Managers role and grant access to the view(s) in question. Then even if you forget to program around it in your Access app, it's ok -- no one but managers will be able to run that report. The message they will receive isn't elegant, but the data is safe. I'm not an ERwin expert but I have worked with one or two. At one point, I asked my friend and colleague Andrei Pascal whether we could customize the template to place what ERwin calls a description into the Extended Properties code. It took Andrei about 5 minutes to modify the template so it did this. That's two "hats off" -- one to the template language and one to Andrei. The template language is pretty much beyond my feeble intellect, but Andrei just whipped out a tiny little loop that walked every table and added an extended property to every table for every column that had a Description, and poof! All done. I used to hate ERwin and I much preferred PowerDesigner and Dezign (whose interface is pretty much a clone of PowerDesigner, although it lacks lots of the PD power). I was dragged kicking and screaming into using ERwin, but have since grown into an enthusiast, not least because generating CRUD and even customized CRUD is a one-click operation. Arthur On 7/30/07, Shamil Salakhetdinov wrote: > > Hi All, > > It looks like we haven't yet have here CRUD vs. (mainly) dynamic manually > written SQL vs. metadata-driven application (frameworks) development > debate? > Or did I miss it? > > Anyway my question is what do you prefer to use when developing > applications > against MS SQL backend:? > > - 1) CRUD SPs based approach to work with base tables + custom SPs(views, > UDFs,...) to implement custom functionality - and SPs only "visible to > outer > world"? > > - 2) dynamic SQL - DAO, ADO, ADO.NET (mainly) manually written etc. with > or > without SPs (views, UDFs,...)? > > - 3) metadata driven (flexible) dynamic SQL approach? > > - 4) you do not use not the first not the second not the third approach - > you do use a "mixture" of them IOW you just write code to implement custom > functionality and whatever approach to use in every certain case you > usually > decide as you go... > > - 5) something else (please add other useful approached I missed to > mention > here)... > > Thank you. > > > -- > Shamil > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From delam at netcapnow.com Mon Jul 30 08:44:33 2007 From: delam at netcapnow.com (delam at netcapnow.com) Date: Mon, 30 Jul 2007 13:44:33 +0000 Subject: [AccessD] Run Access as a service? In-Reply-To: <591325.22663.qm@web31604.mail.mud.yahoo.com> References: <591325.22663.qm@web31604.mail.mud.yahoo.com> Message-ID: <853952693-1185803083-cardhu_decombobulator_blackberry.rim.net-1912026571-@bxe111.bisx.prod.on.blackberry> I think to run as a service may be beyond Access. However, under the control panel, there are scheduled tasks you can use. I have used these in the past to run Access databases at scheduled intervals. I used the technique of having a version of the database that did nothing but theone task. I set the autoexec in that database to trigger the task on open and close the database when the task was complete. Debbie Sent via BlackBerry by AT&T -----Original Message----- From: Sad Der Date: Mon, 30 Jul 2007 05:05:43 To:Acces User Group Subject: [AccessD] Run Access as a service? Hi, Is it possible to run an access db as a serice? I've created something that creates a HTML report. By pressing a button I send the report by mail. I want to do this every evening by using a timed loop. TIA Regards, Sander ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd666 at yahoo.com Mon Jul 30 08:55:08 2007 From: accessd666 at yahoo.com (Sad Der) Date: Mon, 30 Jul 2007 06:55:08 -0700 (PDT) Subject: [AccessD] Get all controls on all forms Message-ID: <586905.71583.qm@web31611.mail.mud.yahoo.com> Hi group, Does anybody have piece of code that retrieves all controles on all forms in a database? I need to store these in a database. Thnx! Regards, Sander ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow From prodevmg at yahoo.com Mon Jul 30 09:24:29 2007 From: prodevmg at yahoo.com (Lonnie Johnson) Date: Mon, 30 Jul 2007 07:24:29 -0700 (PDT) Subject: [AccessD] Get all controls on all forms Message-ID: <556945.68190.qm@web33109.mail.mud.yahoo.com> This is a simple as it gets. Maybe you can build on this. Dim ctl As Control For Each ctl In Me.Controls MsgBox "Control Name: " & ctl.Name Next ctl May God bless you beyond your imagination! Lonnie Johnson ProDev, Professional Development of MS Access Databases Visit me at ==> http://www.prodev.us ----- Original Message ---- From: Sad Der To: Acces User Group Sent: Monday, July 30, 2007 8:55:08 AM Subject: [AccessD] Get all controls on all forms Hi group, Does anybody have piece of code that retrieves all controles on all forms in a database? I need to store these in a database. Thnx! Regards, Sander ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 From jwcolby at colbyconsulting.com Mon Jul 30 09:29:55 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 30 Jul 2007 10:29:55 -0400 Subject: [AccessD] Get all controls on all forms In-Reply-To: <586905.71583.qm@web31611.mail.mud.yahoo.com> Message-ID: <20070730143001.50F2FBCA6@smtp-auth.no-ip.com> I do but I don't have time to go find it. Basically forms which are not open are stored in a documents("forms") collection in the database. You have to get the NAME of each document (which will be the name of each form in the db), then use docmd.openform(ThatFormName) and set a parameter of that DoCmd to open it in design view. Once you have done that, then the form is open in the forms() collection so you can get a pointer to the form. With the form open you can get at the controls collection. I forget what object the documents is a part of. It could be the currentdb object, it could be the application object. Dim doc as document Dim frm as form Dim ctl as control For each doc in documents("forms") docmd.open acform, (doc.name),acDesignView set frm = forms(doc.name) for each ctl in frm.controls() next ctl Docmd.close acform, doc.name Next doc IOW, a form has to be OPEN (either in view mode or design view) to access the controls collection. You want to open it in design view. Once it is opened, get a pointer to it and then access the controls collection The code above is NOT working, but it is close (from memory) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der Sent: Monday, July 30, 2007 9:55 AM To: Acces User Group Subject: [AccessD] Get all controls on all forms Hi group, Does anybody have piece of code that retrieves all controles on all forms in a database? I need to store these in a database. Thnx! Regards, Sander ____________________________________________________________________________ ________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From DWUTKA at Marlow.com Mon Jul 30 09:33:20 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 30 Jul 2007 09:33:20 -0500 Subject: [AccessD] Run Access as a service? In-Reply-To: <591325.22663.qm@web31604.mail.mud.yahoo.com> Message-ID: Not directly. You can do this with VB or .Net, but probably the simplest way would be to just use the scheduling service to run it at the specified time you want it to run. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der Sent: Monday, July 30, 2007 7:06 AM To: Acces User Group Subject: [AccessD] Run Access as a service? Hi, Is it possible to run an access db as a serice? I've created something that creates a HTML report. By pressing a button I send the report by mail. I want to do this every evening by using a timed loop. TIA Regards, Sander ________________________________________________________________________ ____________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+ki ds&cs=bz -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From shamil at users.mns.ru Mon Jul 30 09:47:16 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Mon, 30 Jul 2007 18:47:16 +0400 Subject: [AccessD] Going CRUD way... In-Reply-To: <29f585dd0707300601r5b3e66cbl547e0b4c53c66e18@mail.gmail.com> Message-ID: <000701c7d2b8$86cb14e0$6401a8c0@nant> Hello Arthur, Thank you for your prompt feedback. May I say you're a "generated CRUDs fun"? (I'm getting like that here too therefore this "generated CRUDs fun" is a respectful nickname here :) ...) Do you have any samples of small CRUDs, which you use *in production*, which therefore proved themselves as stable and which you can publish here? - just one for every type of CRUD (Insert, Update, Delete SQL) + Select (by Id) SQL... Thank you. I must say that views used with WinForms (.NET 2.0), even when parameters are used but when views are run against large amounts of back-end data - such views are (very) slow comparing to parameterized stored procedures. I do use views but only as a "middle-/abstraction tier" between SPs and base tables... -- Shamil P.S. Here is a sample of Update SP I use made based on what OlyMars originally did generate - writing that stuff manually is a "no-go" obviously: if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[a_Table_Update]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) drop procedure [dbo].[a_Table_Update] GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO CREATE Procedure [a_Table_Update] -- Update an existing record in [a_Table] table ( @rowId [int] = Null -- for [a_Table].[ID] column , @ConsiderNull_iD bit = 0 , at bitField [bit] = Null -- for [a_Table].[bitField] column , @ConsiderNull_bitField bit = 0 , at intField [int] = Null -- for [a_Table].[intField] column , @ConsiderNull_intField bit = 0 , at decimalField [decimal] = Null -- for [a_Table].[decimalField] column , @ConsiderNull_decimalField bit = 0 , at numericField [numeric] = Null -- for [a_Table].[numericField] column , @ConsiderNull_numericField bit = 0 , at floatField [float] = Null -- for [a_Table].[floatField] column , @ConsiderNull_floatField bit = 0 , at smallMoneyField [smallmoney] = Null -- for [a_Table].[smallMoneyField] column , @ConsiderNull_smallMoneyField bit = 0 , at charField [char](10) = Null -- for [a_Table].[charField] column , @ConsiderNull_charField bit = 0 , at varcharField [varchar](50) = Null -- for [a_Table].[varcharField] column , @ConsiderNull_varcharField bit = 0 , at textField [text] = Null -- for [a_Table].[textField] column , @ConsiderNull_textField bit = 0 , at nvarCharField [nvarchar](50) = Null -- for [a_Table].[nvarCharField] column , @ConsiderNull_nvarCharField bit = 0 , at ntextField [ntext] = Null -- for [a_Table].[ntextField] column , @ConsiderNull_ntextField bit = 0 , at dateTimeField [datetime] = Null -- for [a_Table].[dateTimeField] column , @ConsiderNull_dateTimeField bit = 0 , at uniqueidentifierField [uniqueidentifier] = Null -- for [a_Table].[uniqueidentifierField] column , @ConsiderNull_uniqueidentifierField bit = 0 , at imageField [image] = Null -- for [a_Table].[imageField] column , @ConsiderNull_imageField bit = 0 ) As Set NoCount On Declare @retValue int If @ConsiderNull_iD Is Null Set @ConsiderNull_iD = 0 If @ConsiderNull_bitField Is Null Set @ConsiderNull_bitField = 0 If @ConsiderNull_intField Is Null Set @ConsiderNull_intField = 0 If @ConsiderNull_decimalField Is Null Set @ConsiderNull_decimalField = 0 If @ConsiderNull_numericField Is Null Set @ConsiderNull_numericField = 0 If @ConsiderNull_floatField Is Null Set @ConsiderNull_floatField = 0 If @ConsiderNull_smallMoneyField Is Null Set @ConsiderNull_smallMoneyField = 0 If @ConsiderNull_charField Is Null Set @ConsiderNull_charField = 0 If @ConsiderNull_varcharField Is Null Set @ConsiderNull_varcharField = 0 If @ConsiderNull_textField Is Null Set @ConsiderNull_textField = 0 If @ConsiderNull_nvarCharField Is Null Set @ConsiderNull_nvarCharField = 0 If @ConsiderNull_ntextField Is Null Set @ConsiderNull_ntextField = 0 If @ConsiderNull_dateTimeField Is Null Set @ConsiderNull_dateTimeField = 0 If @ConsiderNull_uniqueidentifierField Is Null Set @ConsiderNull_uniqueidentifierField = 0 If @ConsiderNull_imageField Is Null Set @ConsiderNull_imageField = 0 Update [dbo].[a_Table] Set [rowId] = Case @ConsiderNull_iD When 0 Then IsNull(@rowId, [rowId]) When 1 Then @rowId End , [bitField] = Case @ConsiderNull_bitField When 0 Then IsNull(@bitField, [bitField]) When 1 Then @bitField End , [intField] = Case @ConsiderNull_intField When 0 Then IsNull(@intField, [intField]) When 1 Then @intField End , [decimalField] = Case @ConsiderNull_decimalField When 0 Then IsNull(@decimalField, [decimalField]) When 1 Then @decimalField End , [numericField] = Case @ConsiderNull_numericField When 0 Then IsNull(@numericField, [numericField]) When 1 Then @numericField End , [floatField] = Case @ConsiderNull_floatField When 0 Then IsNull(@floatField, [floatField]) When 1 Then @floatField End , [smallMoneyField] = Case @ConsiderNull_smallMoneyField When 0 Then IsNull(@smallMoneyField, [smallMoneyField]) When 1 Then @smallMoneyField End , [charField] = Case @ConsiderNull_charField When 0 Then IsNull(@charField, [charField]) When 1 Then @charField End , [varcharField] = Case @ConsiderNull_varcharField When 0 Then IsNull(@varcharField, [varcharField]) When 1 Then @varcharField End , [textField] = Case @ConsiderNull_textField When 0 Then IsNull(@textField, [textField]) When 1 Then @textField End , [nvarCharField] = Case @ConsiderNull_nvarCharField When 0 Then IsNull(@nvarCharField, [nvarCharField]) When 1 Then @nvarCharField End , [ntextField] = Case @ConsiderNull_ntextField When 0 Then IsNull(@ntextField, [ntextField]) When 1 Then @ntextField End , [dateTimeField] = Case @ConsiderNull_dateTimeField When 0 Then IsNull(@dateTimeField, [dateTimeField]) When 1 Then @dateTimeField End , [uniqueidentifierField] = Case @ConsiderNull_uniqueidentifierField When 0 Then IsNull(@uniqueidentifierField, [uniqueidentifierField]) When 1 Then @uniqueidentifierField End , [imageField] = Case @ConsiderNull_imageField When 0 Then IsNull(@imageField, [imageField]) When 1 Then @imageField End Where ([rowId] = @rowId) select @retValue = @@ERROR Set NoCount Off Return(@retValue) GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 30, 2007 5:02 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Going CRUD way... Since you wrote this to the AccessD list, I'll begin there with my response. I'm currently doing an ADP for a riding stable (which will soon be for sale, so if any listers have any friends with riding stables... LOL). The general approach in it is forms bound to views. (Nobody but me gets to talk directly to tables.) Some of the views use table-UDFs to simplify joins. All of the combo-boxes and list-boxes use named queries (views) to retrieve their contents. This app is simple, so there's not much need for complicated sprocs, except here and there. These fall mainly in the Reports realm; a dialog box opens, requests parameters such as "Horse", Start Date and End Date, then invokes the report which invokes the sproc and passes the parameters, so you end up with a cross-tab report showing the particular horse's activities ( group lesson, private lesson, sem-private lesson, injury day, etc.) during the date range. In the larger scheme of things, I use ERwin. Its code-gen capabilities are totally wonderful. It has a template language built-in which will generate your CRUD code automatically, and even give you a choice between returning a rowset and a set out OUTPUT parameters. I hadn't realized the benefit of the latter strategy until I worked on a large project with my friend Dejan Sunderic (who wrote a great book about SQL 2005). That type of sproc is useful only when you want exactly one record back, but if you're searching millions of rows, it's demonstrably faster than returning a rowset. You don't even need a timer to note the difference. In Access, there are significant advantages to using views as the data source, IMO, not the least of which is how easily subforms behave. Access does the dirty work for you. You just create a subform based on a view, plonk it onto a master form, and Access handles the plumbing. It couldn't be easier, and in addition you insulate the actual tables. Suppose that your app contains a form that only selected people (let's call them Managers) ought to see. So in SQL you create a Managers role and grant access to the view(s) in question. Then even if you forget to program around it in your Access app, it's ok -- no one but managers will be able to run that report. The message they will receive isn't elegant, but the data is safe. I'm not an ERwin expert but I have worked with one or two. At one point, I asked my friend and colleague Andrei Pascal whether we could customize the template to place what ERwin calls a description into the Extended Properties code. It took Andrei about 5 minutes to modify the template so it did this. That's two "hats off" -- one to the template language and one to Andrei. The template language is pretty much beyond my feeble intellect, but Andrei just whipped out a tiny little loop that walked every table and added an extended property to every table for every column that had a Description, and poof! All done. I used to hate ERwin and I much preferred PowerDesigner and Dezign (whose interface is pretty much a clone of PowerDesigner, although it lacks lots of the PD power). I was dragged kicking and screaming into using ERwin, but have since grown into an enthusiast, not least because generating CRUD and even customized CRUD is a one-click operation. Arthur On 7/30/07, Shamil Salakhetdinov wrote: > > Hi All, > > It looks like we haven't yet have here CRUD vs. (mainly) dynamic manually > written SQL vs. metadata-driven application (frameworks) development > debate? > Or did I miss it? > > Anyway my question is what do you prefer to use when developing > applications > against MS SQL backend:? > > - 1) CRUD SPs based approach to work with base tables + custom SPs(views, > UDFs,...) to implement custom functionality - and SPs only "visible to > outer > world"? > > - 2) dynamic SQL - DAO, ADO, ADO.NET (mainly) manually written etc. with > or > without SPs (views, UDFs,...)? > > - 3) metadata driven (flexible) dynamic SQL approach? > > - 4) you do not use not the first not the second not the third approach - > you do use a "mixture" of them IOW you just write code to implement custom > functionality and whatever approach to use in every certain case you > usually > decide as you go... > > - 5) something else (please add other useful approached I missed to > mention > here)... > > Thank you. > > > -- > Shamil > > > > -- > 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 cfoust at infostatsystems.com Mon Jul 30 10:50:21 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 30 Jul 2007 08:50:21 -0700 Subject: [AccessD] Data Warehouse In-Reply-To: <200707271816.l6RIGOLF009816@databaseadvisors.com> References: <200707271816.l6RIGOLF009816@databaseadvisors.com> Message-ID: Ok, thanks for clarifying. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Friday, July 27, 2007 11:13 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Data Warehouse Charlotte, In the case of a customer dimension, it would be the customer primary key from the customer table in the source. The problem comes from having multiple sources. Then you have to use a surrogate key and store the source primary key in a column along with the source name. Sorry, I have been doing it for so long, it is second nature. So, I do not really think about it. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Thu, 26 Jul 2007 13:59:09 -0700 >From: "Charlotte Foust" >Subject: Re: [AccessD] Data Warehouse (Was: Primary Key Best > Practices) >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >Yes, and I have several of Ralph Kimball's books on Data Warehouse >design and I've built a few, but what I was looking for was an >explanation of how a dimension table inherits a single column PK "from >the source primary table." I assume it means that all the distinct >values for that column that exist in the primary table have a matching >PK in the dimension table, but it took me a while to sort it out to >that, and I've *worked* with the things! > >Charlotte Foust -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon Jul 30 10:52:42 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 30 Jul 2007 08:52:42 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <29f585dd0707271240w6d43fbet80ef9043e7b434d4@mail.gmail.com> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> <46AA3DCB.5000501@shaw.ca> <29f585dd0707271240w6d43fbet80ef9043e7b434d4@mail.gmail.com> Message-ID: Of course, in the documentation, Microsoft advises you not to load up the QAT with all those shortcuts! LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 27, 2007 12:40 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Turning off A2007 Menus You may just have persuaded me to re-install Access 2007. On 7/27/07, MartyConnelly wrote: > > If the "ribbon" takes up too much room, it's easy to hide. > Just right-click on one of the ribbon tabs and choose: > "Minimize the Ribbon." If you want quick access to a button found on > one of the ribbons, just right-click on the button and choose: "Add to > Quick Access Toolbar." Alternatively, you can get a list of all > options and customize the "Quick Access Toolbar." You can easily add > dozens of buttons to the toolbar. > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon Jul 30 10:55:51 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 30 Jul 2007 08:55:51 -0700 Subject: [AccessD] Grid Control In-Reply-To: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> Message-ID: Is there some reason you must have a grid? The built in continuous forms and datasheet forms are much, much easier to work with. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan Sent: Sunday, July 29, 2007 8:31 AM To: Access List Subject: [AccessD] Grid Control I would like to use a data grid control in Access for data entry. Any suggestions? Free is best :-) Thanks, Barb Ryan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Donald.A.McGillivray at sprint.com Mon Jul 30 11:27:07 2007 From: Donald.A.McGillivray at sprint.com (McGillivray, Don [IT]) Date: Mon, 30 Jul 2007 11:27:07 -0500 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files In-Reply-To: <200707292358.l6TNwXBk026421@databaseadvisors.com> References: <200707292358.l6TNwXBk026421@databaseadvisors.com> Message-ID: Darren, I've done something similar by redirecting the output of the DOS "type" command to a file. I've never had an issue with extraneous characters using this method. Something like this: Type *.fil >> BigFile.txt This concatenates the contents of all files with the extension "fil" into a single file called BigFile.txt. Don't know if the order of concatenation is predictable, if that's important to you. As for inserting text between additions or at either end, I think you can redirect the DOS "echo" command in a similar way. Something like: Echo "Start of file" >> BigFile.txt Type *.fil >> BigFile.txt Echo "End of file" >> BigFile.txt Hope this helps . . . Don -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D Sent: Sunday, July 29, 2007 4:30 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files Hi all I am calling a batch file from my access app The batch file just 'merges' a few files into one big file and then gives it a name This is the batch file - Very basic - 1 liner - copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt mynewcoolcombinedfile.XML Pretty basic - but the combining leaves a small ascii type square as the very very last character - Like this ---> Anyone know how to stop this from happening? Or even better - How to 'build' or merge a few files into one big file - from VBA Or even better still - How to insert Text eg Merge "This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into OneCoolFile.XML Many thanks in advance DD -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From robert at webedb.com Mon Jul 30 12:10:42 2007 From: robert at webedb.com (Robert L. Stewart) Date: Mon, 30 Jul 2007 12:10:42 -0500 Subject: [AccessD] Going CRUD way... In-Reply-To: References: Message-ID: <200707301712.l6UHCAkD005195@databaseadvisors.com> Shamil, I have a stored procedure that I use to generate a single CRUD that uses "modes" for each table. If you (or anyone else) would like to get a copy of it, send me a note off list and I will send a copy of it to you. What it does is creates a mode for each of the parts of the CRUD, Create (I mode), Read(A (All) and S (single record) modes), Update (U mode), Delete, (D mode). Plus, I throw in a few other "standard" ones that we have found useful here. You can also add in "custom" modes at the bottom that can give you additional functionality. You can have up to 36 modes if you use a single character. Robert At 10:54 AM 7/30/2007, you wrote: >Date: Mon, 30 Jul 2007 18:47:16 +0400 >From: "Shamil Salakhetdinov" >Subject: Re: [AccessD] Going CRUD way... >To: "'Access Developers discussion and problem solving'" > >Message-ID: <000701c7d2b8$86cb14e0$6401a8c0 at nant> >Content-Type: text/plain; charset="us-ascii" > >Hello Arthur, > >Thank you for your prompt feedback. > >May I say you're a "generated CRUDs fun"? (I'm getting like that here too >therefore this "generated CRUDs fun" is a respectful nickname here :) ...) > >Do you have any samples of small CRUDs, which you use *in production*, which >therefore proved themselves as stable and which you can publish here? - just >one for every type of CRUD (Insert, Update, Delete SQL) + Select (by Id) >SQL... > >Thank you. > > >I must say that views used with WinForms (.NET 2.0), even when parameters >are used but when views are run against large amounts of back-end data - >such views are (very) slow comparing to parameterized stored procedures. > >I do use views but only as a "middle-/abstraction tier" between SPs and base >tables... > >-- >Shamil > From rockysmolin at bchacc.com Mon Jul 30 12:50:51 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 10:50:51 -0700 Subject: [AccessD] Change Printers Message-ID: <004301c7d2d2$2b7d8540$0301a8c0@HAL9005> Dear List: I have a client who wants to print some labels on a roll printer so when they open the form that prints the labels, I'd like them to have a combo box of installed printers (or alternatively a 'browse for printer' function), save the default printer, change to the selected printer, print the label, and change back to the default printer. I know I've done this but I can't find the module where I did it. Does anyone a code snip that does this? MTIA Rocky From JRojas at tnco-inc.com Mon Jul 30 12:54:41 2007 From: JRojas at tnco-inc.com (Joe Rojas) Date: Mon, 30 Jul 2007 13:54:41 -0400 Subject: [AccessD] Export Metadata or Schema References: <200707301712.l6UHCAkD005195@databaseadvisors.com> Message-ID: <758E92433C4F3740B67BE4DD369AF5775C502B@ex2k3.corp.tnco-inc.com> Hello, Is there a way in Access (I'm using 2007 but DB is 2000 format) to export the information that is displayed when you are working with a table in Design View? I am trying to compare the structure of two tables and I thought it would be user to compare this if I could export or copy and paste into Excel. Thanks in advance! Joe Rojas From mmattys at rochester.rr.com Mon Jul 30 13:08:22 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Mon, 30 Jul 2007 14:08:22 -0400 Subject: [AccessD] Export Metadata or Schema References: <200707301712.l6UHCAkD005195@databaseadvisors.com> <758E92433C4F3740B67BE4DD369AF5775C502B@ex2k3.corp.tnco-inc.com> Message-ID: <00be01c7d2d4$9f9c9f90$0202a8c0@Laptop> Dim db as dao.database Dim tdf as dao.tabledef Dim fld as dao.field set db = currentdb For each tdf in db.tabledefs For each fld in tdf.fields debug.print fld.name Next fld Next tdf set db = nothing Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: "Joe Rojas" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 1:54 PM Subject: [AccessD] Export Metadata or Schema > Hello, > > Is there a way in Access (I'm using 2007 but DB is 2000 format) to > export the information that is displayed when you are working with a > table in Design View? > > I am trying to compare the structure of two tables and I thought it > would be user to compare this if I could export or copy and paste into > Excel. > > Thanks in advance! > > Joe Rojas > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From wdhindman at dejpolsystems.com Mon Jul 30 13:17:34 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 14:17:34 -0400 Subject: [AccessD] Change Printers References: <004301c7d2d2$2b7d8540$0301a8c0@HAL9005> Message-ID: <004301c7d2d5$e74b3080$0c10a8c0@jisshowsbs.local> Rocky ...if the Form is meant to only print the labels on the roll printer, why not set it as the "specific" printer in the form's print properties ...that way you don't get the user involved in the printer selection process ...I usually do this with badge printers. William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 1:50 PM Subject: [AccessD] Change Printers > Dear List: > > I have a client who wants to print some labels on a roll printer so when > they open the form that prints the labels, I'd like them to have a combo > box > of installed printers (or alternatively a 'browse for printer' function), > save the default printer, change to the selected printer, print the label, > and change back to the default printer. > > I know I've done this but I can't find the module where I did it. Does > anyone a code snip that does this? > > MTIA > > Rocky > > > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From martyconnelly at shaw.ca Mon Jul 30 13:19:07 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Mon, 30 Jul 2007 11:19:07 -0700 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files In-Reply-To: References: <200707292358.l6TNwXBk026421@databaseadvisors.com> Message-ID: <46AE2B9B.4090804@shaw.ca> Could be a couple of things, I haven't got an Ascii Table handy Have a look at last char in HexEditor. At a guess it could CTRL-Z which is an old DOS EOF McGillivray, Don [IT] wrote: >Darren, > >I've done something similar by redirecting the output of the DOS "type" command to a file. I've never had an issue with extraneous characters using this method. Something like this: > >Type *.fil >> BigFile.txt > >This concatenates the contents of all files with the extension "fil" into a single file called BigFile.txt. Don't know if the order of concatenation is predictable, if that's important to you. > >As for inserting text between additions or at either end, I think you can redirect the DOS "echo" command in a similar way. Something like: > >Echo "Start of file" >> BigFile.txt >Type *.fil >> BigFile.txt >Echo "End of file" >> BigFile.txt > >Hope this helps . . . > >Don > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D >Sent: Sunday, July 29, 2007 4:30 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files > >Hi all > > > >I am calling a batch file from my access app > > > >The batch file just 'merges' a few files into one big file and then gives it a >name > > > >This is the batch file - Very basic - 1 liner - > > > >copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt >mynewcoolcombinedfile.XML > > > >Pretty basic - but the combining leaves a small ascii type square as the very >very last character - Like this ---> > > > >Anyone know how to stop this from happening? > > > >Or even better - How to 'build' or merge a few files into one big file - from >VBA > > > >Or even better still - How to insert Text eg Merge > > > >"This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into >OneCoolFile.XML > > > >Many thanks in advance > > > >DD > > > > > -- Marty Connelly Victoria, B.C. Canada From rockysmolin at bchacc.com Mon Jul 30 13:36:23 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 11:36:23 -0700 Subject: [AccessD] Change Printers In-Reply-To: <004301c7d2d5$e74b3080$0c10a8c0@jisshowsbs.local> Message-ID: <004401c7d2d8$87c4a990$0301a8c0@HAL9005> As soon as I hard code it, they'll change it. So I'd prefer the more flexible route if it's not too much time to do. Also, makes it easier to test. But you're right - if I can't get a chunk of code going in short order, that's what I'll do. The client is actually 4 minutes from the house so dropping in to do the last tweaks and tests is easy. But it would be a nice module to have in the library. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman Sent: Monday, July 30, 2007 11:18 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Change Printers Rocky ...if the Form is meant to only print the labels on the roll printer, why not set it as the "specific" printer in the form's print properties ...that way you don't get the user involved in the printer selection process ...I usually do this with badge printers. William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 1:50 PM Subject: [AccessD] Change Printers > Dear List: > > I have a client who wants to print some labels on a roll printer so when > they open the form that prints the labels, I'd like them to have a combo > box > of installed printers (or alternatively a 'browse for printer' function), > save the default printer, change to the selected printer, print the label, > and change back to the default printer. > > I know I've done this but I can't find the module where I did it. Does > anyone a code snip that does this? > > MTIA > > Rocky > > > > > > > -- > 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 11:14 PM From wdhindman at dejpolsystems.com Mon Jul 30 14:27:37 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 15:27:37 -0400 Subject: [AccessD] Change Printers References: <004401c7d2d8$87c4a990$0301a8c0@HAL9005> Message-ID: <000301c7d2df$b07b7790$0c10a8c0@jisshowsbs.local> ...try http://allenbrowne.com/AppPrintMgt.html William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 2:36 PM Subject: Re: [AccessD] Change Printers > As soon as I hard code it, they'll change it. So I'd prefer the more > flexible route if it's not too much time to do. > > Also, makes it easier to test. But you're right - if I can't get a chunk > of > code going in short order, that's what I'll do. The client is actually 4 > minutes from the house so dropping in to do the last tweaks and tests is > easy. But it would be a nice module to have in the library. > > Rocky > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman > Sent: Monday, July 30, 2007 11:18 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > Rocky > ...if the Form is meant to only print the labels on the roll printer, why > not set it as the "specific" printer in the form's print properties > ...that > way you don't get the user involved in the printer selection process ...I > usually do this with badge printers. > William Hindman > > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 1:50 PM > Subject: [AccessD] Change Printers > > >> Dear List: >> >> I have a client who wants to print some labels on a roll printer so when >> they open the form that prints the labels, I'd like them to have a combo >> box >> of installed printers (or alternatively a 'browse for printer' function), >> save the default printer, change to the selected printer, print the >> label, >> and change back to the default printer. >> >> I know I've done this but I can't find the module where I did it. Does >> anyone a code snip that does this? >> >> MTIA >> >> Rocky >> >> >> >> >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 > 11:14 PM > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From rockysmolin at bchacc.com Mon Jul 30 15:43:49 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 13:43:49 -0700 Subject: [AccessD] Change Printers In-Reply-To: <000301c7d2df$b07b7790$0c10a8c0@jisshowsbs.local> Message-ID: <005c01c7d2ea$5549d230$0301a8c0@HAL9005> Looks like the right stuff. I also found this - if anybody's interested or has the same problem - but I haven't tried it. http://www.mvps.org/access/reports/rpt0009.htm Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman Sent: Monday, July 30, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Change Printers ...try http://allenbrowne.com/AppPrintMgt.html William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 2:36 PM Subject: Re: [AccessD] Change Printers > As soon as I hard code it, they'll change it. So I'd prefer the more > flexible route if it's not too much time to do. > > Also, makes it easier to test. But you're right - if I can't get a chunk > of > code going in short order, that's what I'll do. The client is actually 4 > minutes from the house so dropping in to do the last tweaks and tests is > easy. But it would be a nice module to have in the library. > > Rocky > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman > Sent: Monday, July 30, 2007 11:18 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > Rocky > ...if the Form is meant to only print the labels on the roll printer, why > not set it as the "specific" printer in the form's print properties > ...that > way you don't get the user involved in the printer selection process ...I > usually do this with badge printers. > William Hindman > > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 1:50 PM > Subject: [AccessD] Change Printers > > >> Dear List: >> >> I have a client who wants to print some labels on a roll printer so when >> they open the form that prints the labels, I'd like them to have a combo >> box >> of installed printers (or alternatively a 'browse for printer' function), >> save the default printer, change to the selected printer, print the >> label, >> and change back to the default printer. >> >> I know I've done this but I can't find the module where I did it. Does >> anyone a code snip that does this? >> >> MTIA >> >> Rocky >> >> >> >> >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 > 11:14 PM > > > -- > 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 11:14 PM From wdhindman at dejpolsystems.com Mon Jul 30 16:23:29 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 17:23:29 -0400 Subject: [AccessD] Change Printers References: <005c01c7d2ea$5549d230$0301a8c0@HAL9005> Message-ID: <000301c7d2ef$e04407c0$0c10a8c0@jisshowsbs.local> Rocky ...I think you'll find that reference is to pre A2K printer functionality using api calls ...Access has its own printer object now. William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 4:43 PM Subject: Re: [AccessD] Change Printers > Looks like the right stuff. I also found this - if anybody's interested > or > has the same problem - but I haven't tried it. > > http://www.mvps.org/access/reports/rpt0009.htm > > Rocky > > > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman > Sent: Monday, July 30, 2007 12:28 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > ...try http://allenbrowne.com/AppPrintMgt.html > William Hindman > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 2:36 PM > Subject: Re: [AccessD] Change Printers > > >> As soon as I hard code it, they'll change it. So I'd prefer the more >> flexible route if it's not too much time to do. >> >> Also, makes it easier to test. But you're right - if I can't get a chunk >> of >> code going in short order, that's what I'll do. The client is actually 4 >> minutes from the house so dropping in to do the last tweaks and tests is >> easy. But it would be a nice module to have in the library. >> >> Rocky >> >> >> >> >> >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William >> Hindman >> Sent: Monday, July 30, 2007 11:18 AM >> To: Access Developers discussion and problem solving >> Subject: Re: [AccessD] Change Printers >> >> Rocky >> ...if the Form is meant to only print the labels on the roll printer, why >> not set it as the "specific" printer in the form's print properties >> ...that >> way you don't get the user involved in the printer selection process ...I >> usually do this with badge printers. >> William Hindman >> >> ----- Original Message ----- >> From: "Rocky Smolin at Beach Access Software" >> To: "'Access Developers discussion and problem solving'" >> >> Sent: Monday, July 30, 2007 1:50 PM >> Subject: [AccessD] Change Printers >> >> >>> Dear List: >>> >>> I have a client who wants to print some labels on a roll printer so when >>> they open the form that prints the labels, I'd like them to have a combo >>> box >>> of installed printers (or alternatively a 'browse for printer' >>> function), >>> save the default printer, change to the selected printer, print the >>> label, >>> and change back to the default printer. >>> >>> I know I've done this but I can't find the module where I did it. Does >>> anyone a code snip that does this? >>> >>> MTIA >>> >>> Rocky >>> >>> >>> >>> >>> >>> >>> -- >>> 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 incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: >> 7/29/2007 >> 11:14 PM >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 > 11:14 PM > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From gustav at cactus.dk Mon Jul 30 16:59:04 2007 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 30 Jul 2007 23:59:04 +0200 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files Message-ID: Hi Darren Try with COPY /B, that should remove the EOF byte. /gustav >>> martyconnelly at shaw.ca 30-07-07 20:19 >>> Could be a couple of things, I haven't got an Ascii Table handy Have a look at last char in HexEditor. At a guess it could CTRL-Z which is an old DOS EOF McGillivray, Don [IT] wrote: >Darren, > >I've done something similar by redirecting the output of the DOS "type" command to a file. I've never had an issue with extraneous characters using this method. Something like this: > >Type *.fil >> BigFile.txt > >This concatenates the contents of all files with the extension "fil" into a single file called BigFile.txt. Don't know if the order of concatenation is predictable, if that's important to you. > >As for inserting text between additions or at either end, I think you can redirect the DOS "echo" command in a similar way. Something like: > >Echo "Start of file" >> BigFile.txt >Type *.fil >> BigFile.txt >Echo "End of file" >> BigFile.txt > >Hope this helps . . . > >Don > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D >Sent: Sunday, July 29, 2007 4:30 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files > >Hi all > > > >I am calling a batch file from my access app > > > >The batch file just 'merges' a few files into one big file and then gives it a >name > > > >This is the batch file - Very basic - 1 liner - > > > >copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt >mynewcoolcombinedfile.XML > > > >Pretty basic - but the combining leaves a small ascii type square as the very >very last character - Like this ---> > > > >Anyone know how to stop this from happening? > > > >Or even better - How to 'build' or merge a few files into one big file - from >VBA > > > >Or even better still - How to insert Text eg Merge > > > >"This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into >OneCoolFile.XML > > > >Many thanks in advance > > > >DD From rockysmolin at bchacc.com Mon Jul 30 17:22:16 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 15:22:16 -0700 Subject: [AccessD] Change Printers In-Reply-To: <000301c7d2ef$e04407c0$0c10a8c0@jisshowsbs.local> Message-ID: <007701c7d2f8$1656fb30$0301a8c0@HAL9005> I don't see the form's print properties you referred to. Where is that? Also, wouldn't it be the report's print properties? (which I don't see either) Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman Sent: Monday, July 30, 2007 2:23 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Change Printers Rocky ...I think you'll find that reference is to pre A2K printer functionality using api calls ...Access has its own printer object now. William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 4:43 PM Subject: Re: [AccessD] Change Printers > Looks like the right stuff. I also found this - if anybody's > interested or has the same problem - but I haven't tried it. > > http://www.mvps.org/access/reports/rpt0009.htm > > Rocky > > > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William > Hindman > Sent: Monday, July 30, 2007 12:28 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > ...try http://allenbrowne.com/AppPrintMgt.html > William Hindman > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 2:36 PM > Subject: Re: [AccessD] Change Printers > > >> As soon as I hard code it, they'll change it. So I'd prefer the more >> flexible route if it's not too much time to do. >> >> Also, makes it easier to test. But you're right - if I can't get a >> chunk of code going in short order, that's what I'll do. The client >> is actually 4 minutes from the house so dropping in to do the last >> tweaks and tests is easy. But it would be a nice module to have in >> the library. >> >> Rocky >> >> >> >> >> >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William >> Hindman >> Sent: Monday, July 30, 2007 11:18 AM >> To: Access Developers discussion and problem solving >> Subject: Re: [AccessD] Change Printers >> >> Rocky >> ...if the Form is meant to only print the labels on the roll printer, >> why not set it as the "specific" printer in the form's print >> properties ...that way you don't get the user involved in the printer >> selection process ...I usually do this with badge printers. >> William Hindman >> >> ----- Original Message ----- >> From: "Rocky Smolin at Beach Access Software" >> >> To: "'Access Developers discussion and problem solving'" >> >> Sent: Monday, July 30, 2007 1:50 PM >> Subject: [AccessD] Change Printers >> >> >>> Dear List: >>> >>> I have a client who wants to print some labels on a roll printer so >>> when they open the form that prints the labels, I'd like them to >>> have a combo box of installed printers (or alternatively a 'browse >>> for printer' >>> function), >>> save the default printer, change to the selected printer, print the >>> label, and change back to the default printer. >>> >>> I know I've done this but I can't find the module where I did it. >>> Does anyone a code snip that does this? >>> >>> MTIA >>> >>> Rocky >>> >>> >>> >>> >>> >>> >>> -- >>> 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 incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: >> 7/29/2007 >> 11:14 PM >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: > 7/29/2007 > 11:14 PM > > > -- > 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 11:14 PM From BarbaraRyan at cox.net Mon Jul 30 18:01:24 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Mon, 30 Jul 2007 19:01:24 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> Message-ID: <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> I normally would use continuous forms, but for this worker "scheduling" form (i.e., rows are worker types; columns are dates "07/01/07", "07/02/07"...) I thought I would check out grid controls to see if they would offer any advantages. Barb Ryan ----- Original Message ----- From: "Charlotte Foust" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 11:55 AM Subject: Re: [AccessD] Grid Control > Is there some reason you must have a grid? The built in continuous > forms and datasheet forms are much, much easier to work with. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan > Sent: Sunday, July 29, 2007 8:31 AM > To: Access List > Subject: [AccessD] Grid Control > > I would like to use a data grid control in Access for data entry. Any > suggestions? Free is best :-) > > Thanks, > Barb Ryan > -- > 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 cfoust at infostatsystems.com Mon Jul 30 18:10:10 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 30 Jul 2007 16:10:10 -0700 Subject: [AccessD] Grid Control In-Reply-To: <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> Message-ID: I haven't worked with grids in the last couple of versions, so I'm outdated. When I worked with them, you had to populate them programatically, and that doesn't seem worth the effort IMO. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan Sent: Monday, July 30, 2007 4:01 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Grid Control I normally would use continuous forms, but for this worker "scheduling" form (i.e., rows are worker types; columns are dates "07/01/07", "07/02/07"...) I thought I would check out grid controls to see if they would offer any advantages. Barb Ryan ----- Original Message ----- From: "Charlotte Foust" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 11:55 AM Subject: Re: [AccessD] Grid Control > Is there some reason you must have a grid? The built in continuous > forms and datasheet forms are much, much easier to work with. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan > Sent: Sunday, July 29, 2007 8:31 AM > To: Access List > Subject: [AccessD] Grid Control > > I would like to use a data grid control in Access for data entry. Any > suggestions? Free is best :-) > > Thanks, > Barb Ryan > -- > 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 miscellany at mvps.org Mon Jul 30 18:30:54 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 31 Jul 2007 11:30:54 +1200 Subject: [AccessD] Change Printers In-Reply-To: <007701c7d2f8$1656fb30$0301a8c0@HAL9005> References: <007701c7d2f8$1656fb30$0301a8c0@HAL9005> Message-ID: <46AE74AE.4060506@mvps.org> Rocky, In design view of the report, go to the File|Page Setup menu, and see under the 'Page' tab. Regards Steve Rocky Smolin at Beach Access Software wrote: > I don't see the form's print properties you referred to. Where is that? > Also, wouldn't it be the report's print properties? (which I don't see > either) From miscellany at mvps.org Mon Jul 30 18:36:55 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 31 Jul 2007 11:36:55 +1200 Subject: [AccessD] Grid Control In-Reply-To: <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> Message-ID: <46AE7617.9020204@mvps.org> Barbara, It might be worth giving this a try: http://www.devexpress.com/Products/ActiveX/XQuantumGrid/Index.xml I haven't used it myself. But I use the Sidebar control from the same company, and it is cool. Regards Steve Barbara Ryan wrote: > I normally would use continuous forms, but for this worker "scheduling" form > (i.e., rows are worker types; columns are dates "07/01/07", "07/02/07"...) I > thought I would check out grid controls to see if they would offer any > advantages. From rockysmolin at bchacc.com Mon Jul 30 18:50:45 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 16:50:45 -0700 Subject: [AccessD] Change Printers In-Reply-To: <46AE74AE.4060506@mvps.org> Message-ID: <009201c7d304$72ce6f90$0301a8c0@HAL9005> Got it. Thanks. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Monday, July 30, 2007 4:31 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Change Printers Rocky, In design view of the report, go to the File|Page Setup menu, and see under the 'Page' tab. Regards Steve Rocky Smolin at Beach Access Software wrote: > I don't see the form's print properties you referred to. Where is that? > Also, wouldn't it be the report's print properties? (which I don't see > either) -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 11:14 PM From wdhindman at dejpolsystems.com Mon Jul 30 19:25:19 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 20:25:19 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35><00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <46AE7617.9020204@mvps.org> Message-ID: <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> Steve ...that's an ATL based grid, don't think it will work in Access William Hindman ----- Original Message ----- From: "Steve Schapel" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 7:36 PM Subject: Re: [AccessD] Grid Control > Barbara, > > It might be worth giving this a try: > http://www.devexpress.com/Products/ActiveX/XQuantumGrid/Index.xml > > I haven't used it myself. But I use the Sidebar control from the same > company, and it is cool. > > Regards > Steve > > > Barbara Ryan wrote: >> I normally would use continuous forms, but for this worker "scheduling" >> form >> (i.e., rows are worker types; columns are dates "07/01/07", >> "07/02/07"...) I >> thought I would check out grid controls to see if they would offer any >> advantages. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From wdhindman at dejpolsystems.com Mon Jul 30 19:46:56 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 20:46:56 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> Message-ID: <000301c7d30c$4c43d290$517a6c4c@jisshowsbs.local> Barbara ...I think I sent you an all Access vba scheduling grid sample app pretty much like you describe a few months or so back when you were heading out on your own ...you might want to take a look there first ...if you don't find it, let me know. William Hindman ----- Original Message ----- From: "Barbara Ryan" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 7:01 PM Subject: Re: [AccessD] Grid Control >I normally would use continuous forms, but for this worker "scheduling" >form > (i.e., rows are worker types; columns are dates "07/01/07", "07/02/07"...) > I > thought I would check out grid controls to see if they would offer any > advantages. > > Barb Ryan > > ----- Original Message ----- > From: "Charlotte Foust" > To: "Access Developers discussion and problem solving" > > Sent: Monday, July 30, 2007 11:55 AM > Subject: Re: [AccessD] Grid Control > > >> Is there some reason you must have a grid? The built in continuous >> forms and datasheet forms are much, much easier to work with. >> >> Charlotte Foust >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan >> Sent: Sunday, July 29, 2007 8:31 AM >> To: Access List >> Subject: [AccessD] Grid Control >> >> I would like to use a data grid control in Access for data entry. Any >> suggestions? Free is best :-) >> >> Thanks, >> Barb Ryan >> -- >> 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 wdhindman at dejpolsystems.com Mon Jul 30 19:48:54 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 20:48:54 -0400 Subject: [AccessD] Change Printers References: <007701c7d2f8$1656fb30$0301a8c0@HAL9005> Message-ID: <000901c7d30c$927ef2d0$517a6c4c@jisshowsbs.local> ...form, report ...when you get to be my age it all kind of runs together :) William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 6:22 PM Subject: Re: [AccessD] Change Printers >I don't see the form's print properties you referred to. Where is that? > Also, wouldn't it be the report's print properties? (which I don't see > either) > > Rocky > > > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman > Sent: Monday, July 30, 2007 2:23 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > Rocky > ...I think you'll find that reference is to pre A2K printer functionality > using api calls ...Access has its own printer object now. > William Hindman > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 4:43 PM > Subject: Re: [AccessD] Change Printers > > >> Looks like the right stuff. I also found this - if anybody's >> interested or has the same problem - but I haven't tried it. >> >> http://www.mvps.org/access/reports/rpt0009.htm >> >> Rocky >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William >> Hindman >> Sent: Monday, July 30, 2007 12:28 PM >> To: Access Developers discussion and problem solving >> Subject: Re: [AccessD] Change Printers >> >> ...try http://allenbrowne.com/AppPrintMgt.html >> William Hindman >> ----- Original Message ----- >> From: "Rocky Smolin at Beach Access Software" >> To: "'Access Developers discussion and problem solving'" >> >> Sent: Monday, July 30, 2007 2:36 PM >> Subject: Re: [AccessD] Change Printers >> >> >>> As soon as I hard code it, they'll change it. So I'd prefer the more >>> flexible route if it's not too much time to do. >>> >>> Also, makes it easier to test. But you're right - if I can't get a >>> chunk of code going in short order, that's what I'll do. The client >>> is actually 4 minutes from the house so dropping in to do the last >>> tweaks and tests is easy. But it would be a nice module to have in >>> the library. >>> >>> Rocky >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: accessd-bounces at databaseadvisors.com >>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William >>> Hindman >>> Sent: Monday, July 30, 2007 11:18 AM >>> To: Access Developers discussion and problem solving >>> Subject: Re: [AccessD] Change Printers >>> >>> Rocky >>> ...if the Form is meant to only print the labels on the roll printer, >>> why not set it as the "specific" printer in the form's print >>> properties ...that way you don't get the user involved in the printer >>> selection process ...I usually do this with badge printers. >>> William Hindman >>> >>> ----- Original Message ----- >>> From: "Rocky Smolin at Beach Access Software" >>> >>> To: "'Access Developers discussion and problem solving'" >>> >>> Sent: Monday, July 30, 2007 1:50 PM >>> Subject: [AccessD] Change Printers >>> >>> >>>> Dear List: >>>> >>>> I have a client who wants to print some labels on a roll printer so >>>> when they open the form that prints the labels, I'd like them to >>>> have a combo box of installed printers (or alternatively a 'browse >>>> for printer' >>>> function), >>>> save the default printer, change to the selected printer, print the >>>> label, and change back to the default printer. >>>> >>>> I know I've done this but I can't find the module where I did it. >>>> Does anyone a code snip that does this? >>>> >>>> MTIA >>>> >>>> Rocky >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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 incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: >>> 7/29/2007 >>> 11:14 PM >>> >>> >>> -- >>> 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 incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: >> 7/29/2007 >> 11:14 PM >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 > 11:14 PM > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From anitatiedemann at gmail.com Mon Jul 30 19:50:18 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Tue, 31 Jul 2007 10:50:18 +1000 Subject: [AccessD] Grid Control In-Reply-To: <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <46AE7617.9020204@mvps.org> <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> Message-ID: I use the Janus GridEX 2000 ActiveX Control in most of my Access applications. It can be bound to a Recordset, Table or Query. It gives me so much flexibility with a wealth of features. It is not free, but totally worth the cost. Anita On 7/31/07, William Hindman wrote: > > Steve > ...that's an ATL based grid, don't think it will work in Access > William Hindman > ----- Original Message ----- > From: "Steve Schapel" > To: "Access Developers discussion and problem solving" > > Sent: Monday, July 30, 2007 7:36 PM > Subject: Re: [AccessD] Grid Control > > > > Barbara, > > > > It might be worth giving this a try: > > http://www.devexpress.com/Products/ActiveX/XQuantumGrid/Index.xml > > > > I haven't used it myself. But I use the Sidebar control from the same > > company, and it is cool. > > > > Regards > > Steve > > > > > > Barbara Ryan wrote: > >> I normally would use continuous forms, but for this worker "scheduling" > >> form > >> (i.e., rows are worker types; columns are dates "07/01/07", > >> "07/02/07"...) I > >> thought I would check out grid controls to see if they would offer any > >> advantages. > > -- > > 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 BarbaraRyan at cox.net Mon Jul 30 20:02:57 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Mon, 30 Jul 2007 21:02:57 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35><00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <000301c7d30c$4c43d290$517a6c4c@jisshowsbs.local> Message-ID: <014401c7d30e$885ba9e0$0a00a8c0@PCRURI35> William.... The Contacts app that you sent has been very helpful. I forgot about the scheduling app. I will take a look at it --- thanks for reminding me I had it!!! Barb Ryan ----- Original Message ----- From: "William Hindman" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 8:46 PM Subject: Re: [AccessD] Grid Control > Barbara > > ...I think I sent you an all Access vba scheduling grid sample app pretty > much like you describe a few months or so back when you were heading out > on > your own ...you might want to take a look there first ...if you don't find > it, let me know. > > William Hindman > > ----- Original Message ----- > From: "Barbara Ryan" > To: "Access Developers discussion and problem solving" > > Sent: Monday, July 30, 2007 7:01 PM > Subject: Re: [AccessD] Grid Control > > >>I normally would use continuous forms, but for this worker "scheduling" >>form >> (i.e., rows are worker types; columns are dates "07/01/07", >> "07/02/07"...) >> I >> thought I would check out grid controls to see if they would offer any >> advantages. >> >> Barb Ryan >> >> ----- Original Message ----- >> From: "Charlotte Foust" >> To: "Access Developers discussion and problem solving" >> >> Sent: Monday, July 30, 2007 11:55 AM >> Subject: Re: [AccessD] Grid Control >> >> >>> Is there some reason you must have a grid? The built in continuous >>> forms and datasheet forms are much, much easier to work with. >>> >>> Charlotte Foust >>> >>> -----Original Message----- >>> From: accessd-bounces at databaseadvisors.com >>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan >>> Sent: Sunday, July 29, 2007 8:31 AM >>> To: Access List >>> Subject: [AccessD] Grid Control >>> >>> I would like to use a data grid control in Access for data entry. Any >>> suggestions? Free is best :-) >>> >>> Thanks, >>> Barb Ryan >>> -- >>> 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 BarbaraRyan at cox.net Mon Jul 30 20:05:35 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Mon, 30 Jul 2007 21:05:35 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35><00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <46AE7617.9020204@mvps.org><001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> Message-ID: <014a01c7d30e$e69b9fb0$0a00a8c0@PCRURI35> Anita.... I see that there is a trial version. I'll take a look at it. Thanks, Barb ----- Original Message ----- From: "Anita Smith" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 8:50 PM Subject: Re: [AccessD] Grid Control >I use the Janus GridEX 2000 ActiveX Control in most of my Access > applications. It can be bound to a Recordset, Table or Query. It gives me > so > much flexibility with a wealth of features. It is not free, but totally > worth the cost. > > Anita > > > On 7/31/07, William Hindman wrote: >> >> Steve >> ...that's an ATL based grid, don't think it will work in Access >> William Hindman >> ----- Original Message ----- >> From: "Steve Schapel" >> To: "Access Developers discussion and problem solving" >> >> Sent: Monday, July 30, 2007 7:36 PM >> Subject: Re: [AccessD] Grid Control >> >> >> > Barbara, >> > >> > It might be worth giving this a try: >> > http://www.devexpress.com/Products/ActiveX/XQuantumGrid/Index.xml >> > >> > I haven't used it myself. But I use the Sidebar control from the same >> > company, and it is cool. >> > >> > Regards >> > Steve >> > >> > >> > Barbara Ryan wrote: >> >> I normally would use continuous forms, but for this worker >> >> "scheduling" >> >> form >> >> (i.e., rows are worker types; columns are dates "07/01/07", >> >> "07/02/07"...) I >> >> thought I would check out grid controls to see if they would offer any >> >> advantages. >> > -- >> > 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 Mon Jul 30 20:17:53 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 30 Jul 2007 21:17:53 -0400 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files In-Reply-To: References: Message-ID: <29f585dd0707301817t282a66b9g1b59efb70ff241e@mail.gmail.com> Plus you can even do things like copy file1.txt + file2.txt + file3.txt result.txt. Arthur On 7/30/07, Gustav Brock wrote: > > Hi Darren > > Try with COPY /B, that should remove the EOF byte. > > /gustav > From miscellany at mvps.org Mon Jul 30 23:33:40 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 31 Jul 2007 16:33:40 +1200 Subject: [AccessD] Grid Control In-Reply-To: <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <46AE7617.9020204@mvps.org> <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> Message-ID: <46AEBBA4.2010002@mvps.org> William, It does work in Access, but you need to use ADO. Regards Steve William Hindman wrote: > Steve > ...that's an ATL based grid, don't think it will work in Access From michael at ddisolutions.com.au Tue Jul 31 01:33:46 2007 From: michael at ddisolutions.com.au (Michael Maddison) Date: Tue, 31 Jul 2007 16:33:46 +1000 Subject: [AccessD] Going CRUD way... References: <000701c7d2b8$86cb14e0$6401a8c0@nant> Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D01289B43@ddi-01.DDI.local> Hi Guys, Heres a sample of the CRUD generated by NetTiers an a simple lookup table. I've used a couple of times now. Of course it also generates all the C# objects to go with it. IMO for complex systems CRUD makes good sense. CREATE PROCEDURE dbo.Agency_GetPaged ( @WhereClause varchar (2000) , @OrderBy varchar (2000) , @PageIndex int , @PageSize int ) AS BEGIN DECLARE @PageLowerBound int DECLARE @PageUpperBound int -- Set the page bounds SET @PageLowerBound = @PageSize * @PageIndex SET @PageUpperBound = @PageLowerBound + @PageSize -- Create a temp table to store the select results Create Table #PageIndex ( [IndexId] int IDENTITY (1, 1) NOT NULL, [AgencyID] int ) -- Insert into the temp table declare @SQL as nvarchar(4000) SET @SQL = 'INSERT INTO #PageIndex (AgencyID)' SET @SQL = @SQL + ' SELECT' IF @PageSize > 0 BEGIN SET @SQL = @SQL + ' TOP ' + convert(nvarchar, @PageUpperBound) END SET @SQL = @SQL + ' [AgencyID]' SET @SQL = @SQL + ' FROM dbo.[Agency]' IF LEN(@WhereClause) > 0 BEGIN SET @SQL = @SQL + ' WHERE ' + @WhereClause END IF LEN(@OrderBy) > 0 BEGIN SET @SQL = @SQL + ' ORDER BY ' + @OrderBy END -- Populate the temp table exec sp_executesql @SQL -- Return paged results SELECT O.[AgencyID], O.[AgencyName], O.[AgencyAbbr] FROM dbo.[Agency] O, #PageIndex PageIndex WHERE PageIndex.IndexID > @PageLowerBound AND O.[AgencyID] = PageIndex.[AgencyID] ORDER BY PageIndex.IndexID -- get row count SET @SQL = 'SELECT COUNT(*) as TotalRowCount' SET @SQL = @SQL + ' FROM dbo.[Agency]' IF LEN(@WhereClause) > 0 BEGIN SET @SQL = @SQL + ' WHERE ' + @WhereClause END exec sp_executesql @SQL END GO CREATE PROCEDURE dbo.Agency_Delete ( @AgencyID int ) AS DELETE FROM dbo.[Agency] WITH (ROWLOCK) WHERE [AgencyID] = @AgencyID CREATE PROCEDURE dbo.Agency_Find ( @SearchUsingOR bit = null , @AgencyID int = null , @AgencyName nvarchar (50) = null , @AgencyAbbr nvarchar (5) = null ) AS IF ISNULL(@SearchUsingOR, 0) <> 1 BEGIN SELECT [AgencyID] , [AgencyName] , [AgencyAbbr] FROM dbo.[Agency] WHERE ([AgencyID] = @AgencyID OR @AgencyID is null) AND ([AgencyName] = @AgencyName OR @AgencyName is null) AND ([AgencyAbbr] = @AgencyAbbr OR @AgencyAbbr is null) END ELSE BEGIN SELECT [AgencyID] , [AgencyName] , [AgencyAbbr] FROM dbo.[Agency] WHERE ([AgencyID] = @AgencyID AND @AgencyID is not null) OR ([AgencyName] = @AgencyName AND @AgencyName is not null) OR ([AgencyAbbr] = @AgencyAbbr AND @AgencyAbbr is not null) Select @@ROWCOUNT END GO CREATE PROCEDURE dbo.Agency_Get_List AS SELECT [AgencyID], [AgencyName], [AgencyAbbr] FROM dbo.[Agency] Select @@ROWCOUNT GO CREATE PROCEDURE dbo.Agency_GetByAgencyID ( @AgencyID int ) AS SELECT [AgencyID], [AgencyName], [AgencyAbbr] FROM dbo.[Agency] WHERE [AgencyID] = @AgencyID Select @@ROWCOUNT GO CREATE PROCEDURE dbo.Agency_Insert ( @AgencyID int OUTPUT, @AgencyName nvarchar (50) , @AgencyAbbr nvarchar (5) ) AS INSERT INTO dbo.[Agency] ( [AgencyName] ,[AgencyAbbr] ) VALUES ( @AgencyName , at AgencyAbbr ) -- Get the identity value SET @AgencyID = SCOPE_IDENTITY() GO CREATE PROCEDURE dbo.Agency_Update ( @AgencyID int , @AgencyName nvarchar (50) , @AgencyAbbr nvarchar (5) ) AS -- Modify the updatable columns UPDATE dbo.[Agency] SET [AgencyName] = @AgencyName ,[AgencyAbbr] = @AgencyAbbr WHERE [AgencyID] = @AgencyID GO cheers Michael M To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Going CRUD way... Hello Arthur, Thank you for your prompt feedback. May I say you're a "generated CRUDs fun"? (I'm getting like that here too therefore this "generated CRUDs fun" is a respectful nickname here :) ...) Do you have any samples of small CRUDs, which you use *in production*, which therefore proved themselves as stable and which you can publish here? - just one for every type of CRUD (Insert, Update, Delete SQL) + Select (by Id) SQL... Thank you. I must say that views used with WinForms (.NET 2.0), even when parameters are used but when views are run against large amounts of back-end data - such views are (very) slow comparing to parameterized stored procedures. I do use views but only as a "middle-/abstraction tier" between SPs and base tables... -- Shamil P.S. Here is a sample of Update SP I use made based on what OlyMars originally did generate - writing that stuff manually is a "no-go" obviously: if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[a_Table_Update]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) drop procedure [dbo].[a_Table_Update] GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO CREATE Procedure [a_Table_Update] -- Update an existing record in [a_Table] table ( @rowId [int] = Null -- for [a_Table].[ID] column , @ConsiderNull_iD bit = 0 , at bitField [bit] = Null -- for [a_Table].[bitField] column , @ConsiderNull_bitField bit = 0 , at intField [int] = Null -- for [a_Table].[intField] column , @ConsiderNull_intField bit = 0 , at decimalField [decimal] = Null -- for [a_Table].[decimalField] column , @ConsiderNull_decimalField bit = 0 , at numericField [numeric] = Null -- for [a_Table].[numericField] column , @ConsiderNull_numericField bit = 0 , at floatField [float] = Null -- for [a_Table].[floatField] column , @ConsiderNull_floatField bit = 0 , at smallMoneyField [smallmoney] = Null -- for [a_Table].[smallMoneyField] column , @ConsiderNull_smallMoneyField bit = 0 , at charField [char](10) = Null -- for [a_Table].[charField] column , @ConsiderNull_charField bit = 0 , at varcharField [varchar](50) = Null -- for [a_Table].[varcharField] column , @ConsiderNull_varcharField bit = 0 , at textField [text] = Null -- for [a_Table].[textField] column , @ConsiderNull_textField bit = 0 , at nvarCharField [nvarchar](50) = Null -- for [a_Table].[nvarCharField] column , @ConsiderNull_nvarCharField bit = 0 , at ntextField [ntext] = Null -- for [a_Table].[ntextField] column , @ConsiderNull_ntextField bit = 0 , at dateTimeField [datetime] = Null -- for [a_Table].[dateTimeField] column , @ConsiderNull_dateTimeField bit = 0 , at uniqueidentifierField [uniqueidentifier] = Null -- for [a_Table].[uniqueidentifierField] column , @ConsiderNull_uniqueidentifierField bit = 0 , at imageField [image] = Null -- for [a_Table].[imageField] column , @ConsiderNull_imageField bit = 0 ) As Set NoCount On Declare @retValue int If @ConsiderNull_iD Is Null Set @ConsiderNull_iD = 0 If @ConsiderNull_bitField Is Null Set @ConsiderNull_bitField = 0 If @ConsiderNull_intField Is Null Set @ConsiderNull_intField = 0 If @ConsiderNull_decimalField Is Null Set @ConsiderNull_decimalField = 0 If @ConsiderNull_numericField Is Null Set @ConsiderNull_numericField = 0 If @ConsiderNull_floatField Is Null Set @ConsiderNull_floatField = 0 If @ConsiderNull_smallMoneyField Is Null Set @ConsiderNull_smallMoneyField = 0 If @ConsiderNull_charField Is Null Set @ConsiderNull_charField = 0 If @ConsiderNull_varcharField Is Null Set @ConsiderNull_varcharField = 0 If @ConsiderNull_textField Is Null Set @ConsiderNull_textField = 0 If @ConsiderNull_nvarCharField Is Null Set @ConsiderNull_nvarCharField = 0 If @ConsiderNull_ntextField Is Null Set @ConsiderNull_ntextField = 0 If @ConsiderNull_dateTimeField Is Null Set @ConsiderNull_dateTimeField = 0 If @ConsiderNull_uniqueidentifierField Is Null Set @ConsiderNull_uniqueidentifierField = 0 If @ConsiderNull_imageField Is Null Set @ConsiderNull_imageField = 0 Update [dbo].[a_Table] Set [rowId] = Case @ConsiderNull_iD When 0 Then IsNull(@rowId, [rowId]) When 1 Then @rowId End , [bitField] = Case @ConsiderNull_bitField When 0 Then IsNull(@bitField, [bitField]) When 1 Then @bitField End , [intField] = Case @ConsiderNull_intField When 0 Then IsNull(@intField, [intField]) When 1 Then @intField End , [decimalField] = Case @ConsiderNull_decimalField When 0 Then IsNull(@decimalField, [decimalField]) When 1 Then @decimalField End , [numericField] = Case @ConsiderNull_numericField When 0 Then IsNull(@numericField, [numericField]) When 1 Then @numericField End , [floatField] = Case @ConsiderNull_floatField When 0 Then IsNull(@floatField, [floatField]) When 1 Then @floatField End , [smallMoneyField] = Case @ConsiderNull_smallMoneyField When 0 Then IsNull(@smallMoneyField, [smallMoneyField]) When 1 Then @smallMoneyField End , [charField] = Case @ConsiderNull_charField When 0 Then IsNull(@charField, [charField]) When 1 Then @charField End , [varcharField] = Case @ConsiderNull_varcharField When 0 Then IsNull(@varcharField, [varcharField]) When 1 Then @varcharField End , [textField] = Case @ConsiderNull_textField When 0 Then IsNull(@textField, [textField]) When 1 Then @textField End , [nvarCharField] = Case @ConsiderNull_nvarCharField When 0 Then IsNull(@nvarCharField, [nvarCharField]) When 1 Then @nvarCharField End , [ntextField] = Case @ConsiderNull_ntextField When 0 Then IsNull(@ntextField, [ntextField]) When 1 Then @ntextField End , [dateTimeField] = Case @ConsiderNull_dateTimeField When 0 Then IsNull(@dateTimeField, [dateTimeField]) When 1 Then @dateTimeField End , [uniqueidentifierField] = Case @ConsiderNull_uniqueidentifierField When 0 Then IsNull(@uniqueidentifierField, [uniqueidentifierField]) When 1 Then @uniqueidentifierField End , [imageField] = Case @ConsiderNull_imageField When 0 Then IsNull(@imageField, [imageField]) When 1 Then @imageField End Where ([rowId] = @rowId) select @retValue = @@ERROR Set NoCount Off Return(@retValue) GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 30, 2007 5:02 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Going CRUD way... Since you wrote this to the AccessD list, I'll begin there with my response. I'm currently doing an ADP for a riding stable (which will soon be for sale, so if any listers have any friends with riding stables... LOL). The general approach in it is forms bound to views. (Nobody but me gets to talk directly to tables.) Some of the views use table-UDFs to simplify joins. All of the combo-boxes and list-boxes use named queries (views) to retrieve their contents. This app is simple, so there's not much need for complicated sprocs, except here and there. These fall mainly in the Reports realm; a dialog box opens, requests parameters such as "Horse", Start Date and End Date, then invokes the report which invokes the sproc and passes the parameters, so you end up with a cross-tab report showing the particular horse's activities ( group lesson, private lesson, sem-private lesson, injury day, etc.) during the date range. In the larger scheme of things, I use ERwin. Its code-gen capabilities are totally wonderful. It has a template language built-in which will generate your CRUD code automatically, and even give you a choice between returning a rowset and a set out OUTPUT parameters. I hadn't realized the benefit of the latter strategy until I worked on a large project with my friend Dejan Sunderic (who wrote a great book about SQL 2005). That type of sproc is useful only when you want exactly one record back, but if you're searching millions of rows, it's demonstrably faster than returning a rowset. You don't even need a timer to note the difference. In Access, there are significant advantages to using views as the data source, IMO, not the least of which is how easily subforms behave. Access does the dirty work for you. You just create a subform based on a view, plonk it onto a master form, and Access handles the plumbing. It couldn't be easier, and in addition you insulate the actual tables. Suppose that your app contains a form that only selected people (let's call them Managers) ought to see. So in SQL you create a Managers role and grant access to the view(s) in question. Then even if you forget to program around it in your Access app, it's ok -- no one but managers will be able to run that report. The message they will receive isn't elegant, but the data is safe. I'm not an ERwin expert but I have worked with one or two. At one point, I asked my friend and colleague Andrei Pascal whether we could customize the template to place what ERwin calls a description into the Extended Properties code. It took Andrei about 5 minutes to modify the template so it did this. That's two "hats off" -- one to the template language and one to Andrei. The template language is pretty much beyond my feeble intellect, but Andrei just whipped out a tiny little loop that walked every table and added an extended property to every table for every column that had a Description, and poof! All done. I used to hate ERwin and I much preferred PowerDesigner and Dezign (whose interface is pretty much a clone of PowerDesigner, although it lacks lots of the PD power). I was dragged kicking and screaming into using ERwin, but have since grown into an enthusiast, not least because generating CRUD and even customized CRUD is a one-click operation. Arthur On 7/30/07, Shamil Salakhetdinov wrote: > > Hi All, > > It looks like we haven't yet have here CRUD vs. (mainly) dynamic > manually written SQL vs. metadata-driven application (frameworks) > development debate? > Or did I miss it? > > Anyway my question is what do you prefer to use when developing > applications against MS SQL backend:? > > - 1) CRUD SPs based approach to work with base tables + custom > SPs(views, > UDFs,...) to implement custom functionality - and SPs only "visible to > outer world"? > > - 2) dynamic SQL - DAO, ADO, ADO.NET (mainly) manually written etc. > with or without SPs (views, UDFs,...)? > > - 3) metadata driven (flexible) dynamic SQL approach? > > - 4) you do not use not the first not the second not the third > approach - you do use a "mixture" of them IOW you just write code to > implement custom functionality and whatever approach to use in every > certain case you usually decide as you go... > > - 5) something else (please add other useful approached I missed to > mention here)... > > Thank you. > > > -- > Shamil > > > > -- > 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 adtp at airtelbroadband.in Tue Jul 31 07:29:29 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Tue, 31 Jul 2007 17:59:29 +0530 Subject: [AccessD] Get all controls on all forms References: <586905.71583.qm@web31611.mail.mud.yahoo.com> Message-ID: <005201c7d36e$8ea6d530$7357a27a@pcadt> Sander, Sample subroutine P_ListAllControlsAllForms(), as given below, will populate table named T_AllControls with the names of all forms in the db as well as all controls thereon, along with particulars of ControlType. If any form happens to be blank (no controls), its name will appear against field FormName, leaving the ControlName & ControlType fields blank. Before using this procedure, please make sure that table T_AllControls is available, with fields named FormName (text type), ControlName (text type) and ControlType (number type). Note: This procedure should preferably be run directly from VBA window. If you wish to run it from a test form, the code should be modified suitably so as to prevent opening of that test form. This is because, each form in AllForms collection gets opened turn by turn, in design view. If test form also gets opened in design view, further execution of code will get interrupted. Best wishes, A.D.Tejpal --------------- Sample Subroutine (For listing all forms & their controls) ==================================== Sub P_ListAllControlsAllForms() Dim obj As AccessObject, ct As Control Dim rst As DAO.Recordset Dim FormName As String ' Clear existing contents of table T_AllControls CurrentDb.Execute "DELETE FROM " & _ "T_AllControls;", dbFailOnError Set rst = CurrentDb.OpenRecordset("T_AllControls") For Each obj In CurrentProject.AllForms FormName = obj.Name DoCmd.OpenForm FormName, acDesign If Forms(FormName).Controls.Count > 0 Then For Each ct In Forms(FormName).Controls rst.AddNew With rst.Fields !FormName = FormName !ControlName = ct.Name !ControlType = ct.ControlType End With rst.Update Next Else rst.AddNew rst.Fields("FormName") = FormName rst.Update End If DoCmd.Close acForm, FormName, acSaveNo Next rst.Close Set rst = Nothing Set ct = Nothing Set obj = Nothing End Sub ==================================== ----- Original Message ----- From: Sad Der To: Acces User Group Sent: Monday, July 30, 2007 19:25 Subject: [AccessD] Get all controls on all forms Hi group, Does anybody have piece of code that retrieves all controles on all forms in a database? I need to store these in a database. Thnx! Regards, Sander From rockysmolin at bchacc.com Tue Jul 31 12:07:49 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 31 Jul 2007 10:07:49 -0700 Subject: [AccessD] Calling Subform Routine from Main Form Message-ID: <003e01c7d395$535bc720$0301a8c0@HAL9005> Dear List: I can never remember this syntax: I want to call a sub in a subform from the main form's Current event. Does anyone know this offhand? MTIA Rocky From robert at webedb.com Tue Jul 31 12:14:42 2007 From: robert at webedb.com (Robert L. Stewart) Date: Tue, 31 Jul 2007 12:14:42 -0500 Subject: [AccessD] Going CRUD way... In-Reply-To: References: Message-ID: <200707311720.l6VHKCqK029241@databaseadvisors.com> Michael, The SPs generated by netTiers go beyond a simple CRUD system. They generate a paged get like the first one you listed. But, they also generate a read by each of the foreign keys if you define then in the SQL DB. They are very good and what I use for development in Visual Studio. No, I do not use my CRUD generator for my VS development. It was developed for my day job where the environment is ColdFusion and Access 97. After doing ,Net development for the last 3 years, I finally found Codesmith and netTiers and will probably never write another data layer of my own again. I see no reason to reinvent the wheel when there is one that works so well already. Robert At 12:00 PM 7/31/2007, you wrote: >Date: Tue, 31 Jul 2007 16:33:46 +1000 >From: "Michael Maddison" >Subject: Re: [AccessD] Going CRUD way... >To: "Access Developers discussion and problem solving" > >Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D01289B43 at ddi-01.DDI.local> >Content-Type: text/plain; charset="us-ascii" > >Hi Guys, > >Heres a sample of the CRUD generated by NetTiers an a simple lookup >table. >I've used a couple of times now. >Of course it also generates all the C# objects to go with it. > >IMO for complex systems CRUD makes good sense. From rockysmolin at bchacc.com Tue Jul 31 13:08:02 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 31 Jul 2007 11:08:02 -0700 Subject: [AccessD] Calling Subform Routine from Main Form In-Reply-To: <003e01c7d395$535bc720$0301a8c0@HAL9005> Message-ID: <004b01c7d39d$bd4413b0$0301a8c0@HAL9005> Think I got it. Had to make the routing in the subform Public. And then: Call Me.Child293.Form.UpdateFilter Seems to work. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Tuesday, July 31, 2007 10:08 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Calling Subform Routine from Main Form Dear List: I can never remember this syntax: I want to call a sub in a subform from the main form's Current event. Does anyone know this offhand? MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM From Lambert.Heenan at AIG.com Tue Jul 31 13:11:49 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Tue, 31 Jul 2007 13:11:49 -0500 Subject: [AccessD] Calling Subform Routine from Main Form Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6D33@xlivmbx35.aig.com> Your it call from the main form with.. Me.SubformControlName.Form.RoutineName If you want to call the routine from any place other than the subform or its parent form then the routine needs to be made Public and you would call it with... Forms("MainFomrName").SubformControlName.Form.RoutineName HTH Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Tuesday, July 31, 2007 1:08 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Calling Subform Routine from Main Form Dear List: I can never remember this syntax: I want to call a sub in a subform from the main form's Current event. Does anyone know this offhand? MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Tue Jul 31 18:05:40 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 31 Jul 2007 16:05:40 -0700 Subject: [AccessD] Calling Subform Routine from Main Form In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6D33@xlivmbx35.aig.com> Message-ID: <007701c7d3c7$50f11d00$0301a8c0@HAL9005> Thanks Lambert. That works. I just can't remember how to do it from time to time. Old age I guess... Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Tuesday, July 31, 2007 11:12 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Calling Subform Routine from Main Form Your it call from the main form with.. Me.SubformControlName.Form.RoutineName If you want to call the routine from any place other than the subform or its parent form then the routine needs to be made Public and you would call it with... Forms("MainFomrName").SubformControlName.Form.RoutineName HTH Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Tuesday, July 31, 2007 1:08 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Calling Subform Routine from Main Form Dear List: I can never remember this syntax: I want to call a sub in a subform from the main form's Current event. Does anyone know this offhand? MTIA Rocky -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM From jwcolby at colbyconsulting.com Tue Jul 31 21:46:48 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 31 Jul 2007 22:46:48 -0400 Subject: [AccessD] Hamachi on the road Message-ID: <20070801024649.DBE60BD3B@smtp-auth.no-ip.com> I set up Hamachi on my three servers before I left home, as well as my laptop which I have with me. I bought the pay version, one month license, for each server. That basically gives me the ability to load it as a service which is not available with the free version. Tonight I am in a hotel with "high speed internet" and I can see all of the shares on all of my servers, right over the Hamachi link. I can also remote desktop in to all three machines over the Hamachi IP address. COOL stuff. John W. Colby Colby Consulting www.ColbyConsulting.com From darrend at nimble.com.au Tue Jul 31 22:22:21 2007 From: darrend at nimble.com.au (Darren D) Date: Wed, 1 Aug 2007 13:22:21 +1000 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files In-Reply-To: Message-ID: <200708010322.l713MKjY019538@databaseadvisors.com> Hi Gustav et al The COPY /B worked Donald the Type >> line is excellent - I can see a use for this already Many thanks to those who responded The final syntax was... COPY /B Header.txt + *.xml + Footer.txt MyAyCoolAndWayBig.XML Thanks DD -----Original Message----- From: Gustav Brock [mailto:gustav at cactus.dk] Sent: Tuesday, 31 July 2007 7:59 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Kinda OT:A2003 Calling a batch file - merging files Hi Darren Try with COPY /B, that should remove the EOF byte. /gustav >>> martyconnelly at shaw.ca 30-07-07 20:19 >>> Could be a couple of things, I haven't got an Ascii Table handy Have a look at last char in HexEditor. At a guess it could CTRL-Z which is an old DOS EOF McGillivray, Don [IT] wrote: >Darren, > >I've done something similar by redirecting the output of the DOS "type" command to a file. I've never had an issue with extraneous characters using this method. Something like this: > >Type *.fil >> BigFile.txt > >This concatenates the contents of all files with the extension "fil" into a single file called BigFile.txt. Don't know if the order of concatenation is predictable, if that's important to you. > >As for inserting text between additions or at either end, I think you can redirect the DOS "echo" command in a similar way. Something like: > >Echo "Start of file" >> BigFile.txt >Type *.fil >> BigFile.txt >Echo "End of file" >> BigFile.txt > >Hope this helps . . . > >Don > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D >Sent: Sunday, July 29, 2007 4:30 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files > >Hi all > > > >I am calling a batch file from my access app > > > >The batch file just 'merges' a few files into one big file and then gives it a >name > > > >This is the batch file - Very basic - 1 liner - > > > >copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt >mynewcoolcombinedfile.XML > > > >Pretty basic - but the combining leaves a small ascii type square as the very >very last character - Like this ---> > > > >Anyone know how to stop this from happening? > > > >Or even better - How to 'build' or merge a few files into one big file - from >VBA > > > >Or even better still - How to insert Text eg Merge > > > >"This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into >OneCoolFile.XML > > > >Many thanks in advance > > > >DD -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bhjohnson at verizon.net Tue Jul 31 23:40:09 2007 From: bhjohnson at verizon.net (Bruce H. Johnson) Date: Tue, 31 Jul 2007 21:40:09 -0700 Subject: [AccessD] Hamachi on the road In-Reply-To: <20070801024649.DBE60BD3B@smtp-auth.no-ip.com> References: <20070801024649.DBE60BD3B@smtp-auth.no-ip.com> Message-ID: <005701c7d3f6$0afa9b80$0201a8c0@HALSR> I've had decent results with Hamachi over the Internet. As well, I use the free versions of LogMeIn (logmein.com). With Hamachi seeming to be part of LogMeIn (it's on the web site), I can do a remote control of my home system from pretty much any Internet connection. If I need a file or so, I can either email it (free version of LogMeIn doesn't have file xfer) or fire up Hamachi on both ends. It's worked well for me, too. Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 31, 2007 7:47 PM To: 'Access Developers discussion and problem solving'; 'Discussion of Hardware and Software issues' Subject: [AccessD] Hamachi on the road I set up Hamachi on my three servers before I left home, as well as my laptop which I have with me. I bought the pay version, one month license, for each server. That basically gives me the ability to load it as a service which is not available with the free version. Tonight I am in a hotel with "high speed internet" and I can see all of the shares on all of my servers, right over the Hamachi link. I can also remote desktop in to all three machines over the Hamachi IP address. COOL stuff. John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM From djkr at msn.com Sun Jul 1 05:07:03 2007 From: djkr at msn.com (DJK(John) Robinson) Date: Sun, 1 Jul 2007 11:07:03 +0100 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) In-Reply-To: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> Message-ID: Hi Joe, Not sure I fully understand the setup, but here goes. Since your question is about ordering the seeing of notes, I presume you already have some access control in place, so that the system knows whether the current user is D,S,M or E (Dispatcher, Supervisor, etc). I'd probably put all the notes in one table, with each record time-stamped on creation, and identified by employee and creator-type (S,M or E). Then querying can exclude records that the current user shouldn't see, and order on the creation time-stamp. If for some reason you *have* to have separate tables, then still time-stamp records on creation, but use an appropriate union query to bring together the right set for the current user. Or have I misunderstood something? John -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe Hecht Sent: 01 July 2007 00:08 To: 'Access Developers discussion and problem solving' Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Sun Jul 1 07:59:17 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 08:59:17 -0400 Subject: [AccessD] Open a combobox on entering it Message-ID: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> In a couple of apps I've seen, the comboboxes automatically open when you enter them. How is that done? I'm working on an app where the lists are smallish and I'd like to do it. Arthur From ssharkins at setel.com Sun Jul 1 08:12:13 2007 From: ssharkins at setel.com (Susan Harkins) Date: Sun, 1 Jul 2007 09:12:13 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> References: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> Message-ID: <002e01c7bbe1$71993450$2534fad1@SusanOne> Use the control's Dropdown property Susan H. In a couple of apps I've seen, the comboboxes automatically open when you enter them. How is that done? I'm working on an app where the lists are smallish and I'd like to do it. Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.10/873 - Release Date: 6/26/2007 11:54 PM From fuller.artful at gmail.com Sun Jul 1 08:29:57 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 09:29:57 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <002e01c7bbe1$71993450$2534fad1@SusanOne> References: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> <002e01c7bbe1$71993450$2534fad1@SusanOne> Message-ID: <29f585dd0707010629s49d0e71am31470d2f846ac354@mail.gmail.com> I'd love to, but I can't find it. It's an Access 2003 ADP. Does that matter? Arthur On 7/1/07, Susan Harkins wrote: > > Use the control's Dropdown property > > Susan H. > > In a couple of apps I've seen, the comboboxes automatically open when you > enter them. How is that done? I'm working on an app where the lists are > smallish and I'd like to do it. > > Arthur > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.9.10/873 - Release Date: 6/26/2007 > 11:54 PM > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From ssharkins at setel.com Sun Jul 1 08:39:35 2007 From: ssharkins at setel.com (Susan Harkins) Date: Sun, 1 Jul 2007 09:39:35 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707010629s49d0e71am31470d2f846ac354@mail.gmail.com> References: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com><002e01c7bbe1$71993450$2534fad1@SusanOne> <29f585dd0707010629s49d0e71am31470d2f846ac354@mail.gmail.com> Message-ID: <003d01c7bbe5$45e88640$2534fad1@SusanOne> Well Arthur, I guess that's possible, but I don't know why -- the control is still an Access object isn't it? You'd think it would still be available. Susan H. I'd love to, but I can't find it. It's an Access 2003 ADP. Does that matter? From fuller.artful at gmail.com Sun Jul 1 08:44:51 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 09:44:51 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <003d01c7bbe5$45e88640$2534fad1@SusanOne> References: <29f585dd0707010559x140622c7gb9da5bd78ab70e65@mail.gmail.com> <002e01c7bbe1$71993450$2534fad1@SusanOne> <29f585dd0707010629s49d0e71am31470d2f846ac354@mail.gmail.com> <003d01c7bbe5$45e88640$2534fad1@SusanOne> Message-ID: <29f585dd0707010644t19151d2es281f7c491adfc86f@mail.gmail.com> It's not in the Intellisense either. I think I'll try opening the app in Access 2000 and see if it's there. On 7/1/07, Susan Harkins wrote: > > Well Arthur, I guess that's possible, but I don't know why -- the control > is > still an Access object isn't it? You'd think it would still be available. > > Susan H. > > I'd love to, but I can't find it. It's an Access 2003 ADP. Does that > matter? > > From rockysmolin at bchacc.com Sun Jul 1 09:06:25 2007 From: rockysmolin at bchacc.com (rockysmolin at bchacc.com) Date: Sun, 1 Jul 2007 10:06:25 -0400 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) Message-ID: <380-2200770114625873@M2W040.mail2web.com> Joe: I've got a simple schemeto control access levels. I can handle it with you off line. But I'm out of town right now. Won't be back until next Sunday. Can it wait? Anyone who knows access can defeat this scheme but in an environment where people are behaving this works well. Here's the basic steps: 1. Create a User table - Autonumber, User Name, Password, Accesss Level. 2. Create a global variable gintAccessLevel 3. On the opening form load the names and passwords into a combo box. Prompt for user name and password. 4. Store user's access level in gintAccessLevel. 5. On each form oreach function where you want to restrict access check the user access level and bail if the level's not correct. HTH ROcky Original Message: ----------------- From: Joe Hecht jmhecht at earthlink.net Date: Sat, 30 Jun 2007 16:08:12 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web From rockysmolin at bchacc.com Sun Jul 1 09:09:55 2007 From: rockysmolin at bchacc.com (rockysmolin at bchacc.com) Date: Sun, 1 Jul 2007 10:09:55 -0400 Subject: [AccessD] Open a combobox on entering it Message-ID: <380-2200770114955828@M2W008.mail2web.com> Me.cboMyBox.DropDown won't work in the Got Focus event of the box? Rocky Original Message: ----------------- From: Arthur Fuller fuller.artful at gmail.com Date: Sun, 1 Jul 2007 08:59:17 -0400 To: accessd at databaseadvisors.com Subject: [AccessD] Open a combobox on entering it In a couple of apps I've seen, the comboboxes automatically open when you enter them. How is that done? I'm working on an app where the lists are smallish and I'd like to do it. Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- mail2web.com ? What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint From fuller.artful at gmail.com Sun Jul 1 10:10:03 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 11:10:03 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <380-2200770114955828@M2W008.mail2web.com> References: <380-2200770114955828@M2W008.mail2web.com> Message-ID: <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> That was the ticket. Thanks, Rocky. I was using OnEnter. Now it works. Yay!. On 7/1/07, rockysmolin at bchacc.com wrote: > > Me.cboMyBox.DropDown won't work in the Got Focus event of the box? > > Rocky > > > Original Message: > ----------------- > From: Arthur Fuller fuller.artful at gmail.com > Date: Sun, 1 Jul 2007 08:59:17 -0400 > To: accessd at databaseadvisors.com > Subject: [AccessD] Open a combobox on entering it > > > In a couple of apps I've seen, the comboboxes automatically open when you > enter them. How is that done? I'm working on an app where the lists are > smallish and I'd like to do it. > > Arthur > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > > -------------------------------------------------------------------- > mail2web.com ? What can On Demand Business Solutions do for you? > http://link.mail2web.com/Business/SharePoint > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From fuller.artful at gmail.com Sun Jul 1 12:06:47 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 13:06:47 -0400 Subject: [AccessD] Never Take a job for a friend (Three level design question) In-Reply-To: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> Message-ID: <29f585dd0707011006w7126a816l9f2ee03b307d66eb@mail.gmail.com> I think that some of the respondents so far kind of missed your requirements, Joe (or perhaps the beer I'm enjoying for Canada has had more effect than I anticipated). You actually have only 3 meaningful user levels, since dispatchers are powerless. The other three make a grid like this: Sup Mgr Exec Sup W X X Mgr R W X Exec R R W Where R means Read, W means Write, and X means neither. If the user table contained a 3-char column with each horizontal combination written as a string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine the current row's notes field and act accordingly. This demands of course that the Notes rows be tagged with UserLevel column (S, M or E). If a Sup is looking and the current Notes.UserLevel column contains M or E, hide the Notes. If a Mgr is looking and the current Notes UserLevel contains S, then Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. If an Exec is looking, and the current Notes UserLevl contains S or M, Notes.enabled = False, else Notes.Enabled = True. I think that covers it. hth, Arthur This problem will be much easier to deal with if the notes are presented in single-form fashion rather than datasheet. That said, On 6/30/07, Joe Hecht wrote: > > It is simple. Ya Right > > > > I am righting a poor mans HR program. There are four user levels. > Dispatchers can not do notes, can not see notes. Field supervisor can > write > notes. Can not see manager or executive notes. Managers can write notes, > can read Field supervisor notes, not edit them or see executive notes. > Executives can write theirs, see but not edit all other notes. > > > > Notes are many notes to one employee. > > > > How do I do notes so people see them in chronological order? If I do three > sub tables how would I get all notes to same point. One employee can have > multiple incidents good and bad in their record. How would I get all three > levels of notes to same incident? > > > > Ya all know where I am spending my sat night. > > > > > > > > Joe Hecht > > jmhecht at earthlink.net > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From fuller.artful at gmail.com Sun Jul 1 12:07:49 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 13:07:49 -0400 Subject: [AccessD] Never Take a job for a friend (Three level design question) In-Reply-To: <29f585dd0707011006w7126a816l9f2ee03b307d66eb@mail.gmail.com> References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> <29f585dd0707011006w7126a816l9f2ee03b307d66eb@mail.gmail.com> Message-ID: <29f585dd0707011007s2bb4f993s9e9b8638acf37813@mail.gmail.com> Minor addendum, perhaps obvious. If a dispatcher is looking, hide the Notes, period. Arthur On 7/1/07, Arthur Fuller wrote: > > I think that some of the respondents so far kind of missed your > requirements, Joe (or perhaps the beer I'm enjoying for Canada has had more > effect than I anticipated). > > You actually have only 3 meaningful user levels, since dispatchers are > powerless. The other three make a grid like this: > > Sup Mgr Exec > Sup W X X > Mgr R W X > Exec R R W > > Where R means Read, W means Write, and X means neither. If the user table > contained a 3-char column with each horizontal combination written as a > string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine the > current row's notes field and act accordingly. > > This demands of course that the Notes rows be tagged with UserLevel column > (S, M or E). > > If a Sup is looking and the current Notes.UserLevel column contains M or > E, hide the Notes. > If a Mgr is looking and the current Notes UserLevel contains S, then > Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. > If an Exec is looking, and the current Notes UserLevl contains S or M, > Notes.enabled = False, else Notes.Enabled = True. > > I think that covers it. > > hth, > Arthur > > > This problem will be much easier to deal with if the notes are presented > in single-form fashion rather than datasheet. That said, > > > On 6/30/07, Joe Hecht wrote: > > > > It is simple. Ya Right > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > Dispatchers can not do notes, can not see notes. Field supervisor can > > write > > notes. Can not see manager or executive notes. Managers can write > > notes, > > can read Field supervisor notes, not edit them or see executive notes. > > Executives can write theirs, see but not edit all other notes. > > > > > > > > Notes are many notes to one employee. > > > > > > > > How do I do notes so people see them in chronological order? If I do > > three > > sub tables how would I get all notes to same point. One employee can > > have > > multiple incidents good and bad in their record. How would I get all > > three > > levels of notes to same incident? > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > Joe Hecht > > > > jmhecht at earthlink.net > > > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > From miscellany at mvps.org Sun Jul 1 15:36:12 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 08:36:12 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> Message-ID: <4688103C.7040209@mvps.org> Arthur, I'm pleased you have it working. However, I am not sure what the problem was before. I have often done this on the Enter event of a combobox, and I think it has always worked for me. Regards Steve Arthur Fuller wrote: > That was the ticket. Thanks, Rocky. I was using OnEnter. Now it works. Yay!. > From fuller.artful at gmail.com Sun Jul 1 16:35:10 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 1 Jul 2007 17:35:10 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <4688103C.7040209@mvps.org> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> Message-ID: <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> Maybe it did in prior versions, but in 2003 it's easy enough to check. Whip up a test screen with a combo on it and then open the OnEnter event and use intellisense. The dropdown attribute disappears from the list. Arthur On 7/1/07, Steve Schapel wrote: > > Arthur, > > I'm pleased you have it working. However, I am not sure what the > problem was before. I have often done this on the Enter event of a > combobox, and I think it has always worked for me. > > Regards > Steve > > > Arthur Fuller wrote: > > That was the ticket. Thanks, Rocky. I was using OnEnter. Now it works. > Yay!. > > > - From miscellany at mvps.org Sun Jul 1 17:33:21 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 10:33:21 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> Message-ID: <46882BB1.4080200@mvps.org> Hi Arthur, I have been working with Access 2003 almost exclusively for several years, so very familiar with it. I would have used this method hundreds of times. I have no explanation for why this is not working for you. Me.NameOfYourCombobox.Dropdown Regards Steve Arthur Fuller wrote: > Maybe it did in prior versions, but in 2003 it's easy enough to check. Whip > up a test screen with a combo on it and then open the OnEnter event and use > intellisense. The dropdown attribute disappears from the list. From jmhecht at earthlink.net Sun Jul 1 22:08:56 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Sun, 1 Jul 2007 20:08:56 -0700 Subject: [AccessD] Code help please Message-ID: <003601c7bc56$54b69650$6701a8c0@ACER2G> Hi all wise and mighty list. A2k3 I have a field job title. All job titles require license information unless job tile = admin Silly me I set required in table rules. I need some code that says something like If job title <> "admin" (string) Then Issueing agency .required = true Licenseexp.required = true dotExpdate.required =true I do not see a .required property that I can set in code. TIA Joe Hecht jmhecht at earthlink.net From miscellany at mvps.org Sun Jul 1 22:35:25 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 15:35:25 +1200 Subject: [AccessD] Code help please In-Reply-To: <003601c7bc56$54b69650$6701a8c0@ACER2G> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> Message-ID: <4688727D.6020205@mvps.org> Hi Joe, I think there are two approaches you could take here. First approach... Go to the design view of the table. Set the Required property for all these fields to No. Select 'Properties' from the View menu. In the Validation Rule property, something like this... ([job title]="admin") Or ([Issueing agency] Is Not Null And [Licenseexp] Is Not Null And [dotExpdate] Is Not Null) Validation Text property can be set as required. This assumes no Default Values. Second approach... Code on the Before Update event of the form, for example... If Me.job_title <> "admin" Then If IsNull(Me.Issueing_agency + Me.Licenseexp + Me.dotExpdate) Then MsgBox "Some stuff missing" End If End If Regards Steve Joe Hecht wrote: > Hi all wise and mighty list. > > > > A2k3 > > > > I have a field job title. > > > > All job titles require license information unless job tile = admin > > > > Silly me I set required in table rules. > > > > I need some code that says something like > > > > If job title <> "admin" (string) > > > > Then > > > > Issueing agency .required = true > > Licenseexp.required = true > > dotExpdate.required =true > > > > I do not see a .required property that I can set in code. > > > > TIA > > > > > > > > > > > > Joe Hecht > > jmhecht at earthlink.net > > > From jmhecht at earthlink.net Sun Jul 1 22:42:20 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Sun, 1 Jul 2007 20:42:20 -0700 Subject: [AccessD] Code help please In-Reply-To: <4688727D.6020205@mvps.org> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> <4688727D.6020205@mvps.org> Message-ID: <003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> I will take a look. Still would prefer to code the required field by field. Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 01, 2007 8:35 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Code help please Hi Joe, I think there are two approaches you could take here. First approach... Go to the design view of the table. Set the Required property for all these fields to No. Select 'Properties' from the View menu. In the Validation Rule property, something like this... ([job title]="admin") Or ([Issueing agency] Is Not Null And [Licenseexp] Is Not Null And [dotExpdate] Is Not Null) Validation Text property can be set as required. This assumes no Default Values. Second approach... Code on the Before Update event of the form, for example... If Me.job_title <> "admin" Then If IsNull(Me.Issueing_agency + Me.Licenseexp + Me.dotExpdate) Then MsgBox "Some stuff missing" End If End If Regards Steve Joe Hecht wrote: > Hi all wise and mighty list. > > > > A2k3 > > > > I have a field job title. > > > > All job titles require license information unless job tile = admin > > > > Silly me I set required in table rules. > > > > I need some code that says something like > > > > If job title <> "admin" (string) > > > > Then > > > > Issueing agency .required = true > > Licenseexp.required = true > > dotExpdate.required =true > > > > I do not see a .required property that I can set in code. > > > > TIA > > > > > > > > > > > > Joe Hecht > > jmhecht at earthlink.net > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Sun Jul 1 22:52:03 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 15:52:03 +1200 Subject: [AccessD] Code help please In-Reply-To: <003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> <4688727D.6020205@mvps.org> <003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> Message-ID: <46887663.6000404@mvps.org> Hi Joe, Joe Hecht wrote: > Still would prefer to code the required field by field. As far as I know, this is not possible. Regards Steve From miscellany at mvps.org Sun Jul 1 22:55:04 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 15:55:04 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> Message-ID: <46887718.30704@mvps.org> Hi Arthur, I just had a further thought about this... You need to use the name of the combobox. If you have named the control different from the field it is bound to, and if you are using the name of the field in your code, you will have problems. Regards Steve Arthur Fuller wrote: > Maybe it did in prior versions, but in 2003 it's easy enough to check. Whip > up a test screen with a combo on it and then open the OnEnter event and use > intellisense. The dropdown attribute disappears from the list. > From jmhecht at earthlink.net Sun Jul 1 22:57:01 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Sun, 1 Jul 2007 20:57:01 -0700 Subject: [AccessD] Code help please In-Reply-To: <46887663.6000404@mvps.org> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> <4688727D.6020205@mvps.org><003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> <46887663.6000404@mvps.org> Message-ID: <004901c7bc5d$0c55d2c0$6701a8c0@ACER2G> Thanks for help Steve Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 01, 2007 8:52 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Code help please Hi Joe, Joe Hecht wrote: > Still would prefer to code the required field by field. As far as I know, this is not possible. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Sun Jul 1 23:07:09 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 16:07:09 +1200 Subject: [AccessD] Code help please In-Reply-To: <46887663.6000404@mvps.org> References: <003601c7bc56$54b69650$6701a8c0@ACER2G> <4688727D.6020205@mvps.org> <003b01c7bc5a$feb4aa80$6701a8c0@ACER2G> <46887663.6000404@mvps.org> Message-ID: <468879ED.6000902@mvps.org> > As far as I know, this is not possible. ... unless you mean like this: Dim DataMissing As String If Me.job_title <> "admin" Then If IsNull(Me.Issueing_agency) Then DataMissing = "Issuing Agency, " End If If IsNull(Me.Licenseexp) Then DataMissing = DataMissing & "Licence Exp, " End If If IsNull(Me.dotExpdate) Then DataMissing = DataMissing & "Dot Exp Date, " End If If Len(DataMissing) Then DataMissing = Left(DataMissing, Len(DataMissing) - 2) MsgBox "Data entry required in " & DataMissing & "." End If End If Maybe a more elegant way of coding this, but just throwing the idea in the ring. :-) Regards Steve From thewaddles at sbcglobal.net Mon Jul 2 00:18:32 2007 From: thewaddles at sbcglobal.net (Kevin Waddle) Date: Sun, 1 Jul 2007 22:18:32 -0700 Subject: [AccessD] Manipulate AC95 mdb files without converting Message-ID: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> Access Guru's, I have a client that uses a VB application that creates and uses an Access 95 mdb. He would like to add data directly to the mdb from Access 2002 or Excel. Is it possible, directly or through an add-in, to manipulate data in an Access 95 file? Thank you, Kevin 3 out of 4 Americans make up 75% of the population. From anitatiedemann at gmail.com Mon Jul 2 00:26:04 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Mon, 2 Jul 2007 15:26:04 +1000 Subject: [AccessD] Manipulate AC95 mdb files without converting In-Reply-To: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> References: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> Message-ID: Kevin You should be able to simply open the database with any later versions of Access and enter data directly into it. Anita Smith Australia > Access Guru's, > > I have a client that uses a VB application that creates and uses an Access > 95 mdb. > > He would like to add data directly to the mdb from Access 2002 or Excel. > > Is it possible, directly or through an add-in, to manipulate data in an > Access 95 file? > > Thank you, > Kevin > > > 3 out of 4 Americans make up 75% of the population. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From thewaddles at sbcglobal.net Mon Jul 2 01:17:43 2007 From: thewaddles at sbcglobal.net (Kevin Waddle) Date: Sun, 1 Jul 2007 23:17:43 -0700 Subject: [AccessD] Manipulate AC95 mdb files without converting In-Reply-To: References: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> Message-ID: <00ef01c7bc70$b3da5da0$6600a8c0@TheWaddles> Anita, I'm sorry I didn't make it clear what I am trying to do. But your suggestion pointed me in the right direction. I am trying to import data from an Excel file into the AC95 db. What I ended up doing is creating an Access Object within Excel and running a RunSQL command on each line in the Excel Sheet. Thank you, Kevin 355/113 - Not the famous number Pi, but a great simulation! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Sunday, July 01, 2007 10:26 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Manipulate AC95 mdb files without converting Kevin You should be able to simply open the database with any later versions of Access and enter data directly into it. Anita Smith Australia > Access Guru's, > > I have a client that uses a VB application that creates and uses an > Access > 95 mdb. > > He would like to add data directly to the mdb from Access 2002 or Excel. > > Is it possible, directly or through an add-in, to manipulate data in > an Access 95 file? > > Thank you, > Kevin > > > 3 out of 4 Americans make up 75% of the population. > > -- > 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 Mon Jul 2 02:47:34 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 2 Jul 2007 03:47:34 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <46887718.30704@mvps.org> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> <46887718.30704@mvps.org> Message-ID: <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> That could be it. I did name the combo after the field. On 7/1/07, Steve Schapel wrote: > > Hi Arthur, > > I just had a further thought about this... You need to use the name of > the combobox. If you have named the control different from the field it > is bound to, and if you are using the name of the field in your code, > you will have problems. > > Regards > Steve > From miscellany at mvps.org Mon Jul 2 02:53:10 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 02 Jul 2007 19:53:10 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> <46887718.30704@mvps.org> <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> Message-ID: <4688AEE6.7000200@mvps.org> Hmmm. Well, in that case, probably not. If the control and the field are both named the same as each other, then you can't get it wrong! :-) Regards Steve Arthur Fuller wrote: > That could be it. I did name the combo after the field. > From fuller.artful at gmail.com Mon Jul 2 05:04:31 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 2 Jul 2007 06:04:31 -0400 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <4688AEE6.7000200@mvps.org> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> <46887718.30704@mvps.org> <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> <4688AEE6.7000200@mvps.org> Message-ID: <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. Arthur On 7/2/07, Steve Schapel wrote: > > Hmmm. Well, in that case, probably not. If the control and the field > are both named the same as each other, then you can't get it wrong! :-) > > Regards > Steve > > From ewaldt at gdls.com Mon Jul 2 05:49:14 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Mon, 2 Jul 2007 06:49:14 -0400 Subject: [AccessD] The Business Side Of Databases In-Reply-To: Message-ID: Maybe VB. NYET. ;-) Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems (586) 825-4838 Message: 4 Date: Fri, 29 Jun 2007 13:15:48 -0400 From: "jwcolby" Subject: Re: [AccessD] The Business Side Of Databases To: "'Access Developers discussion and problem solving'" Message-ID: <20070629171552.A85F1BE98 at smtp-auth.no-ip.com> Content-Type: text/plain; charset="US-ASCII" That is exactly what I am looking for. Does it run VB.Net? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of ewaldt at gdls.com Sent: Friday, June 29, 2007 1:05 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] The Business Side Of Databases Hey, John, I just found my kids' old Timex Sinclair 1000. Would that be slow enough? :-) Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems Date: Thu, 28 Jun 2007 13:25:09 -0400 From: "jwcolby" Subject: Re: [AccessD] The Business Side Of Databases To: "'Access Developers discussion and problem solving'" Message-ID: <20070628172512.97DACBE52 at smtp-auth.no-ip.com> Content-Type: text/plain; charset="us-ascii" Well, I like the slower machine idea!!! Great minds think alike. In fact I am searching EBAY for some old Commodore 64 machines to make my servers. ;-) This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From JHewson at karta.com Mon Jul 2 07:59:11 2007 From: JHewson at karta.com (Jim Hewson) Date: Mon, 2 Jul 2007 07:59:11 -0500 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> References: <380-2200770114955828@M2W008.mail2web.com><29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com><4688103C.7040209@mvps.org><29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com><46887718.30704@mvps.org><29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com><4688AEE6.7000200@mvps.org> <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> Message-ID: <6C1791BC61725F44A28C24208026A511126B67@karta-exc-int.Karta.com> Arthur, I too am getting to the stage in life where change is more trouble than it's worth. However, I have had several cases where if I renamed the control by appending the name the errors and problems have disappeared. Most significant in using the domain functions. Jim jhewson at karta.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 02, 2007 5:05 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. Arthur On 7/2/07, Steve Schapel wrote: > > Hmmm. Well, in that case, probably not. If the control and the field > are both named the same as each other, then you can't get it wrong! :-) > > Regards > Steve > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bheygood at abestsystems.com Mon Jul 2 08:29:29 2007 From: bheygood at abestsystems.com (Bob Heygood) Date: Mon, 2 Jul 2007 06:29:29 -0700 Subject: [AccessD] Open Protected Excel via VBA In-Reply-To: References: Message-ID: <002301c7bcad$0471cf00$6401a8c0@speedy> Good Morning to the list, Could someone provide me with a least a jump start on some code to open some sheets in excel that have been protected with a password? I have the password. Best, Bob Heygood From Jim.Hale at FleetPride.com Mon Jul 2 08:43:24 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Mon, 2 Jul 2007 08:43:24 -0500 Subject: [AccessD] Open Protected Excel via VBA In-Reply-To: <002301c7bcad$0471cf00$6401a8c0@speedy> References: <002301c7bcad$0471cf00$6401a8c0@speedy> Message-ID: I think this may be the syntax you are looking for. appExcel.Sheets("instruc").Unprotect Password:=strPW HTH Jim hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bob Heygood Sent: Monday, July 02, 2007 8:29 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Open Protected Excel via VBA Good Morning to the list, Could someone provide me with a least a jump start on some code to open some sheets in excel that have been protected with a password? I have the password. Best, Bob Heygood -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From Jim.Hale at FleetPride.com Mon Jul 2 09:02:20 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Mon, 2 Jul 2007 09:02:20 -0500 Subject: [AccessD] Open Protected Excel via VBA In-Reply-To: References: <002301c7bcad$0471cf00$6401a8c0@speedy> Message-ID: If you meant protected sheets within a workbook, appExcel.Sheets("instruc").Unprotect Password:=strPW Works. If you meant to unprotect a Workbook try the following code snippets: appexcel.Workbooks.Open strPath1 & "\" & strFilename, 0 appexcel.ActiveWorkbook.Unprotect Password:=strPW Jim Hale *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From markamatte at hotmail.com Mon Jul 2 10:50:41 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Mon, 02 Jul 2007 15:50:41 +0000 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) In-Reply-To: <29f585dd0707011007s2bb4f993s9e9b8638acf37813@mail.gmail.com> Message-ID: Joe, I have a db that allows multiple people can add notes. No One can edit old notes. Each note has a DT stamp,User_ID, and note type. The notes are added via an unbound box. If I wanted to impliment what you described...I would probably add a field to my notes table...and along with DTS and USER...I would add a User_Type to the notes. Dispatchers =D Field supervisor =F manager =M executive notes=E Each time a note is created the User_Type would be populated with one of the above depending on the users level of access. One the form/subform displaying the notes...I would change the data source via VBA(depending on user), the 'where' clause specifically. If a dispatcher is logged in..."where User_Type ='D'"...since Dispatchers cannot add notes...none would be returned. See below: EXAMPLE WHERE CLAUSES Dispatchers =where User_Type ='D' Field supervisor =where User_Type ='D' or User_Type ='F' manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' or User_Type='E' Just a thought... Good Luck, Mark A. Matte >From: "Arthur Fuller" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Never Take a job for a friend (Three level >designquestion) >Date: Sun, 1 Jul 2007 13:07:49 -0400 > >Minor addendum, perhaps obvious. If a dispatcher is looking, hide the >Notes, >period. > >Arthur > > >On 7/1/07, Arthur Fuller wrote: > > > > I think that some of the respondents so far kind of missed your > > requirements, Joe (or perhaps the beer I'm enjoying for Canada has had >more > > effect than I anticipated). > > > > You actually have only 3 meaningful user levels, since dispatchers are > > powerless. The other three make a grid like this: > > > > Sup Mgr Exec > > Sup W X X > > Mgr R W X > > Exec R R W > > > > Where R means Read, W means Write, and X means neither. If the user >table > > contained a 3-char column with each horizontal combination written as a > > string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine the > > current row's notes field and act accordingly. > > > > This demands of course that the Notes rows be tagged with UserLevel >column > > (S, M or E). > > > > If a Sup is looking and the current Notes.UserLevel column contains M or > > E, hide the Notes. > > If a Mgr is looking and the current Notes UserLevel contains S, then > > Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. > > If an Exec is looking, and the current Notes UserLevl contains S or M, > > Notes.enabled = False, else Notes.Enabled = True. > > > > I think that covers it. > > > > hth, > > Arthur > > > > > > This problem will be much easier to deal with if the notes are presented > > in single-form fashion rather than datasheet. That said, > > > > > > On 6/30/07, Joe Hecht wrote: > > > > > > It is simple. Ya Right > > > > > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > > Dispatchers can not do notes, can not see notes. Field supervisor can > > > write > > > notes. Can not see manager or executive notes. Managers can write > > > notes, > > > can read Field supervisor notes, not edit them or see executive notes. > > > Executives can write theirs, see but not edit all other notes. > > > > > > > > > > > > Notes are many notes to one employee. > > > > > > > > > > > > How do I do notes so people see them in chronological order? If I do > > > three > > > sub tables how would I get all notes to same point. One employee can > > > have > > > multiple incidents good and bad in their record. How would I get all > > > three > > > levels of notes to same incident? > > > > > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > > > > > > > > > Joe Hecht > > > > > > jmhecht at earthlink.net > > > > > > > > > > > > -- > > > 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 _________________________________________________________________ Don?t miss your chance to WIN $10,000 and other great prizes from Microsoft Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ From cfoust at infostatsystems.com Mon Jul 2 12:03:46 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 2 Jul 2007 10:03:46 -0700 Subject: [AccessD] Never Take a job for a friend (Three leveldesignquestion) In-Reply-To: References: <29f585dd0707011007s2bb4f993s9e9b8638acf37813@mail.gmail.com> Message-ID: Is there some reason NOT to use Access security for this? It still works in 2003 format. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Monday, July 02, 2007 8:51 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Joe, I have a db that allows multiple people can add notes. No One can edit old notes. Each note has a DT stamp,User_ID, and note type. The notes are added via an unbound box. If I wanted to impliment what you described...I would probably add a field to my notes table...and along with DTS and USER...I would add a User_Type to the notes. Dispatchers =D Field supervisor =F manager =M executive notes=E Each time a note is created the User_Type would be populated with one of the above depending on the users level of access. One the form/subform displaying the notes...I would change the data source via VBA(depending on user), the 'where' clause specifically. If a dispatcher is logged in..."where User_Type ='D'"...since Dispatchers cannot add notes...none would be returned. See below: EXAMPLE WHERE CLAUSES Dispatchers =where User_Type ='D' Field supervisor =where User_Type ='D' or User_Type ='F' manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' or User_Type='E' Just a thought... Good Luck, Mark A. Matte >From: "Arthur Fuller" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Never Take a job for a friend (Three level >designquestion) >Date: Sun, 1 Jul 2007 13:07:49 -0400 > >Minor addendum, perhaps obvious. If a dispatcher is looking, hide the >Notes, period. > >Arthur > > >On 7/1/07, Arthur Fuller wrote: > > > > I think that some of the respondents so far kind of missed your > > requirements, Joe (or perhaps the beer I'm enjoying for Canada has > > had >more > > effect than I anticipated). > > > > You actually have only 3 meaningful user levels, since dispatchers > > are powerless. The other three make a grid like this: > > > > Sup Mgr Exec > > Sup W X X > > Mgr R W X > > Exec R R W > > > > Where R means Read, W means Write, and X means neither. If the user >table > > contained a 3-char column with each horizontal combination written > > as a string (i.e. WXX, RWX and RRW) then the OnCurrent event can > > examine the current row's notes field and act accordingly. > > > > This demands of course that the Notes rows be tagged with UserLevel >column > > (S, M or E). > > > > If a Sup is looking and the current Notes.UserLevel column contains > > M or E, hide the Notes. > > If a Mgr is looking and the current Notes UserLevel contains S, then > > Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. > > If an Exec is looking, and the current Notes UserLevl contains S or > > M, Notes.enabled = False, else Notes.Enabled = True. > > > > I think that covers it. > > > > hth, > > Arthur > > > > > > This problem will be much easier to deal with if the notes are > > presented in single-form fashion rather than datasheet. That said, > > > > > > On 6/30/07, Joe Hecht wrote: > > > > > > It is simple. Ya Right > > > > > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > > Dispatchers can not do notes, can not see notes. Field supervisor > > > can write notes. Can not see manager or executive notes. Managers > > > can write notes, can read Field supervisor notes, not edit them or > > > see executive notes. > > > Executives can write theirs, see but not edit all other notes. > > > > > > > > > > > > Notes are many notes to one employee. > > > > > > > > > > > > How do I do notes so people see them in chronological order? If I > > > do three sub tables how would I get all notes to same point. One > > > employee can have multiple incidents good and bad in their record. > > > How would I get all three levels of notes to same incident? > > > > > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > > > > > > > > > Joe Hecht > > > > > > jmhecht at earthlink.net > > > > > > > > > > > > -- > > > 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 _________________________________________________________________ Don't miss your chance to WIN $10,000 and other great prizes from Microsoft Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ From adtejpal at gmail.com Mon Jul 2 12:58:38 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Mon, 2 Jul 2007 23:28:38 +0530 Subject: [AccessD] Open a combobox on entering it References: <380-2200770114955828@M2W008.mail2web.com><29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com><4688103C.7040209@mvps.org><29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com><46887718.30704@mvps.org><29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com><4688AEE6.7000200@mvps.org> <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> Message-ID: <00e801c7bcd2$f6b4da30$7757a27a@pcadt> Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Arthur Fuller To: Access Developers discussion and problem solving Sent: Monday, July 02, 2007 15:34 Subject: Re: [AccessD] Open a combobox on entering it I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. Arthur From cfoust at infostatsystems.com Mon Jul 2 13:06:43 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 2 Jul 2007 11:06:43 -0700 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <00e801c7bcd2$f6b4da30$7757a27a@pcadt> References: <380-2200770114955828@M2W008.mail2web.com><29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com><4688103C.7040209@mvps.org><29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com><46887718.30704@mvps.org><29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com><4688AEE6.7000200@mvps.org><29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> <00e801c7bcd2$f6b4da30$7757a27a@pcadt> Message-ID: I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Arthur Fuller To: Access Developers discussion and problem solving Sent: Monday, July 02, 2007 15:34 Subject: Re: [AccessD] Open a combobox on entering it I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Mon Jul 2 13:58:58 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Mon, 02 Jul 2007 11:58:58 -0700 Subject: [AccessD] Open a combobox on entering it In-Reply-To: Message-ID: <0JKK0069ZF6PEP20@l-daemon> Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 02, 2007 11:07 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Arthur Fuller To: Access Developers discussion and problem solving Sent: Monday, July 02, 2007 15:34 Subject: Re: [AccessD] Open a combobox on entering it I know that lots of people here despise that style, but I've been naming controls the same as their data source for about 15 years and this dog is too old for new tricks. In a few months I'll be 60. Of course, I'm too poor to choose retirement at 60. I'm learning Java currently, but it's not really a new trick :-) There must be something else going on here. I just whipped up a tester in Access 2000 and the dropdown attribute is available in the OnEnter event. I repeated it in 2003 and it worked. I repeated it in 2003 against a SQL database and it worked. So there must be something odd about the database I was working on when the problem arose. My testers created one combo using a value list and another using a table. So I have no idea why I wasn't able to get it before. 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 miscellany at mvps.org Mon Jul 2 14:15:33 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 03 Jul 2007 07:15:33 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <00e801c7bcd2$f6b4da30$7757a27a@pcadt> References: <380-2200770114955828@M2W008.mail2web.com> <29f585dd0707010810i78036286y582ed34679f88ea8@mail.gmail.com> <4688103C.7040209@mvps.org> <29f585dd0707011435l501db249j5f6dc860b575699b@mail.gmail.com> <46887718.30704@mvps.org> <29f585dd0707020047j6ec95435kb30219923b18a4a3@mail.gmail.com> <4688AEE6.7000200@mvps.org> <29f585dd0707020304rcb810e4hcd0225f75241c52d@mail.gmail.com> <00e801c7bcd2$f6b4da30$7757a27a@pcadt> Message-ID: <46894ED5.3080903@mvps.org> I agree 100% with your assertions here, A.D. For myself, I *always* adopt the naming convention of using the same name for a bound control as the name of the field it is bound to. And of course, I always ensure that an unbound or calculated control is *not* named the same as a field in the object's record source. I know of no reason why this practice could cause a problem. Regards Steve A.D.TEJPAL wrote: > Naming of Bound Controls On Forms / Reports > (Visa Vis Record Source) > ================================== > > Arthur, > > You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. > > There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: > > ==================================== > 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. > 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. > ==================================== > > If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. > > What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. > > On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. > > Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. > From adtejpal at gmail.com Mon Jul 2 13:30:12 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Tue, 3 Jul 2007 00:00:12 +0530 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> Message-ID: <001101c7bcdf$1eb25100$b057a27a@pcadt> Joe, It might be desirable to enforce ChainOfCommand discipline as well. For example One chief executive can have more than one managers. Each of these managers has more than one supervisors. Each supervisor in turn has more than one employees under his control. Manager A can see all the notes recorded by supervisors for employees under his command only. Similarly only those in the chain of command for a particular employee can record notes for that employee. For this, recursive joins would be necessary. Would you like a solution to be explored on these lines ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Sunday, July 01, 2007 04:38 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net From jmhecht at earthlink.net Mon Jul 2 14:56:53 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Mon, 2 Jul 2007 12:56:53 -0700 (GMT-07:00) Subject: [AccessD] Never Take a job for a friend (Three level designquestion) Message-ID: <18346248.1183406213937.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> AD, Thanks. It is a small company and each level can deal with any one below them. If you have time I can use help writing the notes code. I can send you the DB when I get home tonight. Los Angeles time. -----Original Message----- >From: "A.D.TEJPAL" >Sent: Jul 2, 2007 11:30 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Never Take a job for a friend (Three level designquestion) > >Joe, > > It might be desirable to enforce ChainOfCommand discipline as well. For example One chief executive can have more than one managers. Each of these managers has more than one supervisors. Each supervisor in turn has more than one employees under his control. > > Manager A can see all the notes recorded by supervisors for employees under his command only. Similarly only those in the chain of command for a particular employee can record notes for that employee. > > For this, recursive joins would be necessary. Would you like a solution to be explored on these lines ? > >Best wishes, >A.D.Tejpal >--------------- > > ----- Original Message ----- > From: Joe Hecht > To: 'Access Developers discussion and problem solving' > Sent: Sunday, July 01, 2007 04:38 > Subject: [AccessD] Never Take a job for a friend (Three level designquestion) > > > It is simple. Ya Right > > I am righting a poor mans HR program. There are four user levels. > > Dispatchers can not do notes, can not see notes. > > Field supervisor can write notes. Can not see manager or executive notes. > > Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. > > Executives can write theirs, see but not edit all other notes. > > Notes are many notes to one employee. > > How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? > > Ya all know where I am spending my sat night. > > Joe Hecht > jmhecht at earthlink.net >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From jmhecht at earthlink.net Mon Jul 2 14:59:55 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Mon, 2 Jul 2007 12:59:55 -0700 (GMT-07:00) Subject: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Message-ID: <8414823.1183406395897.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Greetings oh mighty queen of the shy ones. : ) I will see the network instalation and have a better idea after next Monday or Tuesday night. Joe -----Original Message----- >From: Charlotte Foust >Sent: Jul 2, 2007 10:03 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) > >Is there some reason NOT to use Access security for this? It still >works in 2003 format. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Monday, July 02, 2007 8:51 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Never Take a job for a friend (Three >leveldesignquestion) > >Joe, > >I have a db that allows multiple people can add notes. No One can edit >old notes. Each note has a DT stamp,User_ID, and note type. The notes >are added via an unbound box. > >If I wanted to impliment what you described...I would probably add a >field to my notes table...and along with DTS and USER...I would add a >User_Type to the notes. > >Dispatchers =D >Field supervisor =F >manager =M >executive notes=E > >Each time a note is created the User_Type would be populated with one of >the above depending on the users level of access. > >One the form/subform displaying the notes...I would change the data >source via VBA(depending on user), the 'where' clause specifically. If >a dispatcher is logged in..."where User_Type ='D'"...since Dispatchers >cannot add notes...none would be returned. See below: > >EXAMPLE WHERE CLAUSES >Dispatchers =where User_Type ='D' >Field supervisor =where User_Type ='D' or User_Type ='F' >manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' >executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' >or User_Type='E' > >Just a thought... > >Good Luck, > >Mark A. Matte > >>From: "Arthur Fuller" >>Reply-To: Access Developers discussion and problem >>solving >>To: "Access Developers discussion and problem >>solving" >>Subject: Re: [AccessD] Never Take a job for a friend (Three level >>designquestion) >>Date: Sun, 1 Jul 2007 13:07:49 -0400 >> >>Minor addendum, perhaps obvious. If a dispatcher is looking, hide the >>Notes, period. >> >>Arthur >> >> >>On 7/1/07, Arthur Fuller wrote: >> > >> > I think that some of the respondents so far kind of missed your >> > requirements, Joe (or perhaps the beer I'm enjoying for Canada has >> > had >>more >> > effect than I anticipated). >> > >> > You actually have only 3 meaningful user levels, since dispatchers >> > are powerless. The other three make a grid like this: >> > >> > Sup Mgr Exec >> > Sup W X X >> > Mgr R W X >> > Exec R R W >> > >> > Where R means Read, W means Write, and X means neither. If the user >>table >> > contained a 3-char column with each horizontal combination written >> > as a string (i.e. WXX, RWX and RRW) then the OnCurrent event can >> > examine the current row's notes field and act accordingly. >> > >> > This demands of course that the Notes rows be tagged with UserLevel >>column >> > (S, M or E). >> > >> > If a Sup is looking and the current Notes.UserLevel column contains >> > M or E, hide the Notes. >> > If a Mgr is looking and the current Notes UserLevel contains S, then > >> > Notes.enabled = False; if the Notes UserLevel is E, then hide the >Note. >> > If an Exec is looking, and the current Notes UserLevl contains S or >> > M, Notes.enabled = False, else Notes.Enabled = True. >> > >> > I think that covers it. >> > >> > hth, >> > Arthur >> > >> > >> > This problem will be much easier to deal with if the notes are >> > presented in single-form fashion rather than datasheet. That said, >> > >> > >> > On 6/30/07, Joe Hecht wrote: >> > > >> > > It is simple. Ya Right >> > > >> > > >> > > >> > > I am righting a poor mans HR program. There are four user levels. >> > > Dispatchers can not do notes, can not see notes. Field supervisor >> > > can write notes. Can not see manager or executive notes. Managers > >> > > can write notes, can read Field supervisor notes, not edit them or > >> > > see executive notes. >> > > Executives can write theirs, see but not edit all other notes. >> > > >> > > >> > > >> > > Notes are many notes to one employee. >> > > >> > > >> > > >> > > How do I do notes so people see them in chronological order? If I >> > > do three sub tables how would I get all notes to same point. One >> > > employee can have multiple incidents good and bad in their record. > >> > > How would I get all three levels of notes to same incident? >> > > >> > > >> > > >> > > Ya all know where I am spending my sat night. >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > Joe Hecht >> > > >> > > jmhecht at earthlink.net >> > > >> > > >> > > >> > > -- >> > > 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 > >_________________________________________________________________ >Don't miss your chance to WIN $10,000 and other great prizes from >Microsoft Office Live >http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From jmhecht at earthlink.net Mon Jul 2 21:03:07 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Mon, 2 Jul 2007 19:03:07 -0700 Subject: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Looking for AD In-Reply-To: <001101c7bcdf$1eb25100$b057a27a@pcadt> References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> <001101c7bcdf$1eb25100$b057a27a@pcadt> Message-ID: <003701c7bd16$4d18ce70$6701a8c0@ACER2G> Hi AD, It is 7:00 Pacific. Are you on line? Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 11:30 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Joe, It might be desirable to enforce ChainOfCommand discipline as well. For example One chief executive can have more than one managers. Each of these managers has more than one supervisors. Each supervisor in turn has more than one employees under his control. Manager A can see all the notes recorded by supervisors for employees under his command only. Similarly only those in the chain of command for a particular employee can record notes for that employee. For this, recursive joins would be necessary. Would you like a solution to be explored on these lines ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Sunday, July 01, 2007 04:38 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jmhecht at earthlink.net Mon Jul 2 21:09:17 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Mon, 2 Jul 2007 19:09:17 -0700 Subject: [AccessD] Never Take a job for a friend (Three leveldesignquestion) In-Reply-To: References: <29f585dd0707011007s2bb4f993s9e9b8638acf37813@mail.gmail.com> Message-ID: <003d01c7bd17$2c9861f0$6701a8c0@ACER2G> Mark, I may want to steal ( I mean borrow )after I see the network setup next week. Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Monday, July 02, 2007 8:51 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Joe, I have a db that allows multiple people can add notes. No One can edit old notes. Each note has a DT stamp,User_ID, and note type. The notes are added via an unbound box. If I wanted to impliment what you described...I would probably add a field to my notes table...and along with DTS and USER...I would add a User_Type to the notes. Dispatchers =D Field supervisor =F manager =M executive notes=E Each time a note is created the User_Type would be populated with one of the above depending on the users level of access. One the form/subform displaying the notes...I would change the data source via VBA(depending on user), the 'where' clause specifically. If a dispatcher is logged in..."where User_Type ='D'"...since Dispatchers cannot add notes...none would be returned. See below: EXAMPLE WHERE CLAUSES Dispatchers =where User_Type ='D' Field supervisor =where User_Type ='D' or User_Type ='F' manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' or User_Type='E' Just a thought... Good Luck, Mark A. Matte >From: "Arthur Fuller" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Never Take a job for a friend (Three level >designquestion) >Date: Sun, 1 Jul 2007 13:07:49 -0400 > >Minor addendum, perhaps obvious. If a dispatcher is looking, hide the >Notes, >period. > >Arthur > > >On 7/1/07, Arthur Fuller wrote: > > > > I think that some of the respondents so far kind of missed your > > requirements, Joe (or perhaps the beer I'm enjoying for Canada has had >more > > effect than I anticipated). > > > > You actually have only 3 meaningful user levels, since dispatchers are > > powerless. The other three make a grid like this: > > > > Sup Mgr Exec > > Sup W X X > > Mgr R W X > > Exec R R W > > > > Where R means Read, W means Write, and X means neither. If the user >table > > contained a 3-char column with each horizontal combination written as a > > string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine the > > current row's notes field and act accordingly. > > > > This demands of course that the Notes rows be tagged with UserLevel >column > > (S, M or E). > > > > If a Sup is looking and the current Notes.UserLevel column contains M or > > E, hide the Notes. > > If a Mgr is looking and the current Notes UserLevel contains S, then > > Notes.enabled = False; if the Notes UserLevel is E, then hide the Note. > > If an Exec is looking, and the current Notes UserLevl contains S or M, > > Notes.enabled = False, else Notes.Enabled = True. > > > > I think that covers it. > > > > hth, > > Arthur > > > > > > This problem will be much easier to deal with if the notes are presented > > in single-form fashion rather than datasheet. That said, > > > > > > On 6/30/07, Joe Hecht wrote: > > > > > > It is simple. Ya Right > > > > > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > > Dispatchers can not do notes, can not see notes. Field supervisor can > > > write > > > notes. Can not see manager or executive notes. Managers can write > > > notes, > > > can read Field supervisor notes, not edit them or see executive notes. > > > Executives can write theirs, see but not edit all other notes. > > > > > > > > > > > > Notes are many notes to one employee. > > > > > > > > > > > > How do I do notes so people see them in chronological order? If I do > > > three > > > sub tables how would I get all notes to same point. One employee can > > > have > > > multiple incidents good and bad in their record. How would I get all > > > three > > > levels of notes to same incident? > > > > > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > > > > > > > > > Joe Hecht > > > > > > jmhecht at earthlink.net > > > > > > > > > > > > -- > > > 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 _________________________________________________________________ Dont miss your chance to WIN $10,000 and other great prizes from Microsoft Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ From adtejpal at gmail.com Mon Jul 2 22:57:10 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Tue, 3 Jul 2007 09:27:10 +0530 Subject: [AccessD] Never Take a job for a friend (Threeleveldesignquestion) Looking for AD References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G><001101c7bcdf$1eb25100$b057a27a@pcadt> <003701c7bd16$4d18ce70$6701a8c0@ACER2G> Message-ID: <006001c7bd26$52fbf780$f157a27a@pcadt> Yes Joe ! I am now on line (it is 09-15 Hrs Indian Standard Time). I shall try to put together a sample db, meeting all your requirements. However, in order to make it generic and suitable for larger organizations, the additional feature of ChainOfCommand integrity would also be included. Best wishes, A.D.Tejpal adtejpal at gmail.com ------------------------- ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 07:33 Subject: Re: [AccessD] Never Take a job for a friend (Threeleveldesignquestion) Looking for AD Hi AD, It is 7:00 Pacific. Are you on line? Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 11:30 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Never Take a job for a friend (Three leveldesignquestion) Joe, It might be desirable to enforce ChainOfCommand discipline as well. For example One chief executive can have more than one managers. Each of these managers has more than one supervisors. Each supervisor in turn has more than one employees under his control. Manager A can see all the notes recorded by supervisors for employees under his command only. Similarly only those in the chain of command for a particular employee can record notes for that employee. For this, recursive joins would be necessary. Would you like a solution to be explored on these lines ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Sunday, July 01, 2007 04:38 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net From adtejpal at gmail.com Mon Jul 2 23:46:04 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Tue, 3 Jul 2007 10:16:04 +0530 Subject: [AccessD] Open a combobox on entering it References: <0JKK0069ZF6PEP20@l-daemon> Message-ID: <01d001c7bd2d$46d2b320$f157a27a@pcadt> Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 02, 2007 11:07 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- << SNIPPED >> From accessd at shaw.ca Tue Jul 3 07:08:38 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 03 Jul 2007 05:08:38 -0700 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <01d001c7bd2d$46d2b320$f157a27a@pcadt> Message-ID: <0JKL003TOQUQCO93@l-daemon> Hi A.D. Tejpal: If you would like I could give you a copy of the application before I played around with it. The application was giving the strangest errors. In one example: a combo box would not take the assignment of an initial value but there were no error messages generated... and the issue was not consistent... sometimes it would work fine... but when the combo box name was changed this problem was gone with no other modifications. I have read some warning about this effect, a number of years ago, the article discussed 'Context and Naming-Conventions' but I can not find any reference to the white-paper. Maybe someone else can remember? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 9:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 02, 2007 11:07 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- << SNIPPED >> -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From adtejpal at gmail.com Tue Jul 3 08:56:35 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Tue, 3 Jul 2007 19:26:35 +0530 Subject: [AccessD] Open a combobox on entering it References: <0JKL003TOQUQCO93@l-daemon> Message-ID: <003501c7bd7a$248145a0$1a58a27a@pcadt> Jim, I would be glad to have a look at it. It would be nice if you could kindly send it to me after removing passwords if any. For ready reference, names of forms / reports that have been giving problems, may please be mentioned, along with the typical steps needed to re-create the adverse behavior. I trust the file is in non-2007 format. Best wishes, A.D.Tejpal adtejpal at gmail.com ------------------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 17:38 Subject: Re: [AccessD] Open a combobox on entering it Hi A.D. Tejpal: If you would like I could give you a copy of the application before I played around with it. The application was giving the strangest errors. In one example: a combo box would not take the assignment of an initial value but there were no error messages generated... and the issue was not consistent... sometimes it would work fine... but when the combo box name was changed this problem was gone with no other modifications. I have read some warning about this effect, a number of years ago, the article discussed 'Context and Naming-Conventions' but I can not find any reference to the white-paper. Maybe someone else can remember? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 9:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 02, 2007 11:07 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it I don't have concrete evidence at hand, A. D., but I have run into problems with code references to a control with the same name as the underlying field because controls have different methods and properties available that fields do. I would suspect that there is also a penalty to pay for making the Access app figure out which one you're addressing rather than spelling it out by using different names. I'm not working much in Access anymore, so it will take me time to track down actual examples. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 10:59 AM To: Access Developers discussion and problem solving Cc: adtp at airtelbroadband.in Subject: Re: [AccessD] Open a combobox on entering it Naming of Bound Controls On Forms / Reports (Visa Vis Record Source) ================================== Arthur, You need not feel apprehensive about your style of letting the name of pure bound controls remain the same as that of pertinent field in the record source. There is no evidence that naming a pure bound control same as its control source leads to any problem. Following postulation appears to hold good: ==================================== 1 - An unbound or calculated control should not have its name identical to any of the fields contained in the record source. 2 - At the same time, it is perfectly Ok if the name of a pure bound control is the same as its control source, which of course is one of the fields in the record source. ==================================== If any members of the forum would like to disagree, the reason may kindly be posted along with concrete evidence supporting it. It might be desirable to clear the picture for a large number of access users, who might feel somewhat over-whelmed by the universal assertion that no control should carry the same name as that of a field in the record source. What needs to be emphasized is that on a report or bound form, naming of calculated or unbound controls the same as the name of a field in the record source, could be a recipe for disaster, virtually equivalent to creation of imposter controls and should never be done. On the other hand, it should be perfectly all right to name pure bound controls the same as the record source field that serves as control source. In fact it could be the preferred practice, distinguishing such controls from others, which should carry a prefix like Txt or Cbo etc. Unfortunately, quite often, advice given in access forums makes a flat recommendation against naming of controls same as field names, without explicitly clarifying that the precaution is applicable to other than pure bound controls. Best wishes, A.D.Tejpal --------------- << SNIPPED >> From markamatte at hotmail.com Tue Jul 3 09:28:04 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 03 Jul 2007 14:28:04 +0000 Subject: [AccessD] Never Take a job for a friend (Threeleveldesignquestion) In-Reply-To: <003d01c7bd17$2c9861f0$6701a8c0@ACER2G> Message-ID: No Prob...Just let me know. >From: "Joe Hecht" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Never Take a job for a friend >(Threeleveldesignquestion) >Date: Mon, 2 Jul 2007 19:09:17 -0700 > >Mark, > >I may want to steal ( I mean borrow )after I see the network setup next >week. > >Joe Hecht >jmhecht at earthlink.net > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Monday, July 02, 2007 8:51 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Never Take a job for a friend (Three >leveldesignquestion) > >Joe, > >I have a db that allows multiple people can add notes. No One can edit old >notes. Each note has a DT stamp,User_ID, and note type. The notes are >added via an unbound box. > >If I wanted to impliment what you described...I would probably add a field >to my notes table...and along with DTS and USER...I would add a User_Type >to > >the notes. > >Dispatchers =D >Field supervisor =F >manager =M >executive notes=E > >Each time a note is created the User_Type would be populated with one of >the > >above depending on the users level of access. > >One the form/subform displaying the notes...I would change the data source >via VBA(depending on user), the 'where' clause specifically. If a >dispatcher is logged in..."where User_Type ='D'"...since Dispatchers cannot >add notes...none would be returned. See below: > >EXAMPLE WHERE CLAUSES >Dispatchers =where User_Type ='D' >Field supervisor =where User_Type ='D' or User_Type ='F' >manager =where User_Type ='D' or User_Type ='F' or User_Type ='M' >executive notes=where User_Type ='D' or User_Type ='F' or User_Type ='M' or >User_Type='E' > >Just a thought... > >Good Luck, > >Mark A. Matte > > >From: "Arthur Fuller" > >Reply-To: Access Developers discussion and problem > >solving > >To: "Access Developers discussion and problem > >solving" > >Subject: Re: [AccessD] Never Take a job for a friend (Three level > >designquestion) > >Date: Sun, 1 Jul 2007 13:07:49 -0400 > > > >Minor addendum, perhaps obvious. If a dispatcher is looking, hide the > >Notes, > >period. > > > >Arthur > > > > > >On 7/1/07, Arthur Fuller wrote: > > > > > > I think that some of the respondents so far kind of missed your > > > requirements, Joe (or perhaps the beer I'm enjoying for Canada has had > >more > > > effect than I anticipated). > > > > > > You actually have only 3 meaningful user levels, since dispatchers are > > > powerless. The other three make a grid like this: > > > > > > Sup Mgr Exec > > > Sup W X X > > > Mgr R W X > > > Exec R R W > > > > > > Where R means Read, W means Write, and X means neither. If the user > >table > > > contained a 3-char column with each horizontal combination written as >a > > > string (i.e. WXX, RWX and RRW) then the OnCurrent event can examine >the > > > current row's notes field and act accordingly. > > > > > > This demands of course that the Notes rows be tagged with UserLevel > >column > > > (S, M or E). > > > > > > If a Sup is looking and the current Notes.UserLevel column contains M >or > > > E, hide the Notes. > > > If a Mgr is looking and the current Notes UserLevel contains S, then > > > Notes.enabled = False; if the Notes UserLevel is E, then hide the >Note. > > > If an Exec is looking, and the current Notes UserLevl contains S or M, > > > Notes.enabled = False, else Notes.Enabled = True. > > > > > > I think that covers it. > > > > > > hth, > > > Arthur > > > > > > > > > This problem will be much easier to deal with if the notes are >presented > > > in single-form fashion rather than datasheet. That said, > > > > > > > > > On 6/30/07, Joe Hecht wrote: > > > > > > > > It is simple. Ya Right > > > > > > > > > > > > > > > > I am righting a poor mans HR program. There are four user levels. > > > > Dispatchers can not do notes, can not see notes. Field supervisor >can > > > > write > > > > notes. Can not see manager or executive notes. Managers can write > > > > notes, > > > > can read Field supervisor notes, not edit them or see executive >notes. > > > > Executives can write theirs, see but not edit all other notes. > > > > > > > > > > > > > > > > Notes are many notes to one employee. > > > > > > > > > > > > > > > > How do I do notes so people see them in chronological order? If I do > > > > three > > > > sub tables how would I get all notes to same point. One employee can > > > > have > > > > multiple incidents good and bad in their record. How would I get all > > > > three > > > > levels of notes to same incident? > > > > > > > > > > > > > > > > Ya all know where I am spending my sat night. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Joe Hecht > > > > > > > > jmhecht at earthlink.net > > > > > > > > > > > > > > > > -- > > > > 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 > >_________________________________________________________________ >Dont miss your chance to WIN $10,000 and other great prizes from Microsoft >Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/ > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://liveearth.msn.com From robert at webedb.com Tue Jul 3 09:38:28 2007 From: robert at webedb.com (Robert L. Stewart) Date: Tue, 03 Jul 2007 09:38:28 -0500 Subject: [AccessD] Never Take a job for a friend In-Reply-To: References: Message-ID: <200707031444.l63EiR5I004467@databaseadvisors.com> Since it is for a "friend," I would say absolutely do not use security. Personally, I would not want to get sucked into having to maintain it. Robert At 09:28 AM 7/3/2007, you wrote: >Date: Mon, 2 Jul 2007 10:03:46 -0700 >From: "Charlotte Foust" >Subject: Re: [AccessD] Never Take a job for a friend (Three > leveldesignquestion) >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >Is there some reason NOT to use Access security for this? It still >works in 2003 format. > >Charlotte Foust From cfoust at infostatsystems.com Tue Jul 3 10:20:17 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 3 Jul 2007 08:20:17 -0700 Subject: [AccessD] Never Take a job for a friend In-Reply-To: <200707031444.l63EiR5I004467@databaseadvisors.com> References: <200707031444.l63EiR5I004467@databaseadvisors.com> Message-ID: It needn't be that draconian, and security isn't all that hard. How could it be any harder than keeping track of who is supposed to have which permissions entirely through code? It would save a lot of work for Joe if there were simply 3, or however many, user groups with specific permissions. Then a simple login to the application would handle the details. You could even just create logins for each group and not go any further into personal logins. People being what they are, sooner or later someone would find out the other logins and try them "for fun", of course. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Tuesday, July 03, 2007 7:38 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Never Take a job for a friend Since it is for a "friend," I would say absolutely do not use security. Personally, I would not want to get sucked into having to maintain it. Robert At 09:28 AM 7/3/2007, you wrote: >Date: Mon, 2 Jul 2007 10:03:46 -0700 >From: "Charlotte Foust" >Subject: Re: [AccessD] Never Take a job for a friend (Three > leveldesignquestion) >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >Is there some reason NOT to use Access security for this? It still >works in 2003 format. > >Charlotte Foust -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Tue Jul 3 11:20:54 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 03 Jul 2007 16:20:54 +0000 Subject: [AccessD] Never Take a job for a friend In-Reply-To: Message-ID: Lately I've been using API calls to get the username they are logged on to the computer with...then have a table listing potential users and their level of access. Just remember to leave someone access to update this table. Mark >From: "Charlotte Foust" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Never Take a job for a friend >Date: Tue, 3 Jul 2007 08:20:17 -0700 > >It needn't be that draconian, and security isn't all that hard. How >could it be any harder than keeping track of who is supposed to have >which permissions entirely through code? > >It would save a lot of work for Joe if there were simply 3, or however >many, user groups with specific permissions. Then a simple login to the >application would handle the details. You could even just create logins >for each group and not go any further into personal logins. People >being what they are, sooner or later someone would find out the other >logins and try them "for fun", of course. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. >Stewart >Sent: Tuesday, July 03, 2007 7:38 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Never Take a job for a friend > >Since it is for a "friend," I would say >absolutely do not use security. Personally, I would not want to get >sucked into having to maintain it. > >Robert > >At 09:28 AM 7/3/2007, you wrote: > >Date: Mon, 2 Jul 2007 10:03:46 -0700 > >From: "Charlotte Foust" > >Subject: Re: [AccessD] Never Take a job for a friend (Three > > leveldesignquestion) > >To: "Access Developers discussion and problem solving" > > > >Message-ID: > > > > >Content-Type: text/plain; charset="us-ascii" > > > >Is there some reason NOT to use Access security for this? It still > >works in 2003 format. > > > >Charlotte Foust > > >-- >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 _________________________________________________________________ http://newlivehotmail.com From fuller.artful at gmail.com Tue Jul 3 11:21:46 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 3 Jul 2007 12:21:46 -0400 Subject: [AccessD] Forgotten Syntax Message-ID: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> I want to assign a value to a form that is guaranteed to be open. Scenario: OnEnter of a field on form A pops up a dialog that asks for a couple of values. Then I want to post the result to the field on form A and close the popup. Something like: Forms("A").form.B.ResultPlace = Me.Result or something. I keep forgetting this syntax. This time I'll tatoo it. A. From miscellany at mvps.org Tue Jul 3 11:34:21 2007 From: miscellany at mvps.org (Steve Schapel) Date: Wed, 04 Jul 2007 04:34:21 +1200 Subject: [AccessD] Open a combobox on entering it In-Reply-To: <003501c7bd7a$248145a0$1a58a27a@pcadt> References: <0JKL003TOQUQCO93@l-daemon> <003501c7bd7a$248145a0$1a58a27a@pcadt> Message-ID: <468A7A8D.2080305@mvps.org> A.D., I am interested in this topic, and would therefore appreciate if you can announce your findings after you have worked with Jim's database. Regards Steve A.D.TEJPAL wrote: > Jim, > > I would be glad to have a look at it. It would be nice if you could > kindly send it to me after removing passwords if any. For ready > reference, names of forms / reports that have been giving problems, > may please be mentioned, along with the typical steps needed to > re-create the adverse behavior. From bheygood at abestsystems.com Tue Jul 3 12:01:10 2007 From: bheygood at abestsystems.com (Bob Heygood) Date: Tue, 3 Jul 2007 10:01:10 -0700 Subject: [AccessD] Open Protected Excel via VBA In-Reply-To: References: <002301c7bcad$0471cf00$6401a8c0@speedy> Message-ID: <00b001c7bd93$c17ebfe0$6401a8c0@speedy> Hey Jim, Works Great Thanks so much. Bob Heygood -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim Sent: Monday, July 02, 2007 7:02 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open Protected Excel via VBA If you meant protected sheets within a workbook, appExcel.Sheets("instruc").Unprotect Password:=strPW Works. If you meant to unprotect a Workbook try the following code snippets: appexcel.Workbooks.Open strPath1 & "\" & strFilename, 0 appexcel.ActiveWorkbook.Unprotect Password:=strPW Jim Hale *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Tue Jul 3 12:03:56 2007 From: miscellany at mvps.org (Steve Schapel) Date: Wed, 04 Jul 2007 05:03:56 +1200 Subject: [AccessD] Forgotten Syntax In-Reply-To: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> References: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> Message-ID: <468A817C.8030401@mvps.org> Arthur, What does the "B" refer to in your example? Do you mean you want the result in a control on a subform? If the value form the popup form is going into a control on form A, then... Forms!A!ResultPlace = Me.Result If the value form the popup form is going into a control on subform B on form A, then... Forms!A!B.Form!ResultPlace = Me.Result Regards Steve Arthur Fuller wrote: > I want to assign a value to a form that is guaranteed to be open. Scenario: > OnEnter of a field on form A pops up a dialog that asks for a couple of > values. Then I want to post the result to the field on form A and close the > popup. > > Something like: > > Forms("A").form.B.ResultPlace = Me.Result > > or something. I keep forgetting this syntax. This time I'll tatoo it. > > A. From fuller.artful at gmail.com Tue Jul 3 12:32:05 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 3 Jul 2007 13:32:05 -0400 Subject: [AccessD] Forgotten Syntax In-Reply-To: <468A817C.8030401@mvps.org> References: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> <468A817C.8030401@mvps.org> Message-ID: <29f585dd0707031032x10eba3c0i2bde173efca200b9@mail.gmail.com> I should have been more clear, sorry about that. Call the popup form C, from which I want to execute the code. The target field is on form B, which is a subform of form A. Arthur On 7/3/07, Steve Schapel wrote: > > Arthur, > > What does the "B" refer to in your example? Do you mean you want the > result in a control on a subform? > > If the value form the popup form is going into a control on form A, > then... > Forms!A!ResultPlace = Me.Result > > If the value form the popup form is going into a control on subform B on > form A, then... > Forms!A!B.Form!ResultPlace = Me.Result > > Regards > Steve > From miscellany at mvps.org Tue Jul 3 12:41:23 2007 From: miscellany at mvps.org (Steve Schapel) Date: Wed, 04 Jul 2007 05:41:23 +1200 Subject: [AccessD] Forgotten Syntax In-Reply-To: <29f585dd0707031032x10eba3c0i2bde173efca200b9@mail.gmail.com> References: <29f585dd0707030921k3d36ee92u117c11e120b37222@mail.gmail.com> <468A817C.8030401@mvps.org> <29f585dd0707031032x10eba3c0i2bde173efca200b9@mail.gmail.com> Message-ID: <468A8A43.8040509@mvps.org> Ok, Arthur, so I think just as per my earlier reply: Forms!A!B.Form!ResultPlace = Me.Result Regards Steve Arthur Fuller wrote: > I should have been more clear, sorry about that. Call the popup form C, from > which I want to execute the code. The target field is on form B, which is a > subform of form A. From adtejpal at gmail.com Tue Jul 3 23:43:54 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Wed, 4 Jul 2007 10:13:54 +0530 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP References: Message-ID: <007801c7bdf6$36aed360$7c58a27a@pcadt> It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- From darrend at nimble.com.au Wed Jul 4 00:15:46 2007 From: darrend at nimble.com.au (Darren D) Date: Wed, 4 Jul 2007 15:15:46 +1000 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <007801c7bdf6$36aed360$7c58a27a@pcadt> Message-ID: <200707040516.l645G6TE011652@databaseadvisors.com> Brilliant Now all my posts will be sent straight to Marty - directly Well done - Congrats - Darren -----Original Message----- From: A.D.TEJPAL [mailto:adtejpal at gmail.com] Sent: Wednesday, 4 July 2007 2:44 PM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM From john at winhaven.net Wed Jul 4 00:26:25 2007 From: john at winhaven.net (John Bartow) Date: Wed, 4 Jul 2007 00:26:25 -0500 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <007801c7bdf6$36aed360$7c58a27a@pcadt> References: <007801c7bdf6$36aed360$7c58a27a@pcadt> Message-ID: <003201c7bdfb$dea71000$6402a8c0@ScuzzPaq> Congratulations Marty! Very well deserved IMHO. Thank you for all of your contributions to the various Database Advisors lists. Sincerely, John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Tuesday, July 03, 2007 11:44 PM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From darren at activebilling.com.au Wed Jul 4 00:31:39 2007 From: darren at activebilling.com.au (Darren D) Date: Wed, 4 Jul 2007 15:31:39 +1000 Subject: [AccessD] A2003:Merging Many files into one file Message-ID: <200707040532.l645Vx4s016666@databaseadvisors.com> Hi All I have no clue on how to do this I have say.10 txt files that I want to merge into 1 big txt file Any clues? Many thanks in advance Darren No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM From martyconnelly at shaw.ca Wed Jul 4 02:43:53 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Wed, 04 Jul 2007 00:43:53 -0700 Subject: [AccessD] A2003:Merging Many files into one file In-Reply-To: <200707040532.l645Vx4s016666@databaseadvisors.com> References: <200707040532.l645Vx4s016666@databaseadvisors.com> Message-ID: <468B4FB9.8030906@shaw.ca> Use the old dos command with a Shell function or DOS cmd Multifiles with wildcard copy "C:\temp\short*.txt" "c:\:temp\mybigfile.txt" or copy "C:\temp\short1.txt" + C:\temp\short2.txt" "c:\:temp\mybigfile.txt" get the help file for copy or xcopy at cmd prompt C:\>copy /? Copies one or more files to another location. COPY [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B] [+ source [/A | /B] [+ ...]] [destination [/A | /B]] source Specifies the file or files to be copied. /A Indicates an ASCII text file. /B Indicates a binary file. destination Specifies the directory and/or filename for the new file(s). /V Verifies that new files are written correctly. /N Uses short filename, if available, when copying a file with a non-8dot3 name. /Y Suppresses prompting to confirm you want to overwrite an existing destination file. /-Y Causes prompting to confirm you want to overwrite an existing destination file. /Z Copies networked files in restartable mode. The switch /Y may be preset in the COPYCMD environment variable. This may be overridden with /-Y on the command line. Default is to prompt on overwrites unless COPY command is being executed from within a batch script. To append files, specify a single file for destination, but multiple files for source (using wildcards or file1+file2+file3 format). Darren D wrote: >Hi All > > > >I have no clue on how to do this > > > >I have say.10 txt files that I want to merge into 1 big txt file > > > >Any clues? > > > >Many thanks in advance > > > >Darren > > > > -- Marty Connelly Victoria, B.C. Canada From Gustav at cactus.dk Wed Jul 4 04:29:01 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Wed, 04 Jul 2007 11:29:01 +0200 Subject: [AccessD] Manipulate AC95 mdb files without converting Message-ID: Hi Anita Is that really you? I was sure you had left the list. Welcome back! /gustav >>> anitatiedemann at gmail.com 02-07-2007 07:26 >>> Kevin You should be able to simply open the database with any later versions of Access and enter data directly into it. Anita Smith Australia From ssharkins at setel.com Wed Jul 4 13:07:53 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 4 Jul 2007 14:07:53 -0400 Subject: [AccessD] Omission of Me Message-ID: <000001c7be66$3ede82e0$06b62ad1@SusanOne> Does anyone remember what version of Access dropped the need for Me or the Forms.formname identifiers when the form (or report) is current? I think it was XP, but I really don't remember. It seems like it's been around for a really long time, so maybe it was 2000? Susan H. From accma at sympatico.ca Wed Jul 4 18:07:44 2007 From: accma at sympatico.ca (Annie Courchesne, CMA) Date: Wed, 4 Jul 2007 19:07:44 -0400 Subject: [AccessD] Performance tips anyone? Message-ID: <002201c7be90$215364f0$6800a8c0@anniec> Hi all, I have a customer that complains about his database (BE/FE A97 running in runtime mode) is slow. The number of concurrent user keep growing over the years and it's up to 10 or 12 now. What I'm looking at right now is to optimize the whole database and upgrade to Access 2003. I've look at the performance tips from this page (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some pretty usefull information. Anyone has other tips on getting this database more performing? I was also wondering if using a dedicated server for the database would help to improve performance? And what about SQL Server 2005 Express? I've read here that it's free and has a large capacity (more than enough for what I need). Will it really help in speeding up the database? How hard is it to set up? Any good documentation I can read on this? Thanks to all of you! Annie Courchesne, CMA From jwcolby at colbyconsulting.com Wed Jul 4 18:52:18 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 4 Jul 2007 19:52:18 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <20070704235234.7B130BCEC@smtp-auth.no-ip.com> If you are not doing so yet, the biggest single thing that you can do is keep a pointer to a table in the BE open. You can do that by opening a table, query or form based on a table etc. Doesn't matter how you do it but keep a pointer open. What happens is that the first time a table in the BE is used, JET has to acquire locks on the BE which takes longer and longer as more and more users are in the database. Once that first lock is acquired however, the next usage of the BE is much faster. Thus keeping some table open to the BE establishes that first lock and then keeps it open. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Wednesday, July 04, 2007 7:08 PM To: accessd at databaseadvisors.com Subject: [AccessD] Performance tips anyone? Hi all, I have a customer that complains about his database (BE/FE A97 running in runtime mode) is slow. The number of concurrent user keep growing over the years and it's up to 10 or 12 now. What I'm looking at right now is to optimize the whole database and upgrade to Access 2003. I've look at the performance tips from this page (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some pretty usefull information. Anyone has other tips on getting this database more performing? I was also wondering if using a dedicated server for the database would help to improve performance? And what about SQL Server 2005 Express? I've read here that it's free and has a large capacity (more than enough for what I need). Will it really help in speeding up the database? How hard is it to set up? Any good documentation I can read on this? Thanks to all of you! Annie Courchesne, CMA -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From anitatiedemann at gmail.com Wed Jul 4 19:41:42 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 10:41:42 +1000 Subject: [AccessD] Manipulate AC95 mdb files without converting In-Reply-To: References: Message-ID: Hi Gustav, Yes it's me. I never really left the list. I just did not receive posts for a long time. I thought I would get the posts for a while to see whats happening. It appears that the number of posts have dropped off a lot which is good because I don't have time to read that many. I hope you are all well and still working away in Access. I still work with Access but have moved to SQL server for the back end. I still love using Access to develop the front ends simply because I can get a lot done in a short space of time. I find that using SQL server stored procedures is just so efficient, it allows the developer to move a lot of functionality to the database. I was wondering what the general opinions of the latest version of Access are? I installed it, but have not worked with it yet. It appears to have been designed for non developers? Anita Smith Australia On 7/4/07, Gustav Brock wrote: > > Hi Anita > > Is that really you? I was sure you had left the list. > Welcome back! > > /gustav > > >>> anitatiedemann at gmail.com 02-07-2007 07:26 >>> > Kevin > You should be able to simply open the database with any later versions of > Access and enter data directly into it. > Anita Smith > Australia > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From darrend at nimble.com.au Wed Jul 4 19:49:58 2007 From: darrend at nimble.com.au (Darren D) Date: Thu, 5 Jul 2007 10:49:58 +1000 Subject: [AccessD] A2003:Merging Many files into one file In-Reply-To: <468B4FB9.8030906@shaw.ca> Message-ID: <200707050050.l650oTd1005120@databaseadvisors.com> Marty - Brilliant and simple Just what I needed Thanks DD -----Original Message----- From: MartyConnelly [mailto:martyconnelly at shaw.ca] Sent: Wednesday, 4 July 2007 5:44 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] A2003:Merging Many files into one file Use the old dos command with a Shell function or DOS cmd Multifiles with wildcard copy "C:\temp\short*.txt" "c:\:temp\mybigfile.txt" or copy "C:\temp\short1.txt" + C:\temp\short2.txt" "c:\:temp\mybigfile.txt" get the help file for copy or xcopy at cmd prompt C:\>copy /? Copies one or more files to another location. COPY [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B] [+ source [/A | /B] [+ ...]] [destination [/A | /B]] source Specifies the file or files to be copied. /A Indicates an ASCII text file. /B Indicates a binary file. destination Specifies the directory and/or filename for the new file(s). /V Verifies that new files are written correctly. /N Uses short filename, if available, when copying a file with a non-8dot3 name. /Y Suppresses prompting to confirm you want to overwrite an existing destination file. /-Y Causes prompting to confirm you want to overwrite an existing destination file. /Z Copies networked files in restartable mode. The switch /Y may be preset in the COPYCMD environment variable. This may be overridden with /-Y on the command line. Default is to prompt on overwrites unless COPY command is being executed from within a batch script. To append files, specify a single file for destination, but multiple files for source (using wildcards or file1+file2+file3 format). Darren D wrote: >Hi All > > > >I have no clue on how to do this > > > >I have say.10 txt files that I want to merge into 1 big txt file > > > >Any clues? > > > >Many thanks in advance > > > >Darren > > > > -- Marty Connelly Victoria, B.C. Canada -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.12/878 - Release Date: 28/06/2007 5:57 PM From anitatiedemann at gmail.com Wed Jul 4 20:00:17 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 11:00:17 +1000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <002201c7be90$215364f0$6800a8c0@anniec> References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: Annie, There are a number of things you can do to speed up an Access Database. I haven't looked at the link you provided, but here are a few suggestions based on my experience over the years: * Make sure your tables contain indexes on the fields frequently used for criteria in queries * Put the criteria on the ONE side of the relationship in queries * Don't open forms and reports with large underlying recordsources. If possible open the forms with only 1 underlying record - not a whole table. * I have found that opening a form specifying the procedure arguments makes it open faster DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of DoCmd.OpenForm "MyForm" Upgrading to A2003 probably won't make much difference. Using Runtime mode should not make it run any slower either. SQL server Express is a great option, but you would probably have to rewrite the form and report recordsources to really take advantage of it. It is not hard to set up. I think there is an upgrade wizard that will upgrade an Access Database to SQL Server. I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. I hope this helps a bit. Anita On 7/5/07, Annie Courchesne, CMA wrote: > > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over > the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and > upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would > help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From developer at ultradnt.com Wed Jul 4 23:04:13 2007 From: developer at ultradnt.com (Steve Conklin) Date: Thu, 5 Jul 2007 00:04:13 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> Replace any DoCmd.RunSQL's with CurrentDB.execute. Steve -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Wednesday, July 04, 2007 9:00 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Annie, There are a number of things you can do to speed up an Access Database. I haven't looked at the link you provided, but here are a few suggestions based on my experience over the years: * Make sure your tables contain indexes on the fields frequently used for criteria in queries * Put the criteria on the ONE side of the relationship in queries * Don't open forms and reports with large underlying recordsources. If possible open the forms with only 1 underlying record - not a whole table. * I have found that opening a form specifying the procedure arguments makes it open faster DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of DoCmd.OpenForm "MyForm" Upgrading to A2003 probably won't make much difference. Using Runtime mode should not make it run any slower either. SQL server Express is a great option, but you would probably have to rewrite the form and report recordsources to really take advantage of it. It is not hard to set up. I think there is an upgrade wizard that will upgrade an Access Database to SQL Server. I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. I hope this helps a bit. Anita On 7/5/07, Annie Courchesne, CMA wrote: > > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running > in runtime mode) is slow. The number of concurrent user keep growing > over the years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and > upgrade to Access 2003. I've look at the performance tips from this > page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > some pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database > would help to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free > and has a large capacity (more than enough for what I need). Will it > really help in speeding up the database? How hard is it to set up? > Any good documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > > -- > 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 jwcolby at colbyconsulting.com Wed Jul 4 23:29:03 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 00:29:03 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Anita, >I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). And of course all of the things you mentioned in terms of FE optimizations. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Wednesday, July 04, 2007 9:00 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Annie, There are a number of things you can do to speed up an Access Database. I haven't looked at the link you provided, but here are a few suggestions based on my experience over the years: * Make sure your tables contain indexes on the fields frequently used for criteria in queries * Put the criteria on the ONE side of the relationship in queries * Don't open forms and reports with large underlying recordsources. If possible open the forms with only 1 underlying record - not a whole table. * I have found that opening a form specifying the procedure arguments makes it open faster DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of DoCmd.OpenForm "MyForm" Upgrading to A2003 probably won't make much difference. Using Runtime mode should not make it run any slower either. SQL server Express is a great option, but you would probably have to rewrite the form and report recordsources to really take advantage of it. It is not hard to set up. I think there is an upgrade wizard that will upgrade an Access Database to SQL Server. I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. I hope this helps a bit. Anita From miscellany at mvps.org Wed Jul 4 23:54:24 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 16:54:24 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> References: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Message-ID: <468C7980.9070407@mvps.org> I agree, John. Access should handle more than 10-12 users under most circumstances, and generally many more than that. It is very difficult to make comparisons in terms of "number of users", as this will vary enormously depending on the nature of the application, and the way in which the users are hitting the database. Regards Steve jwcolby wrote: > Anita, > >> I think that 10-12 users is the absolute maximum you will get out of an > Access database it will continue to get slower over the years as the > database grows. At some stage you would probably have to upgrade to SQL > server. > > Errrrr! Wrong answer. > > I have a database with 25 users in the database every day. The BE is > currently about 800 mbytes. This BE has tables with hundreds of thousands > of records in some tables, 30K-50K records in the main tables (claimant / > claim). I open a VERY complex tabbed form with about 20 tabs on it, with > subforms on each tab (JIT subforms). > > Users on fast machines open the form in about 1.2 seconds. Users on very > old slow machines take about 5 to 6 seconds. > > Speed of the individual workstation is the single largest determinate of > acceptable speed. A high speed processor and LOTS of memory (1 gig for > Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference > as well (which requires a gigabit NIC in the machines as well). > > And of course all of the things you mentioned in terms of FE optimizations. > From miscellany at mvps.org Wed Jul 4 23:56:17 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 16:56:17 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <468C79F1.3060408@mvps.org> Anita Smith wrote: > * I have found that opening a form specifying the procedure arguments makes > it open faster > DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of > DoCmd.OpenForm "MyForm" That's very interesting, Anita, I hadn't heard about this. Thanks. Is this a subjective impression, or did you do some speed measurement testing? Regards Steve From anitatiedemann at gmail.com Wed Jul 4 23:56:49 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 14:56:49 +1000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> References: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Message-ID: John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita From miscellany at mvps.org Wed Jul 4 23:59:28 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 16:59:28 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: <000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> References: <002201c7be90$215364f0$6800a8c0@anniec> <000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> Message-ID: <468C7AB0.8090900@mvps.org> Sorry to be contrary, Steve, but I don't think this is supported by the evidence. In fact, I believe DoCmd.OpenQuery would perform faster if you are running a saved query, as long as the number of records hasn't changed dramatically since the last time it was run. But either way, I think this is possibly academic interest only, as the speed differences here are likely to be imperceptible. Regards Steve Steve Conklin wrote: > Replace any DoCmd.RunSQL's with CurrentDB.execute. > From anitatiedemann at gmail.com Thu Jul 5 00:01:34 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 15:01:34 +1000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <468C79F1.3060408@mvps.org> References: <002201c7be90$215364f0$6800a8c0@anniec> <468C79F1.3060408@mvps.org> Message-ID: Steve, One day while testing a form I found it was slow to open (I like my forms to open instantly). When I added the arguments it magically speeded up. I am at a loss as to why? Anita On 7/5/07, Steve Schapel wrote: > > Anita Smith wrote: > > * I have found that opening a form specifying the procedure arguments > makes > > it open faster > > DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of > > DoCmd.OpenForm "MyForm" > > That's very interesting, Anita, I hadn't heard about this. Thanks. Is > this a subjective impression, or did you do some speed measurement > testing? > > Regards > Steve > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From miscellany at mvps.org Thu Jul 5 00:09:37 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 17:09:37 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: <002201c7be90$215364f0$6800a8c0@anniec> References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <468C7D11.9050201@mvps.org> Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > From adtejpal at gmail.com Thu Jul 5 00:11:03 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Thu, 5 Jul 2007 10:41:03 +0530 Subject: [AccessD] Naming of controls - [Was: Open a combobox on entering it] References: <0JKL003TOQUQCO93@l-daemon> Message-ID: <008c01c7bec3$561511b0$4e57a27a@pcadt> Jim, Thanks for making the file available for study. My findings are placed in the note appended below. Certain factors as brought out are suspected to have contributed to the inconsistent behavior mentioned in your post. I understand this is a db that was handed over to you. Of course, if it had been your own creation, the aberrations would not have crept in. A gist of the findings: (a) A particular bound control is named as per a field other than its actual control source. Moreover, the name of its source field is a reserved word (Name). Combination of these factors makes it a case of multiplied pitfall. (b) Embedded quote in field name. Better avoid. (c) Lookup fields used in tables. Not considered desirable. (d) Subdatasheet property of tables is Auto. It should be set to None. (e) In many cases, table column headings are at variance with field names. Better keep the tables simple & straightforward. Instead, the objective can be met through suitable captions on form labels. As mentioned by you, the problem experienced at your end has been surfacing intermittently. In limited tests at my end, no abnormality could be detected. However, it can be expected that if the points brought out above (details in the note below) are attended to and even with names of pure bound controls kept same as their source fields, the db should perform consistently. Simultaneously, it has to be ensured that the names of unbound and calculated controls never coincide with any field name in the record source. Best wishes, A.D.Tejpal --------------- Findings ======================================= 1 - Bound text box named LstnmVol on form frmHoursWorked: (a) Control source for this text box is a field named Name (a reserved word). (b) LstnmVol is itself a field in tblVolunteers, one of the source tables for the query serving as record source for this form. (c) Combination of (a) & (b) above, is bound to invite trouble as it becomes a case of contaminated bound control, named after an existing field in one of the source tables, even though that particular field is not its control source. Moreover, the control source actually used (Name) happens to be a reserved word. (d) It appears that to start with, this control was bound to field LstnmVol and was correctly named accordingly. Later when calculated field Name was used as the control source, re-naming of the control accordingly (to match the name of new control source) seems to have been overlooked. (e) Suggested step - Modify the name of calculated field in record source from Name to VName. Control source as well as name of this text box would then become VName. 2 - Control named DtEnt'dHW on form frmHoursWorked: (a) There is an embedded quote in the name of control as well as source field. (b) Suggested step - Eliminate embedded quote in field as well as control name. 3 - Data Tables: (a) In many cases, column headings are different from field names. It is considered desirable to keep the tables as simple & straightforward as possible. The process of depicting the fields under more convenient names should better be handled at form level, through suitable captions for labels. (b) Subdatasheet property of all tables should be set to None. (At present it is Auto). (c) Two fields in table tblHourWorked are found to be lookup type. This is considered a violation of ten commandments. Note: (a) SQL serving as record source for form frmHoursWorked involves inner join on EventNum between tables tblHourWorked and tblEvents. At present, this field is blank in tblHourWorked, leading to no record getting displayed. For testing, tblEvents was removed from the query, temporarily. Retaining this table & displaying the records by converting to Left join would have rendered the recordset non-updateable. (b) Compile error in form lstEditHrsWkd on account of missing End If in two subroutines. This was rectified. ======================================= ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 17:38 Subject: Re: [AccessD] Open a combobox on entering it Hi A.D. Tejpal: If you would like I could give you a copy of the application before I played around with it. The application was giving the strangest errors. In one example: a combo box would not take the assignment of an initial value but there were no error messages generated... and the issue was not consistent... sometimes it would work fine... but when the combo box name was changed this problem was gone with no other modifications. I have read some warning about this effect, a number of years ago, the article discussed 'Context and Naming-Conventions' but I can not find any reference to the white-paper. Maybe someone else can remember? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 9:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim From miscellany at mvps.org Thu Jul 5 00:28:49 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 05 Jul 2007 17:28:49 +1200 Subject: [AccessD] Naming of controls - [Was: Open a combobox on entering it] In-Reply-To: <008c01c7bec3$561511b0$4e57a27a@pcadt> References: <0JKL003TOQUQCO93@l-daemon> <008c01c7bec3$561511b0$4e57a27a@pcadt> Message-ID: <468C8191.9050107@mvps.org> A.D., I so enjoyed your use of the terminology "a case of multiplied pitfall". :-) I was very interested to see your discussion, so thanks for doing it. In particular, I would certainly expect a control named the same as the name of *another* field in the form's record source, to eventually cause a hiccup. Regards Steve A.D.TEJPAL wrote: > Jim, > > Thanks for making the file available for study. My findings are placed in the note appended below. Certain factors as brought out are suspected to have contributed to the inconsistent behavior mentioned in your post. I understand this is a db that was handed over to you. Of course, if it had been your own creation, the aberrations would not have crept in. > > A gist of the findings: > (a) A particular bound control is named as per a field other than its actual control source. Moreover, the name of its source field is a reserved word (Name). Combination of these factors makes it a case of multiplied pitfall. > (b) Embedded quote in field name. Better avoid. > (c) Lookup fields used in tables. Not considered desirable. > (d) Subdatasheet property of tables is Auto. It should be set to None. > (e) In many cases, table column headings are at variance with field names. Better keep the tables simple & straightforward. Instead, the objective can be met through suitable captions on form labels. > > As mentioned by you, the problem experienced at your end has been surfacing intermittently. In limited tests at my end, no abnormality could be detected. > > However, it can be expected that if the points brought out above (details in the note below) are attended to and even with names of pure bound controls kept same as their source fields, the db should perform consistently. Simultaneously, it has to be ensured that the names of unbound and calculated controls never coincide with any field name in the record source. From jwcolby at colbyconsulting.com Thu Jul 5 00:42:34 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 01:42:34 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705054251.62982BD59@smtp-auth.no-ip.com> Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 00:45:53 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 01:45:53 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <468C7D11.9050201@mvps.org> Message-ID: <20070705054610.9B201BDAC@smtp-auth.no-ip.com> >And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Thursday, July 05, 2007 1:10 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running > in runtime mode) is slow. The number of concurrent user keep growing > over the years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and > upgrade to Access 2003. I've look at the performance tips from this > page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > some pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database > would help to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free > and has a large capacity (more than enough for what I need). Will it > really help in speeding up the database? How hard is it to set up? > Any good documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From anitatiedemann at gmail.com Thu Jul 5 01:17:04 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Thu, 5 Jul 2007 16:17:04 +1000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705054610.9B201BDAC@smtp-auth.no-ip.com> References: <468C7D11.9050201@mvps.org> <20070705054610.9B201BDAC@smtp-auth.no-ip.com> Message-ID: Perhaps you could write some code to run through all the queries to run them before redeploying the database. Anita On 7/5/07, jwcolby wrote: > > >And here's another thing I only found out about this week... the first > time > a saved query is run after the database is compacted, will be slow, > because > the query plan has to be re-created. > > Ohhhh that is something to consider, I kinda knew this but never thought > of > it in quite this light. I build and then upload to a server. The users > download the FE every day. Thus the first time they open anything it will > be slow, every day. Sigh. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel > Sent: Thursday, July 05, 2007 1:10 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Performance tips anyone? > > Annie, > > If you have forms with lots of comboboxes, it certainly helps if you don't > populate them unless and until they are needed, i.e. set the Row Source on > their Enter event. > > Similarly, if you have forms with subforms on different pages of a tab > control, leave the Source Object of the subforms blanks, and only set it > if > and when that tab is selected. > > And here's another thing I only found out about this week... the first > time > a saved query is run after the database is compacted, will be slow, > because > the query plan has to be re-created. So if you compact/repair the > front-end > application file, queries will run slow the first time, and forms based on > queries will open slowly the first time. An argument against 'Compact On > Close' - but then, for memory, I don't think Comapct On Close was > available > in Access 97. > > Regards > Steve > > > Annie Courchesne, CMA wrote: > > Hi all, > > > > > > > > I have a customer that complains about his database (BE/FE A97 running > > in runtime mode) is slow. The number of concurrent user keep growing > > over the years and it's up to 10 or 12 now. > > > > > > > > What I'm looking at right now is to optimize the whole database and > > upgrade to Access 2003. I've look at the performance tips from this > > page > > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > > some pretty usefull information. > > > > > > > > Anyone has other tips on getting this database more performing? > > > > > > > > I was also wondering if using a dedicated server for the database > > would help to improve performance? > > > > > > > > And what about SQL Server 2005 Express? I've read here that it's free > > and has a large capacity (more than enough for what I need). Will it > > really help in speeding up the database? How hard is it to set up? > > Any good documentation I can read on this? > > > > > > > > Thanks to all of you! > > > > > > > > > > > > Annie Courchesne, CMA > > > > > > > -- > 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 accessd at shaw.ca Thu Jul 5 01:25:39 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Wed, 04 Jul 2007 23:25:39 -0700 Subject: [AccessD] Naming of controls - [Was: Open a combobox on entering it] In-Reply-To: <008c01c7bec3$561511b0$4e57a27a@pcadt> Message-ID: <0JKP006VV0AWAEU0@l-daemon> Hi A D Tejpal: No problem. That example is definitely one of the worse I have seen for a while. Added to those coding issues is a poor design. Consider that the lady that made the database designed it never having worked in Access or any database before, she is a hair-dresser who was doing a friend a favour, I think she did rather well. Regards Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Wednesday, July 04, 2007 10:11 PM To: Access Developers discussion and problem solving Cc: A. D. TEJPAL Subject: Re: [AccessD] Naming of controls - [Was: Open a combobox on entering it] Jim, Thanks for making the file available for study. My findings are placed in the note appended below. Certain factors as brought out are suspected to have contributed to the inconsistent behavior mentioned in your post. I understand this is a db that was handed over to you. Of course, if it had been your own creation, the aberrations would not have crept in. A gist of the findings: (a) A particular bound control is named as per a field other than its actual control source. Moreover, the name of its source field is a reserved word (Name). Combination of these factors makes it a case of multiplied pitfall. (b) Embedded quote in field name. Better avoid. (c) Lookup fields used in tables. Not considered desirable. (d) Subdatasheet property of tables is Auto. It should be set to None. (e) In many cases, table column headings are at variance with field names. Better keep the tables simple & straightforward. Instead, the objective can be met through suitable captions on form labels. As mentioned by you, the problem experienced at your end has been surfacing intermittently. In limited tests at my end, no abnormality could be detected. However, it can be expected that if the points brought out above (details in the note below) are attended to and even with names of pure bound controls kept same as their source fields, the db should perform consistently. Simultaneously, it has to be ensured that the names of unbound and calculated controls never coincide with any field name in the record source. Best wishes, A.D.Tejpal --------------- Findings ======================================= 1 - Bound text box named LstnmVol on form frmHoursWorked: (a) Control source for this text box is a field named Name (a reserved word). (b) LstnmVol is itself a field in tblVolunteers, one of the source tables for the query serving as record source for this form. (c) Combination of (a) & (b) above, is bound to invite trouble as it becomes a case of contaminated bound control, named after an existing field in one of the source tables, even though that particular field is not its control source. Moreover, the control source actually used (Name) happens to be a reserved word. (d) It appears that to start with, this control was bound to field LstnmVol and was correctly named accordingly. Later when calculated field Name was used as the control source, re-naming of the control accordingly (to match the name of new control source) seems to have been overlooked. (e) Suggested step - Modify the name of calculated field in record source from Name to VName. Control source as well as name of this text box would then become VName. 2 - Control named DtEnt'dHW on form frmHoursWorked: (a) There is an embedded quote in the name of control as well as source field. (b) Suggested step - Eliminate embedded quote in field as well as control name. 3 - Data Tables: (a) In many cases, column headings are different from field names. It is considered desirable to keep the tables as simple & straightforward as possible. The process of depicting the fields under more convenient names should better be handled at form level, through suitable captions for labels. (b) Subdatasheet property of all tables should be set to None. (At present it is Auto). (c) Two fields in table tblHourWorked are found to be lookup type. This is considered a violation of ten commandments. Note: (a) SQL serving as record source for form frmHoursWorked involves inner join on EventNum between tables tblHourWorked and tblEvents. At present, this field is blank in tblHourWorked, leading to no record getting displayed. For testing, tblEvents was removed from the query, temporarily. Retaining this table & displaying the records by converting to Left join would have rendered the recordset non-updateable. (b) Compile error in form lstEditHrsWkd on account of missing End If in two subroutines. This was rectified. ======================================= ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 17:38 Subject: Re: [AccessD] Open a combobox on entering it Hi A.D. Tejpal: If you would like I could give you a copy of the application before I played around with it. The application was giving the strangest errors. In one example: a combo box would not take the assignment of an initial value but there were no error messages generated... and the issue was not consistent... sometimes it would work fine... but when the combo box name was changed this problem was gone with no other modifications. I have read some warning about this effect, a number of years ago, the article discussed 'Context and Naming-Conventions' but I can not find any reference to the white-paper. Maybe someone else can remember? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Monday, July 02, 2007 9:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Open a combobox on entering it Jim, Would you be in a position to isolate a typical form or report that has caused trouble on account of control names as mentioned in your post, and make it available as a self contained small db, for further investigation ? Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Tuesday, July 03, 2007 00:28 Subject: Re: [AccessD] Open a combobox on entering it Hi Charlotte: I have just been running into problems with the controls named the name of the data field... A client has this package and all sorts of weird things were happening. At 3:00AM, I started naming control appropriately and things started magically working :-) The strange thing is that the app never complained it just didn't work right and the results were never consistent... So, don't do it Arthur... if only for your own health and sanity. :-) Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Andrew.Curtis at wapl.com.au Thu Jul 5 01:21:36 2007 From: Andrew.Curtis at wapl.com.au (Curtis, Andrew (WAPL)) Date: Thu, 5 Jul 2007 14:21:36 +0800 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705054251.62982BD59@smtp-auth.no-ip.com> References: <20070705054251.62982BD59@smtp-auth.no-ip.com> Message-ID: Anita, you havent said how big your FE is in mb? Also, does every user have a copy of the FE on their own PC, or are they accessing a common FE also from a network? In my experience this has a direct bearing on the load speed. Some other things I have found along the way: A) only select data based on deterministic fields. In other words if you have a table with field1, field2, with field1="job" and field2="2222", don't go building a query that concatenates these fields then open a form based on that query using (select * from queryx where concatfield="job2222"). Any index on field1 and 2 of the table would be ignored if the index were not compound (including both fields). If you find yourself routinely selecting data from tables that don't have exactly what your after (select * from tablex where field1="job" and field2="2222" then you may incur a performance hit. Consider in this case, a third field in tablex called "fullfield" with a value of "job2222", indexed. Then select straight from the table. The fullfield could be filled at data entry. B) FE bloat, usually caused by long running queries, repair and compact of the FE reduces the size in this case. C) fill tabs on forms, only when the tab is selected. This way when the form is opened, only the default tab needs to bet data on opening. If any of this is off base, appologies in advance, but I have just been through a similar exercise with another persons creation with quite staggering results. --Regards Andrew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, 5 July 2007 1:43 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 This message and any attached files may contain information that is confidential and/or subject of legal privilege intended only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete the message. From Andrew.Curtis at wapl.com.au Thu Jul 5 01:31:43 2007 From: Andrew.Curtis at wapl.com.au (Curtis, Andrew (WAPL)) Date: Thu, 5 Jul 2007 14:31:43 +0800 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705054251.62982BD59@smtp-auth.no-ip.com> References: <20070705054251.62982BD59@smtp-auth.no-ip.com> Message-ID: This article may help you out. Performance analyzer http://articles.techrepublic.com.com/5100-1035_11-5034310.html you may need to sign up, its free and worthwhile. --andrew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, 5 July 2007 1:43 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 This message and any attached files may contain information that is confidential and/or subject of legal privilege intended only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this message in error please notify the sender immediately and delete the message. From accma at sympatico.ca Thu Jul 5 05:25:59 2007 From: accma at sympatico.ca (Annie Courchesne, CMA) Date: Thu, 5 Jul 2007 06:25:59 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <000901c7beee$e163b390$6800a8c0@anniec> Hi Anita, Thanks for the tips. About the tip for opening a form with complete argument, would this also apply to openreport? A lot of report are quite slow to open. Thanks! Annie Courchesne, CMA -----Message d'origine----- De?: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Anita Smith Envoy??: 4 juillet 2007 21:00 ??: Access Developers discussion and problem solving Objet?: Re: [AccessD] Performance tips anyone? Annie, There are a number of things you can do to speed up an Access Database. I haven't looked at the link you provided, but here are a few suggestions based on my experience over the years: * Make sure your tables contain indexes on the fields frequently used for criteria in queries * Put the criteria on the ONE side of the relationship in queries * Don't open forms and reports with large underlying recordsources. If possible open the forms with only 1 underlying record - not a whole table. * I have found that opening a form specifying the procedure arguments makes it open faster DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of DoCmd.OpenForm "MyForm" Upgrading to A2003 probably won't make much difference. Using Runtime mode should not make it run any slower either. SQL server Express is a great option, but you would probably have to rewrite the form and report recordsources to really take advantage of it. It is not hard to set up. I think there is an upgrade wizard that will upgrade an Access Database to SQL Server. I think that 10-12 users is the absolute maximum you will get out of an Access database it will continue to get slower over the years as the database grows. At some stage you would probably have to upgrade to SQL server. I hope this helps a bit. Anita On 7/5/07, Annie Courchesne, CMA wrote: > > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over > the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and > upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would > help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > > -- > 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 accma at sympatico.ca Thu Jul 5 05:35:26 2007 From: accma at sympatico.ca (Annie Courchesne, CMA) Date: Thu, 5 Jul 2007 06:35:26 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <468C7D11.9050201@mvps.org> References: <002201c7be90$215364f0$6800a8c0@anniec> <468C7D11.9050201@mvps.org> Message-ID: <000a01c7bef0$330cbdd0$6800a8c0@anniec> Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De?: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy??: 5 juillet 2007 01:10 ??: Access Developers discussion and problem solving Objet?: Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Thu Jul 5 06:02:58 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 05 Jul 2007 13:02:58 +0200 Subject: [AccessD] Performance tips anyone? Message-ID: Hi Annie It sounds like you have the FEs on the server? Try to copy them to a workstation, relink BE tables and test performance. You should observe a great improvement. If so, at start up of a workstation, copy a master of each FE to a local drive and use these. Or (also,) move the temp tables to a separate local database which you recreate at every start up. Write protect the report FE to disable bloat. /gustav >>> accma at sympatico.ca 05-07-2007 12:35 >>> Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De : accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy? : 5 juillet 2007 01:10 ? : Access Developers discussion and problem solving Objet : Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA From ewaldt at gdls.com Thu Jul 5 07:05:11 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 5 Jul 2007 08:05:11 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: John: Could you include code to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From jwcolby at colbyconsulting.com Thu Jul 5 07:13:27 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 08:13:27 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705121344.A2BA7BD5A@smtp-auth.no-ip.com> Yep, I need to do something like this. Often in Access this isn't very feasible since many people use references to controls on forms, which means the form has to be open to cause the query to run. I stopped using that method long ago, preferring to use "filters" (static functions) to pass parameters to queries. So I can probably write code to iterate the querydef collection, grabbing the name of each query and executing it. Even then it could take awhile to execute every query in a FE. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of ewaldt at gdls.com Sent: Thursday, July 05, 2007 8:05 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? John: Could you include code to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ewaldt at gdls.com Thu Jul 5 07:19:59 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 5 Jul 2007 08:19:59 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: John: Could you include code to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From accma at sympatico.ca Thu Jul 5 07:33:23 2007 From: accma at sympatico.ca (Annie Courchesne, CMA) Date: Thu, 5 Jul 2007 08:33:23 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Hi Gustav, The FEs are on the local machine... sorry for not specifying this. The temp tables are on the local machine also, but I never thought to have those table put in a completely seperated db and to recreate them at start up... I'll have to look this up. Thanks! Annie Courchesne, CMA -----Message d'origine----- De : accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part deGustav Brock Envoy? : 5 juillet, 2007 07:03 ? : accessd at databaseadvisors.com Objet : Re: [AccessD] Performance tips anyone? Hi Annie It sounds like you have the FEs on the server? Try to copy them to a workstation, relink BE tables and test performance. You should observe a great improvement. If so, at start up of a workstation, copy a master of each FE to a local drive and use these. Or (also,) move the temp tables to a separate local database which you recreate at every start up. Write protect the report FE to disable bloat. /gustav >>> accma at sympatico.ca 05-07-2007 12:35 >>> Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De : accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy? : 5 juillet 2007 01:10 ? : Access Developers discussion and problem solving Objet : Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running in > runtime mode) is slow. The number of concurrent user keep growing over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free and > has a large capacity (more than enough for what I need). Will it really > help in speeding up the database? How hard is it to set up? Any good > documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ewaldt at gdls.com Thu Jul 5 07:41:59 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 5 Jul 2007 08:41:59 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: John: Could you include code to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From Jdemarco at hudsonhealthplan.org Thu Jul 5 08:20:37 2007 From: Jdemarco at hudsonhealthplan.org (Jim DeMarco) Date: Thu, 5 Jul 2007 09:20:37 -0400 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <007801c7bdf6$36aed360$7c58a27a@pcadt> References: <007801c7bdf6$36aed360$7c58a27a@pcadt> Message-ID: <0B8880A20E2CF24280FA60901E108FB08F28FD@TTNEXCHSVR.hshhp.com> Awesome news!! Congrats Marty you certainly deserve it. Wasn't there just a thread on this here?? Were we clairvoyant? Jim DeMarco -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Wednesday, July 04, 2007 12:44 AM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 08:26:22 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 09:26:22 -0400 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <007801c7bdf6$36aed360$7c58a27a@pcadt> Message-ID: <20070705132640.76E80BEF0@smtp-auth.no-ip.com> Indeed, congrats Marty, well deserved. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Wednesday, July 04, 2007 12:44 AM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 08:28:05 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 09:28:05 -0400 Subject: [AccessD] FW: Performance tips anyone? Message-ID: <20070705132822.AF216BF04@smtp-auth.no-ip.com> Can our list manager help Thomas figure out why he gets bounce messages. His messages are getting through but he is being told they aren't. Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com _____ From: ewaldt at gdls.com [mailto:ewaldt at gdls.com] Sent: Thursday, July 05, 2007 9:07 AM To: jwcolby at colbyconsulting.com Subject: Re: Performance tips anyone? John: I keep sending this to the list, but it keeps being rejected; something about "the recipient's BlackBerry Handheld". Anyway, thought I'd send it on to you. You've probably already thought of it, but just in case... Could you include code in a module to open and close all queries, "hide" the code so only you run it, but then run it before posting the new update to the FE? That should recreate any query plans, shouldn't it? Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems John Colby responded to Steve Schapel: Ohhhh that is something to consider, I kinda knew this but never thought of it in quite this light. I build and then upload to a server. The users download the FE every day. Thus the first time they open anything it will be slow, every day. Sigh. Steve had said: And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From jwcolby at colbyconsulting.com Thu Jul 5 08:45:58 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 09:45:58 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <000a01c7bef0$330cbdd0$6800a8c0@anniec> Message-ID: <20070705134615.7C7B3BD93@smtp-auth.no-ip.com> I have to say, that is a big database, specifically the Fes. Definitely get the temp tables out of the FE. What you might want to do is create the temp db and temp table on-the-fly as you start a report. That way it is always started from scratch and no compact/repair is ever required. You can even move to using the "IN SOMEDATABASE" clause to allow accessing the data without having to create links to the temp Bes. The other thing you will want to do is a decompile / compile / compact / repair to shrink the FE size. If you haven't done that in awhile, you might be amazed how much it shrinks down. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Thursday, July 05, 2007 6:35 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De?: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy??: 5 juillet 2007 01:10 ??: Access Developers discussion and problem solving Objet?: Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running > in runtime mode) is slow. The number of concurrent user keep growing > over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > some pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database > would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free > and has a large capacity (more than enough for what I need). Will it > really help in speeding up the database? How hard is it to set up? > Any good documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > -- 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 Thu Jul 5 09:03:13 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 05 Jul 2007 10:03:13 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <002201c7be90$215364f0$6800a8c0@anniec> References: <002201c7be90$215364f0$6800a8c0@anniec> Message-ID: <013001c7bf0d$3adadb10$8abea8c0@XPS> Annie, Besides keeping a pointer open to the BE at all times, which John already mentioned: 1. Make sure that the MDB/MDEs are not being virus scanned on the clients and server. 2. If a NT/2000/2003 server is used to share the backend, consider turning off OPLOCKS (opportunistic locking). 3. Make sure the backend is only a level or two deep in the directory structure and access via a drive letter rather then UNC naming convention. I think everything else has already been mentioned. At the application level, Indexing of course is critical. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Wednesday, July 04, 2007 7:08 PM To: accessd at databaseadvisors.com Subject: [AccessD] Performance tips anyone? Hi all, I have a customer that complains about his database (BE/FE A97 running in runtime mode) is slow. The number of concurrent user keep growing over the years and it's up to 10 or 12 now. What I'm looking at right now is to optimize the whole database and upgrade to Access 2003. I've look at the performance tips from this page (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some pretty usefull information. Anyone has other tips on getting this database more performing? I was also wondering if using a dedicated server for the database would help to improve performance? And what about SQL Server 2005 Express? I've read here that it's free and has a large capacity (more than enough for what I need). Will it really help in speeding up the database? How hard is it to set up? Any good documentation I can read on this? Thanks to all of you! Annie Courchesne, CMA -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 09:09:14 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 10:09:14 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <013001c7bf0d$3adadb10$8abea8c0@XPS> Message-ID: <20070705140931.CD7D8BDC9@smtp-auth.no-ip.com> Wow, this thread needs to be distilled and placed up on our site as a "how to". There have been a lot of good suggestions here. I actually ran into the virus checker thing a few years back and spent an hour or two tracking it down, but did I remember that for this thread? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 10:03 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Annie, Besides keeping a pointer open to the BE at all times, which John already mentioned: 1. Make sure that the MDB/MDEs are not being virus scanned on the clients and server. 2. If a NT/2000/2003 server is used to share the backend, consider turning off OPLOCKS (opportunistic locking). 3. Make sure the backend is only a level or two deep in the directory structure and access via a drive letter rather then UNC naming convention. I think everything else has already been mentioned. At the application level, Indexing of course is critical. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Wednesday, July 04, 2007 7:08 PM To: accessd at databaseadvisors.com Subject: [AccessD] Performance tips anyone? Hi all, I have a customer that complains about his database (BE/FE A97 running in runtime mode) is slow. The number of concurrent user keep growing over the years and it's up to 10 or 12 now. What I'm looking at right now is to optimize the whole database and upgrade to Access 2003. I've look at the performance tips from this page (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some pretty usefull information. Anyone has other tips on getting this database more performing? I was also wondering if using a dedicated server for the database would help to improve performance? And what about SQL Server 2005 Express? I've read here that it's free and has a large capacity (more than enough for what I need). Will it really help in speeding up the database? How hard is it to set up? Any good documentation I can read on this? Thanks to all of you! Annie Courchesne, CMA -- 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 markamatte at hotmail.com Thu Jul 5 09:11:56 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 05 Jul 2007 14:11:56 +0000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Message-ID: I've been able to handle about 40(on a LAN)...lot of transactional stuff...but with more than 40 I seemed to end up with corruption every other day. I had about a 1 second screen transition. Mark A. Matte >From: "jwcolby" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 00:29:03 -0400 > >Anita, > > >I think that 10-12 users is the absolute maximum you will get out of an >Access database it will continue to get slower over the years as the >database grows. At some stage you would probably have to upgrade to SQL >server. > >Errrrr! Wrong answer. > >I have a database with 25 users in the database every day. The BE is >currently about 800 mbytes. This BE has tables with hundreds of thousands >of records in some tables, 30K-50K records in the main tables (claimant / >claim). I open a VERY complex tabbed form with about 20 tabs on it, with >subforms on each tab (JIT subforms). > >Users on fast machines open the form in about 1.2 seconds. Users on very >old slow machines take about 5 to 6 seconds. > >Speed of the individual workstation is the single largest determinate of >acceptable speed. A high speed processor and LOTS of memory (1 gig for >Windows XP Pro) are essential. Moving to a 1 gbit lan made a big >difference >as well (which requires a gigabit NIC in the machines as well). > >And of course all of the things you mentioned in terms of FE optimizations. > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith >Sent: Wednesday, July 04, 2007 9:00 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Performance tips anyone? > >Annie, >There are a number of things you can do to speed up an Access Database. I >haven't looked at the link you provided, but here are a few suggestions >based on my experience over the years: > >* Make sure your tables contain indexes on the fields frequently used for >criteria in queries >* Put the criteria on the ONE side of the relationship in queries >* Don't open forms and reports with large underlying recordsources. If >possible open the forms with only 1 underlying record - not a whole table. >* I have found that opening a form specifying the procedure arguments makes >it open faster > DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of > DoCmd.OpenForm "MyForm" > >Upgrading to A2003 probably won't make much difference. > >Using Runtime mode should not make it run any slower either. > >SQL server Express is a great option, but you would probably have to >rewrite >the form and report recordsources to really take advantage of it. It is not >hard to set up. I think there is an upgrade wizard that will upgrade an >Access Database to SQL Server. > >I think that 10-12 users is the absolute maximum you will get out of an >Access database it will continue to get slower over the years as the >database grows. At some stage you would probably have to upgrade to SQL >server. > >I hope this helps a bit. > >Anita > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 From markamatte at hotmail.com Thu Jul 5 09:21:41 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 05 Jul 2007 14:21:41 +0000 Subject: [AccessD] Performance tips anyone? In-Reply-To: <000a01c7bef0$330cbdd0$6800a8c0@anniec> Message-ID: Here in this office they have what they call a 'resource server'...basically a desktop...with a shared folder housing the BE. The DB is the only thing on this machine. The reason is that their public drive gets so much traffic...the db was taking a serious performance hit. So I have a copy of the FE on each machine...the BE on an isolated shared machine. Everytime they launch the FE...the FE is updated if updates are available...relinks the BE if necessary...and off we go. Mark A. Matte >From: "Annie Courchesne, CMA" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 06:35:26 -0400 > >Hi all, > >Wow, lots of great tips! > >Any thoughts about having a dedicated server for the BE db only? > >The BE db is 650mb with 200 tables. The largest table 1.5 millions >records. > > >The FE db is split in two db, one with the forms and one with the report. >The form db is 45mb with about 2000 objects. The report db is 14 mb with >about 1000 objects. The report db as to be compacted regularly since it's >using temp table and the size can grow to 500 mb depending of the report >printed. > >Thanks! > >Annie Courchesne, CMA > > >-----Message d'origine----- >De?: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel >Envoy??: 5 juillet 2007 01:10 >??: Access Developers discussion and problem solving >Objet?: Re: [AccessD] Performance tips anyone? > >Annie, > >If you have forms with lots of comboboxes, it certainly helps if you >don't populate them unless and until they are needed, i.e. set the Row >Source on their Enter event. > >Similarly, if you have forms with subforms on different pages of a tab >control, leave the Source Object of the subforms blanks, and only set it >if and when that tab is selected. > >And here's another thing I only found out about this week... the first >time a saved query is run after the database is compacted, will be slow, >because the query plan has to be re-created. So if you compact/repair >the front-end application file, queries will run slow the first time, >and forms based on queries will open slowly the first time. An argument >against 'Compact On Close' - but then, for memory, I don't think Comapct >On Close was available in Access 97. > >Regards >Steve > > >Annie Courchesne, CMA wrote: > > Hi all, > > > > > > > > I have a customer that complains about his database (BE/FE A97 running >in > > runtime mode) is slow. The number of concurrent user keep growing over >the > > years and it's up to 10 or 12 now. > > > > > > > > What I'm looking at right now is to optimize the whole database and >upgrade > > to Access 2003. I've look at the performance tips from this page > > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found some > > pretty usefull information. > > > > > > > > Anyone has other tips on getting this database more performing? > > > > > > > > I was also wondering if using a dedicated server for the database would >help > > to improve performance? > > > > > > > > And what about SQL Server 2005 Express? I've read here that it's free >and > > has a large capacity (more than enough for what I need). Will it really > > help in speeding up the database? How hard is it to set up? Any good > > documentation I can read on this? > > > > > > > > Thanks to all of you! > > > > > > > > > > > > Annie Courchesne, CMA > > > > > > >-- >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 _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 From jimdettman at verizon.net Thu Jul 5 09:25:22 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 05 Jul 2007 10:25:22 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <20070705042920.A1F8EBD9C@smtp-auth.no-ip.com> Message-ID: <001801c7bf10$534792d0$8abea8c0@XPS> Mark, You hit on a key point; with JET, and a well designed and written app, it's not performance that is an issue, but one of corruption. With a typical read/write app, by the time you get past 40 or so users, it's almost impossible to keep the environment stable enough to prevent corruptions from occurring. Case in point, years ago I was aware of one JET based reporting/ready only app that ran perfectly fine with 200+ users. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Thursday, July 05, 2007 10:12 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? I've been able to handle about 40(on a LAN)...lot of transactional stuff...but with more than 40 I seemed to end up with corruption every other day. I had about a 1 second screen transition. Mark A. Matte >From: "jwcolby" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 00:29:03 -0400 > >Anita, > > >I think that 10-12 users is the absolute maximum you will get out of an >Access database it will continue to get slower over the years as the >database grows. At some stage you would probably have to upgrade to SQL >server. > >Errrrr! Wrong answer. > >I have a database with 25 users in the database every day. The BE is >currently about 800 mbytes. This BE has tables with hundreds of thousands >of records in some tables, 30K-50K records in the main tables (claimant / >claim). I open a VERY complex tabbed form with about 20 tabs on it, with >subforms on each tab (JIT subforms). > >Users on fast machines open the form in about 1.2 seconds. Users on very >old slow machines take about 5 to 6 seconds. > >Speed of the individual workstation is the single largest determinate of >acceptable speed. A high speed processor and LOTS of memory (1 gig for >Windows XP Pro) are essential. Moving to a 1 gbit lan made a big >difference >as well (which requires a gigabit NIC in the machines as well). > >And of course all of the things you mentioned in terms of FE optimizations. > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith >Sent: Wednesday, July 04, 2007 9:00 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Performance tips anyone? > >Annie, >There are a number of things you can do to speed up an Access Database. I >haven't looked at the link you provided, but here are a few suggestions >based on my experience over the years: > >* Make sure your tables contain indexes on the fields frequently used for >criteria in queries >* Put the criteria on the ONE side of the relationship in queries >* Don't open forms and reports with large underlying recordsources. If >possible open the forms with only 1 underlying record - not a whole table. >* I have found that opening a form specifying the procedure arguments makes >it open faster > DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit instead of > DoCmd.OpenForm "MyForm" > >Upgrading to A2003 probably won't make much difference. > >Using Runtime mode should not make it run any slower either. > >SQL server Express is a great option, but you would probably have to >rewrite >the form and report recordsources to really take advantage of it. It is not >hard to set up. I think there is an upgrade wizard that will upgrade an >Access Database to SQL Server. > >I think that 10-12 users is the absolute maximum you will get out of an >Access database it will continue to get slower over the years as the >database grows. At some stage you would probably have to upgrade to SQL >server. > >I hope this helps a bit. > >Anita > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migratio n_HM_mini_2G_0507 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Thu Jul 5 09:34:46 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 05 Jul 2007 16:34:46 +0200 Subject: [AccessD] Performance tips anyone? Message-ID: Hi Mark We've had success too with this kind of a server loaded with Linux/Samba, either NAS-Lite or FreeNAS (discussed previously in several threads). /gustav >>> markamatte at hotmail.com 05-07-2007 16:21 >>> Here in this office they have what they call a 'resource server'...basically a desktop...with a shared folder housing the BE. The DB is the only thing on this machine. The reason is that their public drive gets so much traffic...the db was taking a serious performance hit. So I have a copy of the FE on each machine...the BE on an isolated shared machine. Everytime they launch the FE...the FE is updated if updates are available...relinks the BE if necessary...and off we go. Mark A. Matte From listmaster at databaseadvisors.com Thu Jul 5 10:23:11 2007 From: listmaster at databaseadvisors.com (Bryan Carbonnell) Date: Thu, 5 Jul 2007 11:23:11 -0400 Subject: [AccessD] FW: Performance tips anyone? In-Reply-To: <20070705132822.AF216BF04@smtp-auth.no-ip.com> References: <20070705132822.AF216BF04@smtp-auth.no-ip.com> Message-ID: On 7/5/07, jwcolby wrote: > Can our list manager help Thomas figure out why he gets bounce messages. > His messages are getting through but he is being told they aren't. Thomas, Contact me off list and I'll work on this with you. -- Bryan Carbonnell - listmaster at databaseadvisors.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From DWUTKA at Marlow.com Thu Jul 5 10:47:41 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 10:47:41 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Brave? I have a database with ~80, and it's predecessor used to handle ~125 users. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Wednesday, July 04, 2007 11:57 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 10:51:47 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 10:51:47 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705054251.62982BD59@smtp-auth.no-ip.com> Message-ID: It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwcolby at colbyconsulting.com Thu Jul 5 10:54:08 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 11:54:08 -0400 Subject: [AccessD] FW: Performance tips anyone? In-Reply-To: Message-ID: <20070705155426.AA3C7BF4B@smtp-auth.no-ip.com> Bryan, I don't think he is seeing his posts to the list, (he is getting bounce notices) so it is doubtful that he is seeing YOUR posts to the list either, although that might not be true. Anyway, I think you need to contact him directly. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bryan Carbonnell Sent: Thursday, July 05, 2007 11:23 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] FW: Performance tips anyone? On 7/5/07, jwcolby wrote: > Can our list manager help Thomas figure out why he gets bounce messages. > His messages are getting through but he is being told they aren't. Thomas, Contact me off list and I'll work on this with you. -- Bryan Carbonnell - listmaster at databaseadvisors.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Thu Jul 5 11:12:44 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 09:12:44 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <0JKP008WWRHA2JB0@l-daemon> Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From developer at ultradnt.com Thu Jul 5 11:21:19 2007 From: developer at ultradnt.com (Steve Conklin) Date: Thu, 5 Jul 2007 12:21:19 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <468C7AB0.8090900@mvps.org> References: <002201c7be90$215364f0$6800a8c0@anniec><000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> <468C7AB0.8090900@mvps.org> Message-ID: <001401c7bf20$89329240$0764a8c0@ULTRADNT> Steve: I have made this change in production apps, and have seen the time drop from minutes to seconds. Steve -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Thursday, July 05, 2007 12:59 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Sorry to be contrary, Steve, but I don't think this is supported by the evidence. In fact, I believe DoCmd.OpenQuery would perform faster if you are running a saved query, as long as the number of records hasn't changed dramatically since the last time it was run. But either way, I think this is possibly academic interest only, as the speed differences here are likely to be imperceptible. Regards Steve Steve Conklin wrote: > Replace any DoCmd.RunSQL's with CurrentDB.execute. > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 5 11:30:15 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 12:30:15 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <0JKP008WWRHA2JB0@l-daemon> Message-ID: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 Jim.Hale at FleetPride.com Thu Jul 5 11:41:15 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 5 Jul 2007 11:41:15 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <000a01c7bef0$330cbdd0$6800a8c0@anniec> References: <002201c7be90$215364f0$6800a8c0@anniec> <468C7D11.9050201@mvps.org> <000a01c7bef0$330cbdd0$6800a8c0@anniec> Message-ID: Is your network local, ie. the backend is on a server with a fast connection? No one has mentioned this but my experience has been anything outside the local office connecting to a backend on our network is unacceptably slow (I believe we have dedicated T1s, I'll find out from the notwork guy). Connecting through a VPN connection over the net is unacceptable for us even with broadband. My backends range from 100mg-400mg. Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Annie Courchesne, CMA Sent: Thursday, July 05, 2007 5:35 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Hi all, Wow, lots of great tips! Any thoughts about having a dedicated server for the BE db only? The BE db is 650mb with 200 tables. The largest table 1.5 millions records. The FE db is split in two db, one with the forms and one with the report. The form db is 45mb with about 2000 objects. The report db is 14 mb with about 1000 objects. The report db as to be compacted regularly since it's using temp table and the size can grow to 500 mb depending of the report printed. Thanks! Annie Courchesne, CMA -----Message d'origine----- De?: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] De la part de Steve Schapel Envoy??: 5 juillet 2007 01:10 ??: Access Developers discussion and problem solving Objet?: Re: [AccessD] Performance tips anyone? Annie, If you have forms with lots of comboboxes, it certainly helps if you don't populate them unless and until they are needed, i.e. set the Row Source on their Enter event. Similarly, if you have forms with subforms on different pages of a tab control, leave the Source Object of the subforms blanks, and only set it if and when that tab is selected. And here's another thing I only found out about this week... the first time a saved query is run after the database is compacted, will be slow, because the query plan has to be re-created. So if you compact/repair the front-end application file, queries will run slow the first time, and forms based on queries will open slowly the first time. An argument against 'Compact On Close' - but then, for memory, I don't think Comapct On Close was available in Access 97. Regards Steve Annie Courchesne, CMA wrote: > Hi all, > > > > I have a customer that complains about his database (BE/FE A97 running > in runtime mode) is slow. The number of concurrent user keep growing > over the > years and it's up to 10 or 12 now. > > > > What I'm looking at right now is to optimize the whole database and upgrade > to Access 2003. I've look at the performance tips from this page > (http://www.granite.ab.ca/access/performancefaq.htm) and I've found > some pretty usefull information. > > > > Anyone has other tips on getting this database more performing? > > > > I was also wondering if using a dedicated server for the database > would help > to improve performance? > > > > And what about SQL Server 2005 Express? I've read here that it's free > and has a large capacity (more than enough for what I need). Will it > really help in speeding up the database? How hard is it to set up? > Any good documentation I can read on this? > > > > Thanks to all of you! > > > > > > Annie Courchesne, CMA > > > -- 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From accessd at shaw.ca Thu Jul 5 11:55:40 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 09:55:40 -0700 Subject: [AccessD] Global Tracking Security chips In-Reply-To: Message-ID: <0JKP007CMTGXLVM2@l-daemon> Hi All: Has anyone heard of or used Global Tracking Security chips? A potential client is asking about information on this as they will be putting on an art show where there are many irreplaceable pieces that will be displayed. MTIA Jim From cfoust at infostatsystems.com Thu Jul 5 11:52:00 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 09:52:00 -0700 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: <003201c7bdfb$dea71000$6402a8c0@ScuzzPaq> References: <007801c7bdf6$36aed360$7c58a27a@pcadt> <003201c7bdfb$dea71000$6402a8c0@ScuzzPaq> Message-ID: My congratulations as well, Marty. Well done and well deserved!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Tuesday, July 03, 2007 11:44 PM To: Access Developers discussion and problem solving Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP It is my pleasure to announce that Marty Connelly has joined the family of Access MVP's. My heartiest congratulations Marty! The recognition accorded to you is richly deserved and was keenly anticipated. We are all delighted. Your contributions to various forums carry such a wealth of information that most of your posts qualify for inclusion in a collection meant for ready reference. Best wishes, A.D.Tejpal --------------- From cfoust at infostatsystems.com Thu Jul 5 11:55:39 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 09:55:39 -0700 Subject: [AccessD] Omission of Me In-Reply-To: <000001c7be66$3ede82e0$06b62ad1@SusanOne> References: <000001c7be66$3ede82e0$06b62ad1@SusanOne> Message-ID: What do you mean by "dropped the need for"? The Me and the other forms of identifiers tell the database engine what it's dealing with so that intellisense is available and syntax checking knows enough to blow up on a misspelling or squawk if the Option Explicit is set on. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 04, 2007 11:08 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Omission of Me Does anyone remember what version of Access dropped the need for Me or the Forms.formname identifiers when the form (or report) is current? I think it was XP, but I really don't remember. It seems like it's been around for a really long time, so maybe it was 2000? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Thu Jul 5 12:12:24 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 10:12:24 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> Message-ID: <0JKP00LIVU8Q9590@l-daemon> Hi John: You are right about newbies learning how to use 'unbound'. For my part, my experience extends from before Access when 'unbound' was the only way... but Access has been for many years the best presentation and reporting tool around... bar none. The Visual Studio (.Net) versions are replacing this and with the new Reporting features in all MS SQL versions we have moved full-circle back to 'unbound' world. In this new environment newbies will have to learn to use 'unbound'. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 cfoust at infostatsystems.com Thu Jul 5 12:08:48 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 10:08:48 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> References: <0JKP008WWRHA2JB0@l-daemon> <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> Message-ID: I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 DWUTKA at Marlow.com Thu Jul 5 12:13:41 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 12:13:41 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <0JKP008WWRHA2JB0@l-daemon> Message-ID: Heavy user performance is keyed to being unbound. I will concede that with a low number of users (30 or less) bound still has a lot of advantages. Then again, I don't write Access interfaces very often, most of my stuff is VB or ASP for a front end. (Wrote a Data Class builder for VB 6. Point it at a database, select a table, and it builds a single data class and collection data class for me. Makes VB interfaces even easier). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 11:13 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 12:15:33 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 12:15:33 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> Message-ID: But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From cfoust at infostatsystems.com Thu Jul 5 12:14:57 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 10:14:57 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <0JKP00LIVU8Q9590@l-daemon> References: <20070705163033.CEED1BF7C@smtp-auth.no-ip.com> <0JKP00LIVU8Q9590@l-daemon> Message-ID: Not necessarily, or at least, not in the same way. The forms and reports in .Net can be bound to a dataset with ease, it's the data that is largely unbound or at least bound JIT. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 10:12 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Hi John: You are right about newbies learning how to use 'unbound'. For my part, my experience extends from before Access when 'unbound' was the only way... but Access has been for many years the best presentation and reporting tool around... bar none. The Visual Studio (.Net) versions are replacing this and with the new Reporting features in all MS SQL versions we have moved full-circle back to 'unbound' world. In this new environment newbies will have to learn to use 'unbound'. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 jwcolby at colbyconsulting.com Thu Jul 5 12:22:41 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 13:22:41 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705172259.4A273BF60@smtp-auth.no-ip.com> Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 DWUTKA at Marlow.com Thu Jul 5 12:28:45 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 12:28:45 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705172259.4A273BF60@smtp-auth.no-ip.com> Message-ID: I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwcolby at colbyconsulting.com Thu Jul 5 12:32:08 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 13:32:08 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim From cfoust at infostatsystems.com Thu Jul 5 12:38:11 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 10:38:11 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705172259.4A273BF60@smtp-auth.no-ip.com> References: <20070705172259.4A273BF60@smtp-auth.no-ip.com> Message-ID: Well, if the shoe fits .... LOL No, John, I'm saying that newcomers to Access shouldn't just use the paint by numbers approach. Since Access is being positioned for power users rather than developers, my remarks were directed toward said users. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:23 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with >unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 cfoust at infostatsystems.com Thu Jul 5 12:40:48 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 10:40:48 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705173226.C6086BF69@smtp-auth.no-ip.com> References: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Message-ID: Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From reuben at gfconsultants.com Thu Jul 5 12:44:27 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Thu, 5 Jul 2007 13:44:27 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Message-ID: Damn, who brought up bound vs unbound again? They need taken out back and beatin. Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 05, 2007 1:32 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > > Drew, > > >But Access is just as well suited for unbound solutions too. > > Just as well suited as what? Access is NOT as well suited for > unbound as it > is for bound. Access just has TONS of features in it directly > dependent on > bound forms and controls. Unbounders throw all that stuff away; > To try and > implement that stuff in an unbound solution requires a LOT of custom code. > AFAICT most Access "unbounders" make no effort to recreate most of what > Access just "gives" us bounders. > > And Access is certainly NOT as well suited for unbound as VB.Net > (or even VB > 6), not that I am an expert in .Net yet. But you are talking a > whole nother > ball game when you talk .Net. > > So as much as I love ya, I have to disagree with that one. I > think you are > one of the "been doing Access unbound so long you forgot the pain" folk. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > Sent: Thursday, July 05, 2007 1:16 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Performance tips anyone? > > But Access is just as well suited for unbound solutions too. The only > exception to that rule is it's goofiness with callback routines. (Can't go > into debug if you have a callback routine ANYWHERE. Goes haywire). > > Drew > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, July 05, 2007 11:30 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > Jim, > > >You mentioning this will not cause near the stir as it did 10 years ago > as > most (all?) have now accepted the reality. ;-) > > LOL, no not quite. Access is a tool built from the ground up for bound. > To > even discuss unbound for Access NOW, when much more robust > unbound tools are > available is ... well... kinda silly. Unless of course you have > been doing > unbound with Access for the last 10 years in which case you have the > expertise to do so. Telling the average Access nubee to use > Access unbound > is IMHO a disservice to the nubee. He might as well just go learn VB.Net. > > As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am > not an Access nubee). > > The right tool for the job so to speak. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence > Sent: Thursday, July 05, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > Yes, Drew you have hit on the key to performance... 'unbound'. > > You mentioning this will not cause near the stir as it did 10 years ago as > most (all?) have now accepted the reality. ;-) > > Jim > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From ssharkins at setel.com Thu Jul 5 12:58:32 2007 From: ssharkins at setel.com (Susan Harkins) Date: Thu, 5 Jul 2007 13:58:32 -0400 Subject: [AccessD] Omission of Me In-Reply-To: References: <000001c7be66$3ede82e0$06b62ad1@SusanOne> Message-ID: <007601c7bf2e$1b00b320$1c32fad1@SusanOne> I always use Me because I don't know what version readers are using. It seems to me that its possible to drop Me in certain cases. If IsNull(cboSubject) Then MsgBox "Please select a subject", vbOKOnly, "Error" Exit Sub End If The above's the only thing I can come up with -- in older versions, wasn't the Me identifier required before the control, as in the following: If IsNull(Me.cboSubject) Then Or, am I just making stuff up again? Susan H. What do you mean by "dropped the need for"? The Me and the other forms of identifiers tell the database engine what it's dealing with so that intellisense is available and syntax checking knows enough to blow up on a misspelling or squawk if the Option Explicit is set on. Charlotte Foust From jwcolby at colbyconsulting.com Thu Jul 5 13:53:41 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 14:53:41 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Thu Jul 5 14:00:27 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 05 Jul 2007 15:00:27 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Message-ID: <006601c7bf36$c0cce0a0$8abea8c0@XPS> Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 Jul 5 14:02:01 2007 From: davidmcafee at gmail.com (David McAfee) Date: Thu, 5 Jul 2007 12:02:01 -0700 Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP In-Reply-To: References: <007801c7bdf6$36aed360$7c58a27a@pcadt> <003201c7bdfb$dea71000$6402a8c0@ScuzzPaq> Message-ID: <8786a4c00707051202p77962928w79735d64aced0e5c@mail.gmail.com> Congratulations Marty, much deserved! > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL > Sent: Tuesday, July 03, 2007 11:44 PM > To: Access Developers discussion and problem solving > Subject: [AccessD] Congratulations Marty Connelly - New MS Access MVP > > It is my pleasure to announce that Marty Connelly has joined the > family of Access MVP's. > > My heartiest congratulations Marty! The recognition accorded to you > is richly deserved and was keenly anticipated. We are all delighted. > > Your contributions to various forums carry such a wealth of > information that most of your posts qualify for inclusion in a > collection meant for ready reference. > > Best wishes, > A.D.Tejpal > From jwcolby at colbyconsulting.com Thu Jul 5 14:06:16 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 5 Jul 2007 15:06:16 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070705190634.6DE42BCB7@smtp-auth.no-ip.com> I never said anything about hard to use unbound, I said suited to unbound. It plainly is NOT. Access is designed from the ground for bound. It is like taking a Mercedes and yanking the engine out, taking a cutting torch to the frame and trying to stuff a Chevy v8 in it, then splice in all other systems. Yea, it can be done, but it is not "well suited" for that. ANY unbound is harder than bound (regardless of the engine), because you are doing all of the work that the built in "bound code" does for you automatically. You know that Charlotte, you just like to argue. I (bound) do not have to do any locking, etc. You do. And there are TONS of other things that come with the bounded-ness that you either do not provide, or code in all over again. In my personal opinion, it IS hard to use unbound for exactly those reasons. If I wanted to write code to replace the Access bound engine I would not use the Access bound engine!!! At least not if I were starting a project today, July 2007. And of course I do count you in with Drew. Those who have done it so long they forgot the pain. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 Jim.Hale at FleetPride.com Thu Jul 5 14:34:05 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 5 Jul 2007 14:34:05 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <006601c7bf36$c0cce0a0$8abea8c0@XPS> References: <20070705173226.C6086BF69@smtp-auth.no-ip.com> <006601c7bf36$c0cce0a0$8abea8c0@XPS> Message-ID: < You just have to write the same code you would have to write in *any* language to work with unbound objects.> That may be true but I have to side with John also. Many of the users who initially have the timidity to try Access haven't ever coded in *any* other language. The initial learning curve for power user newbies is hard enough without having to worry about unbound concepts. Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 2:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From DWUTKA at Marlow.com Thu Jul 5 14:54:58 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 14:54:58 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705173226.C6086BF69@smtp-auth.no-ip.com> Message-ID: I've only played around in .Net. Have not really found a use for it yet. Not that it's a bad language or system, it's just that everything I do already has the VB runtimes, and I have so much VB code that I just am sticking with VB 6 for now. So I can't debate what VB.Net can and can't do. As far as Access goes, I haven't been doing Access unbound very often. I usually just use Access as the db. But as far as Access Front Ends go, I'll through in a form or report when I need it for small projects, but if I am going to be building a full blown access front end, I usually am making it unbound, mainly due to limitations on bound objects. Let me explain, most of the Access FE work is stuff I'm doing as side work. At the moment, I only have one person asking for that, and he can do a lot in Access already. So I get the projects that are a little more then 'cookie cutter' style. For instance, the last big one I built was an inventory system. Some of what they needed to do went beyond what bound can do naturally. So instead of trying to cram the bound 'mold' into what they wanted to do, I built the business logic into Class modules. Everything tied in together, so when something was update in one place, the events alerted every affected process. By it's very nature, this type of business layer has to be unbound (because a bound form leaves the business logic out). My point in this, is that it depends on the project goals. Of course, as we all know, our work is a lot like art. Everyone has their own styles and preferred tools. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:32 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 14:56:01 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 14:56:01 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: I think it was JWC. (oh look at that big stick over there, how did that get there?) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Reuben Cummings Sent: Thursday, July 05, 2007 12:44 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Damn, who brought up bound vs unbound again? They need taken out back and beatin. Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 05, 2007 1:32 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > > Drew, > > >But Access is just as well suited for unbound solutions too. > > Just as well suited as what? Access is NOT as well suited for > unbound as it > is for bound. Access just has TONS of features in it directly > dependent on > bound forms and controls. Unbounders throw all that stuff away; > To try and > implement that stuff in an unbound solution requires a LOT of custom code. > AFAICT most Access "unbounders" make no effort to recreate most of what > Access just "gives" us bounders. > > And Access is certainly NOT as well suited for unbound as VB.Net > (or even VB > 6), not that I am an expert in .Net yet. But you are talking a > whole nother > ball game when you talk .Net. > > So as much as I love ya, I have to disagree with that one. I > think you are > one of the "been doing Access unbound so long you forgot the pain" folk. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > Sent: Thursday, July 05, 2007 1:16 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Performance tips anyone? > > But Access is just as well suited for unbound solutions too. The only > exception to that rule is it's goofiness with callback routines. (Can't go > into debug if you have a callback routine ANYWHERE. Goes haywire). > > Drew > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, July 05, 2007 11:30 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > Jim, > > >You mentioning this will not cause near the stir as it did 10 years ago > as > most (all?) have now accepted the reality. ;-) > > LOL, no not quite. Access is a tool built from the ground up for bound. > To > even discuss unbound for Access NOW, when much more robust > unbound tools are > available is ... well... kinda silly. Unless of course you have > been doing > unbound with Access for the last 10 years in which case you have the > expertise to do so. Telling the average Access nubee to use > Access unbound > is IMHO a disservice to the nubee. He might as well just go learn VB.Net. > > As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am > not an Access nubee). > > The right tool for the job so to speak. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence > Sent: Thursday, July 05, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Performance tips anyone? > > Yes, Drew you have hit on the key to performance... 'unbound'. > > You mentioning this will not cause near the stir as it did 10 years ago as > most (all?) have now accepted the reality. ;-) > > Jim > > > -- > 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 14:57:45 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 14:57:45 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> Message-ID: Watch out, you've never tried my cookies..... they stay soft and gooey for days, a touch of extra molasses, with maple syrup in them (REAL maple syrup), and loaded with chocolate chunks. Faster isn't always better.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 1:54 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 15:02:52 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 15:02:52 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <006601c7bf36$c0cce0a0$8abea8c0@XPS> Message-ID: If the tabs in the database window stopped at forms, I would almost agree. However, access has a WONDERFUL reporting capability. I have written a handful of 'unbound' reports, but only a handful. Every other report I have written is as bound as they come. As I just explained in my last post, the advantage of creating an unbound interface is the control. With reporting, you are just allowing data to be viewed (nothing is being modified), so the need for control isn't there. Reports aside, however, there are other reasons to use Access unbound. The end users want the Access interface is a big one. Please keep in mind, this debate isn't about which is better. Building bound Access apps is great. Access excels at it. This debate is about the validity of creating unbound Access apps...which Access also does quite well with. Hard to prove it's not valid when several good examples have been given why it is valid. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 2:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From carbonnb at gmail.com Thu Jul 5 15:03:44 2007 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Thu, 5 Jul 2007 16:03:44 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> Message-ID: On 7/5/07, Drew Wutka wrote: > Watch out, you've never tried my cookies..... they stay soft and gooey You're right. I haven't. Hint. Hint. > Faster isn't always better.... ;) Yea, but waiting years...... C'Mon. I'm going to have to send my new address. Oops. this should be over on OT :) -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From cfoust at infostatsystems.com Thu Jul 5 15:03:11 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 13:03:11 -0700 Subject: [AccessD] Omission of Me In-Reply-To: <007601c7bf2e$1b00b320$1c32fad1@SusanOne> References: <000001c7be66$3ede82e0$06b62ad1@SusanOne> <007601c7bf2e$1b00b320$1c32fad1@SusanOne> Message-ID: I don't recall it being absolutely required in any of VBA versions, but I could be wrong about A95. In theory, there's a penalty for not using it because the application has to figure out whether you're referring to a control, a field or a variable on the fly, which means if you don't have option explicit set on, it will assume any misspelling is a new variable. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Thursday, July 05, 2007 10:59 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Omission of Me I always use Me because I don't know what version readers are using. It seems to me that its possible to drop Me in certain cases. If IsNull(cboSubject) Then MsgBox "Please select a subject", vbOKOnly, "Error" Exit Sub End If The above's the only thing I can come up with -- in older versions, wasn't the Me identifier required before the control, as in the following: If IsNull(Me.cboSubject) Then Or, am I just making stuff up again? Susan H. What do you mean by "dropped the need for"? The Me and the other forms of identifiers tell the database engine what it's dealing with so that intellisense is available and syntax checking knows enough to blow up on a misspelling or squawk if the Option Explicit is set on. Charlotte Foust -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From DWUTKA at Marlow.com Thu Jul 5 15:05:30 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 15:05:30 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705190634.6DE42BCB7@smtp-auth.no-ip.com> Message-ID: Huh? You've stepped backwards quite a bit on this ol' buddy. Bound and unbound handle data transfers the exact same way, they are using Jet. There is no need to put in extra locks. In fact, that's one of the main reasons I will go unbound with an app, is if I need to avoid some of the issues involved with a bound application. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 2:06 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? I never said anything about hard to use unbound, I said suited to unbound. It plainly is NOT. Access is designed from the ground for bound. It is like taking a Mercedes and yanking the engine out, taking a cutting torch to the frame and trying to stuff a Chevy v8 in it, then splice in all other systems. Yea, it can be done, but it is not "well suited" for that. ANY unbound is harder than bound (regardless of the engine), because you are doing all of the work that the built in "bound code" does for you automatically. You know that Charlotte, you just like to argue. I (bound) do not have to do any locking, etc. You do. And there are TONS of other things that come with the bounded-ness that you either do not provide, or code in all over again. In my personal opinion, it IS hard to use unbound for exactly those reasons. If I wanted to write code to replace the Access bound engine I would not use the Access bound engine!!! At least not if I were starting a project today, July 2007. And of course I do count you in with Drew. Those who have done it so long they forgot the pain. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From miscellany at mvps.org Thu Jul 5 15:05:46 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 06 Jul 2007 08:05:46 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: Message-ID: <468D4F1A.6050707@mvps.org> Annie, Some good information on this topic at http://www.granite.ab.ca/access/temptables.htm Regards Steve Annie Courchesne, CMA wrote: > > The temp tables are on the local machine also, but I never thought to have > those table put in a completely seperated db and to recreate them at start > up... I'll have to look this up. From cfoust at infostatsystems.com Thu Jul 5 15:04:17 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 13:04:17 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <006601c7bf36$c0cce0a0$8abea8c0@XPS> References: <20070705173226.C6086BF69@smtp-auth.no-ip.com> <006601c7bf36$c0cce0a0$8abea8c0@XPS> Message-ID: But there used to be no really good alternative, pre .Net days. Why wouldn't you have used it unbound? Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 12:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 DWUTKA at Marlow.com Thu Jul 5 15:07:59 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 15:07:59 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Well that's very true. A newbie developer is going to use bound concepts from the get go. I, for example, worked with Access for a few months before I was forced to use code to do a few things (that very first task was to hide the Access window...can't do it without code). I continued to use bound stuff until I got into classes and collections. That changed the whole spectrum. Hey, who was it, on this list, that I sent a copy of the Inventory Database I built. Whoever it was, pop in here and tell me if you could build those capabilities into a strictly bound application. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim Sent: Thursday, July 05, 2007 2:34 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? < You just have to write the same code you would have to write in *any* language to work with unbound objects.> That may be true but I have to side with John also. Many of the users who initially have the timidity to try Access haven't ever coded in *any* other language. The initial learning curve for power user newbies is hard enough without having to worry about unbound concepts. Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 05, 2007 2:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, I side with John on this one. If your going to use Access unbound, you might as well not bother. Jim. *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Thu Jul 5 15:09:01 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 15:09:01 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Believe it or not, I have not forgotten about that, Stephen shouldn't have offered his to Alan, that's why I've been dragging my feet. ;) Send me your new address offline, I'll sneak some too ya! Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bryan Carbonnell Sent: Thursday, July 05, 2007 3:04 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? On 7/5/07, Drew Wutka wrote: > Watch out, you've never tried my cookies..... they stay soft and gooey You're right. I haven't. Hint. Hint. > Faster isn't always better.... ;) Yea, but waiting years...... C'Mon. I'm going to have to send my new address. Oops. this should be over on OT :) -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From cfoust at infostatsystems.com Thu Jul 5 15:07:49 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 5 Jul 2007 13:07:49 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705190634.6DE42BCB7@smtp-auth.no-ip.com> References: <20070705190634.6DE42BCB7@smtp-auth.no-ip.com> Message-ID: >> You know that Charlotte, you just like to argue. MOI?? Not true!! That's a case of the pot calling the kettle black! And what does "suited" mean anyhow? Once ADO came into the picture, Access was suited to unbound objects, including data objects. By your logic, all .Net forms and reports would use their built in connection strings to access data because it designed in. In fact, the flexibility of .Net lies in NOT using all the "built-in" stuff. Same like Access. ;-> Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:06 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? I never said anything about hard to use unbound, I said suited to unbound. It plainly is NOT. Access is designed from the ground for bound. It is like taking a Mercedes and yanking the engine out, taking a cutting torch to the frame and trying to stuff a Chevy v8 in it, then splice in all other systems. Yea, it can be done, but it is not "well suited" for that. ANY unbound is harder than bound (regardless of the engine), because you are doing all of the work that the built in "bound code" does for you automatically. You know that Charlotte, you just like to argue. I (bound) do not have to do any locking, etc. You do. And there are TONS of other things that come with the bounded-ness that you either do not provide, or code in all over again. In my personal opinion, it IS hard to use unbound for exactly those reasons. If I wanted to write code to replace the Access bound engine I would not use the Access bound engine!!! At least not if I were starting a project today, July 2007. And of course I do count you in with Drew. Those who have done it so long they forgot the pain. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? Hey, count me in that group with Drew, John. Access isn't hard to use unbound. You just have to write the same code you would have to write in *any* language to work with unbound objects. The freedom is certainly worth the sacrifice of the bound uh ... "boundaries". Your problem is that it doesn't play nicely with your framework!! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Drew, >But Access is just as well suited for unbound solutions too. Just as well suited as what? Access is NOT as well suited for unbound as it is for bound. Access just has TONS of features in it directly dependent on bound forms and controls. Unbounders throw all that stuff away; To try and implement that stuff in an unbound solution requires a LOT of custom code. AFAICT most Access "unbounders" make no effort to recreate most of what Access just "gives" us bounders. And Access is certainly NOT as well suited for unbound as VB.Net (or even VB 6), not that I am an expert in .Net yet. But you are talking a whole nother ball game when you talk .Net. So as much as I love ya, I have to disagree with that one. I think you are one of the "been doing Access unbound so long you forgot the pain" folk. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? But Access is just as well suited for unbound solutions too. The only exception to that rule is it's goofiness with callback routines. (Can't go into debug if you have a callback routine ANYWHERE. Goes haywire). Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -- 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 markamatte at hotmail.com Thu Jul 5 16:05:02 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 05 Jul 2007 21:05:02 +0000 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Actually...You 'kinda' brought it up Drew...but Jim L ran with it!!!...lol Mark Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew >From: "Drew Wutka" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 14:56:01 -0500 > >I think it was JWC. (oh look at that big stick over there, how did that >get there?) > >Drew > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Reuben >Cummings >Sent: Thursday, July 05, 2007 12:44 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Performance tips anyone? > >Damn, who brought up bound vs unbound again? They need taken out back >and >beatin. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > > Sent: Thursday, July 05, 2007 1:32 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > > > Drew, > > > > >But Access is just as well suited for unbound solutions too. > > > > Just as well suited as what? Access is NOT as well suited for > > unbound as it > > is for bound. Access just has TONS of features in it directly > > dependent on > > bound forms and controls. Unbounders throw all that stuff away; > > To try and > > implement that stuff in an unbound solution requires a LOT of custom >code. > > AFAICT most Access "unbounders" make no effort to recreate most of >what > > Access just "gives" us bounders. > > > > And Access is certainly NOT as well suited for unbound as VB.Net > > (or even VB > > 6), not that I am an expert in .Net yet. But you are talking a > > whole nother > > ball game when you talk .Net. > > > > So as much as I love ya, I have to disagree with that one. I > > think you are > > one of the "been doing Access unbound so long you forgot the pain" >folk. > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > > Sent: Thursday, July 05, 2007 1:16 PM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] Performance tips anyone? > > > > But Access is just as well suited for unbound solutions too. The only > > exception to that rule is it's goofiness with callback routines. >(Can't go > > into debug if you have a callback routine ANYWHERE. Goes haywire). > > > > Drew > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > > Sent: Thursday, July 05, 2007 11:30 AM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > Jim, > > > > >You mentioning this will not cause near the stir as it did 10 years >ago > > as > > most (all?) have now accepted the reality. ;-) > > > > LOL, no not quite. Access is a tool built from the ground up for >bound. > > To > > even discuss unbound for Access NOW, when much more robust > > unbound tools are > > available is ... well... kinda silly. Unless of course you have > > been doing > > unbound with Access for the last 10 years in which case you have the > > expertise to do so. Telling the average Access nubee to use > > Access unbound > > is IMHO a disservice to the nubee. He might as well just go learn >VB.Net. > > > > As for me, if I need unbound it will be in VB.Net, NOT in Access (and >I am > > not an Access nubee). > > > > The right tool for the job so to speak. > > > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim >Lawrence > > Sent: Thursday, July 05, 2007 12:13 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > Yes, Drew you have hit on the key to performance... 'unbound'. > > > > You mentioning this will not cause near the stir as it did 10 years >ago as > > most (all?) have now accepted the reality. ;-) > > > > Jim > > > > > > -- > > 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 >The information contained in this transmission is intended only for the >person or entity to which it is addressed and may contain II-VI Proprietary >and/or II-VI BusinessSensitve material. If you are not the intended >recipient, please contact the sender immediately and destroy the material >in its entirety, whether electronic or hard copy. You are notified that any >review, retransmission, copying, disclosure, dissemination, or other use >of, or taking of any action in reliance upon this information by persons or >entities other than the intended recipient is prohibited. > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01 From DWUTKA at Marlow.com Thu Jul 5 16:24:50 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 5 Jul 2007 16:24:50 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Oh my, where did that stick go, it was just there a minute ago!!! Your honor, I would like to plead the 5th! And while we're at it, I have a constitutional right to face my accuser, so since this is an email list, you'll have to come to Dallas if you want to charge me with inciting another bound/unbound debate, or, more grammatically correct, for slamming on the cookie cutting bounders. ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Thursday, July 05, 2007 4:05 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? Actually...You 'kinda' brought it up Drew...but Jim L ran with it!!!...lol Mark Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew >From: "Drew Wutka" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Performance tips anyone? >Date: Thu, 5 Jul 2007 14:56:01 -0500 > >I think it was JWC. (oh look at that big stick over there, how did that >get there?) > >Drew > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Reuben >Cummings >Sent: Thursday, July 05, 2007 12:44 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Performance tips anyone? > >Damn, who brought up bound vs unbound again? They need taken out back >and >beatin. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > > Sent: Thursday, July 05, 2007 1:32 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > > > Drew, > > > > >But Access is just as well suited for unbound solutions too. > > > > Just as well suited as what? Access is NOT as well suited for > > unbound as it > > is for bound. Access just has TONS of features in it directly > > dependent on > > bound forms and controls. Unbounders throw all that stuff away; > > To try and > > implement that stuff in an unbound solution requires a LOT of custom >code. > > AFAICT most Access "unbounders" make no effort to recreate most of >what > > Access just "gives" us bounders. > > > > And Access is certainly NOT as well suited for unbound as VB.Net > > (or even VB > > 6), not that I am an expert in .Net yet. But you are talking a > > whole nother > > ball game when you talk .Net. > > > > So as much as I love ya, I have to disagree with that one. I > > think you are > > one of the "been doing Access unbound so long you forgot the pain" >folk. > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > > Sent: Thursday, July 05, 2007 1:16 PM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] Performance tips anyone? > > > > But Access is just as well suited for unbound solutions too. The only > > exception to that rule is it's goofiness with callback routines. >(Can't go > > into debug if you have a callback routine ANYWHERE. Goes haywire). > > > > Drew > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > > Sent: Thursday, July 05, 2007 11:30 AM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > Jim, > > > > >You mentioning this will not cause near the stir as it did 10 years >ago > > as > > most (all?) have now accepted the reality. ;-) > > > > LOL, no not quite. Access is a tool built from the ground up for >bound. > > To > > even discuss unbound for Access NOW, when much more robust > > unbound tools are > > available is ... well... kinda silly. Unless of course you have > > been doing > > unbound with Access for the last 10 years in which case you have the > > expertise to do so. Telling the average Access nubee to use > > Access unbound > > is IMHO a disservice to the nubee. He might as well just go learn >VB.Net. > > > > As for me, if I need unbound it will be in VB.Net, NOT in Access (and >I am > > not an Access nubee). > > > > The right tool for the job so to speak. > > > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim >Lawrence > > Sent: Thursday, July 05, 2007 12:13 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Performance tips anyone? > > > > Yes, Drew you have hit on the key to performance... 'unbound'. > > > > You mentioning this will not cause near the stir as it did 10 years >ago as > > most (all?) have now accepted the reality. ;-) > > > > Jim > > > > > > -- > > 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 >The information contained in this transmission is intended only for the >person or entity to which it is addressed and may contain II-VI Proprietary >and/or II-VI BusinessSensitve material. If you are not the intended >recipient, please contact the sender immediately and destroy the material >in its entirety, whether electronic or hard copy. You are notified that any >review, retransmission, copying, disclosure, dissemination, or other use >of, or taking of any action in reliance upon this information by persons or >entities other than the intended recipient is prohibited. > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From miscellany at mvps.org Thu Jul 5 17:01:56 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 06 Jul 2007 10:01:56 +1200 Subject: [AccessD] Performance tips anyone? In-Reply-To: <001401c7bf20$89329240$0764a8c0@ULTRADNT> References: <002201c7be90$215364f0$6800a8c0@anniec> <000e01c7beb9$8f88c180$0764a8c0@ULTRADNT> <468C7AB0.8090900@mvps.org> <001401c7bf20$89329240$0764a8c0@ULTRADNT> Message-ID: <468D6A54.206@mvps.org> That's cool, Steve. Can you think of anything else you might have changed at the same time? Regards Steve Steve Conklin wrote: > Steve: > I have made this change in production apps, and have seen the time drop from > minutes to seconds. > From martyconnelly at shaw.ca Thu Jul 5 20:02:11 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 05 Jul 2007 18:02:11 -0700 Subject: [AccessD] Manipulate AC95 mdb files without converting In-Reply-To: <00ef01c7bc70$b3da5da0$6600a8c0@TheWaddles> References: <00e601c7bc68$6f485320$6600a8c0@TheWaddles> <00ef01c7bc70$b3da5da0$6600a8c0@TheWaddles> Message-ID: <468D9493.5000309@shaw.ca> You can also open an Excel Spreadsheet using the JET OLE DB Provider to read into a Access table, removing the header record , just set a reference to ADO, should work with 95. You could modify this to use individual sheets or ranges. You might get away with using linking an xls file through the Link Manager as a table, never tried it with access 95 I skipped that version. ADO version oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _ "Data Source=c:\somepath\mySpreadsheet.xls;" & _ "Extended Properties=""Excel 8.0;HDR=Yes""" Where "HDR=Yes" means that there is a header row in the cell range (or named range), so the provider will not include the first row of the selection into the recordset. If "HDR=No", then the provider will include the first row of the cell range (or named ranged) into the recordset. ExcelADO demonstrates how to use ADO to read and write data in Excel workbooks http://support.microsoft.com/default.aspx?scid=kb;en-us;278973 Then write table back to excel with ADO into specific Cells. Careful this is Excel based. Import data from Access to Excel (ADO) single worksheet http://erlandsendata.no/english/index.php?d=envbadacimportado Kevin Waddle wrote: >Anita, > >I'm sorry I didn't make it clear what I am trying to do. > >But your suggestion pointed me in the right direction. > >I am trying to import data from an Excel file into the AC95 db. > >What I ended up doing is creating an Access Object within Excel and running >a RunSQL command on each line in the Excel Sheet. > >Thank you, >Kevin > > >355/113 - Not the famous number Pi, but a great simulation! > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith >Sent: Sunday, July 01, 2007 10:26 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Manipulate AC95 mdb files without converting > >Kevin >You should be able to simply open the database with any later versions of >Access and enter data directly into it. >Anita Smith >Australia > > > > >>Access Guru's, >> >>I have a client that uses a VB application that creates and uses an >>Access >>95 mdb. >> >>He would like to add data directly to the mdb from Access 2002 or Excel. >> >>Is it possible, directly or through an add-in, to manipulate data in >>an Access 95 file? >> >>Thank you, >>Kevin >> >> >> > > -- Marty Connelly Victoria, B.C. Canada From accessd at shaw.ca Thu Jul 5 21:58:25 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 19:58:25 -0700 Subject: [AccessD] Isolating matching and related records In-Reply-To: <468D9493.5000309@shaw.ca> Message-ID: <0JKQ003S9LDENDD5@l-daemon> Hi All: The following question seems like a simple SQL question but I just can not find the appropriate answer at this minute... too many long nights. Given: 1. A table of many records, with each record having a couple fields called {section] and [code]. 2. The content of field [section] has only three possible entries of "A1","B1" and "C1". The contents of field [code] can be any of a variety of codes. 3. There will always be records for group "A1" and "C1" but not always for "B1" What SQL code would find the group where there are no matching "B1" records and delete all the records in the "C1" group An example of data could be; 5 records of [section] = "A1", [code] = "TTR" 4 records of [section] = "B1", [code] = "TTR" 30 records of [section] = "C1", [code] = "TTR" 3 records of [section] = "A1", [code] = "CYR" 47 records of [section] = "C1", [code] = "CYR" 5 records of [section] = "A1", [code] = "PIJ" 4 records of [section] = "B1", [code] = "PIJ" 30 records of [section] = "C1", [code] = "PIJ" After the SQL code was run all 47 records with [section] = "C1' and [code] = "CYR" would be gone. It does not seem like a difficult process but... MTIA Jim From jmhecht at earthlink.net Thu Jul 5 22:03:35 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Thu, 5 Jul 2007 20:03:35 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> References: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> Message-ID: <000501c7bf7a$3ec87b70$6701a8c0@ACER2G> Looking at my bleeding hands.... That was the problem, I was holding the cookie cutter wrong and that's why my mdbs were never as good. : ( Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 accessd at shaw.ca Thu Jul 5 22:11:04 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 05 Jul 2007 20:11:04 -0700 Subject: [AccessD] Performance tips anyone? In-Reply-To: <20070705185359.94BA8BEBE@smtp-auth.no-ip.com> Message-ID: <0JKQ002GJLYHG560@l-daemon> Of course you could always make an 'unbound' framework for those applications that have more than 10 users. Think of it John; Framework-Lite ('bound') for 1 to 10 users, Framework-Pro ('unbound') for 11 to 250 users and finally Framework-Web (written in ASP.Net) for unlimited. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 1:29 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I don't think so, but I think she is inferring that you use a cookie cutter approach... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:23 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Charlotte, >I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. LOL. Are you calling me a wannabe? ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 05, 2007 1:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? I just KNEW you wouldn't be able to resist that comment, John! LOL I agree with you thought (mostly). I made heavy use of unbound forms and controls in Access, and it was easier for me to switch to .Net than it might be for some. However, I still think every Access wannabe should learn how to deal with unbound objects as well, and not simply use the cookie cutter bound approach. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 9:30 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Jim, >You mentioning this will not cause near the stir as it did 10 years ago >as most (all?) have now accepted the reality. ;-) LOL, no not quite. Access is a tool built from the ground up for bound. To even discuss unbound for Access NOW, when much more robust unbound tools are available is ... well... kinda silly. Unless of course you have been doing unbound with Access for the last 10 years in which case you have the expertise to do so. Telling the average Access nubee to use Access unbound is IMHO a disservice to the nubee. He might as well just go learn VB.Net. As for me, if I need unbound it will be in VB.Net, NOT in Access (and I am not an Access nubee). The right tool for the job so to speak. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Yes, Drew you have hit on the key to performance... 'unbound'. You mentioning this will not cause near the stir as it did 10 years ago as most (all?) have now accepted the reality. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 05, 2007 8:52 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? It narrows down to a few factors: Backend Design (well indexed and normalized) Front End Design (Hit and run designs, don't stay connected to the backend unless you have too) Network Speed (far more important then hardware speed/memory. Sure, the more your interface leans on the processor/ram, the more you need CPU speed and ram, but for actual database work, the network speed and server hard drive access time are far more criticl) Did I mention 'unbound'. Of course, most of these concerns go out the window when using a web based interface with the .mdb running locally.... ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 12:43 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Anita, >You are very brave It doesn't feel that way. Access works very well for what it does. >A form will open fast if designed well. You are right there. You can grind everything to a halt by trying to use bound forms pulling tens of thousands of records. I had to go to the "single record" thing for this form, but it worked and worked well. >You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. That is just a silly thing to say. Try getting a modern real database running on an old 100 mhz machine with 64 meg. You have to face facts and the facts are that the machine makes the difference. A modern machine can be had for peanuts from Dell. If the business owner is complaining that his Celeron 1ghz machines running 256 megs of ram, windows 98 and Access 2000 is running slow.... My only response will be... "and your point is?" I use a framework which makes it very easy for me to do things like time form openings and log what machine is doing the opening. I showed my client that his users complaining about slow databases were ALL on slow machines. And yep, he is buying new modern "workstations", a few a month, to get rid of the old junk he was running with. And the users have quit complaining. Sorry, facts is facts. You can index till the cows come home but that is never going to fly on ancient hardware. Now, you can certainly move the whole shooting match to a modern server running Windows server 2003 and SQl Server and pay through the nose for that machine, OS and SQL Server, and then pay through the nose for SQL Server and OS notworking experts. That is certainly an option. Or you can update your workstations for less money and have good performance for many (MANY) more than 10-12 users. And no, I am not arguing that an MDB is the solution for hundreds of users but 10-12 users? C'mon! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 05, 2007 12:57 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Performance tips anyone? John, My comments in line: Errrrr! Wrong answer. I have a database with 25 users in the database every day. The BE is currently about 800 mbytes. This BE has tables with hundreds of thousands of records in some tables, 30K-50K records in the main tables (claimant / claim). I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). *************************************** You are very brave *************************************** I open a VERY complex tabbed form with about 20 tabs on it, with subforms on each tab (JIT subforms). Users on fast machines open the form in about 1.2 seconds. Users on very old slow machines take about 5 to 6 seconds. *************************************** A form will open fast if designed well. *************************************** Speed of the individual workstation is the single largest determinate of acceptable speed. A high speed processor and LOTS of memory (1 gig for Windows XP Pro) are essential. Moving to a 1 gbit lan made a big difference as well (which requires a gigabit NIC in the machines as well). *************************************** You can keep throwing hardware at Access applications to will make them perform faster. The real trick is to get your database to perform fast regardless. *************************************** Anita -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- 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 jwcolby at colbyconsulting.com Fri Jul 6 00:12:51 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 6 Jul 2007 01:12:51 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: <0JKQ002GJLYHG560@l-daemon> Message-ID: <20070706051310.779F1BCC5@smtp-auth.no-ip.com> LOL. I am using framework-pro (.net 2.0) for anything that needs more than Access bound can give me. And framework-lite (bound) is routinely handling 25 users, every day. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, July 05, 2007 11:11 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? Of course you could always make an 'unbound' framework for those applications that have more than 10 users. Think of it John; Framework-Lite ('bound') for 1 to 10 users, Framework-Pro ('unbound') for 11 to 250 users and finally Framework-Web (written in ASP.Net) for unlimited. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 05, 2007 11:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Performance tips anyone? ROTFL. No I use a framework. OK, yea, I use a cookie cutter approach, that is what a framework does. Of course I can turn out cookies waaaaaay faster than those of you cutting your cookies by hand. John W. Colby Colby Consulting www.ColbyConsulting.com From adtejpal at gmail.com Fri Jul 6 02:51:13 2007 From: adtejpal at gmail.com (A.D.TEJPAL) Date: Fri, 6 Jul 2007 13:21:13 +0530 Subject: [AccessD] Isolating matching and related records References: <0JKQ003S9LDENDD5@l-daemon> Message-ID: <001101c7bfa2$883106b0$0957a27a@pcadt> Jim, Delete query as given below, should get you the desired results. Best wishes, A.D.Tejpal --------------- ======================================== DELETE * FROM T_Codes WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 WHERE T1.Section = "B1"),0,1),0) > 0; ======================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Friday, July 06, 2007 08:28 Subject: [AccessD] Isolating matching and related records Hi All: The following question seems like a simple SQL question but I just can not find the appropriate answer at this minute... too many long nights. Given: 1. A table of many records, with each record having a couple fields called {section] and [code]. 2. The content of field [section] has only three possible entries of "A1","B1" and "C1". The contents of field [code] can be any of a variety of codes. 3. There will always be records for group "A1" and "C1" but not always for "B1" What SQL code would find the group where there are no matching "B1" records and delete all the records in the "C1" group An example of data could be; 5 records of [section] = "A1", [code] = "TTR" 4 records of [section] = "B1", [code] = "TTR" 30 records of [section] = "C1", [code] = "TTR" 3 records of [section] = "A1", [code] = "CYR" 47 records of [section] = "C1", [code] = "CYR" 5 records of [section] = "A1", [code] = "PIJ" 4 records of [section] = "B1", [code] = "PIJ" 30 records of [section] = "C1", [code] = "PIJ" After the SQL code was run all 47 records with [section] = "C1' and [code] = "CYR" would be gone. It does not seem like a difficult process but... MTIA Jim From miscellany at mvps.org Fri Jul 6 03:50:22 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 06 Jul 2007 20:50:22 +1200 Subject: [AccessD] OpenForm parameters Message-ID: <468E024E.60506@mvps.org> In the recent discussion here in the thread "Performance tips anyone?", it was suggested that explicitly entering the arguments in an OpenForm call will improve the performance of the form opening. Just for fun, I have done an admittedly crude test, on the basis of which unfortunately this idea was not supported. I had some code to open and close a bound form 1000 times, and record the time in seconds. 3 trials. The results when the form was opened like this: DoCmd.OpenForm "MyForm" ... were: 19 23 23 The results when the form was opened like this: DoCmd.OpenForm "MyForm", acNormal, , , acFormEdit, acWindowNormal ... were: 24 20 25 So, if these results are an indication, in fact the reverse may be true. Which would make sense, when you think about it, that pre-compiled default values may be a bit quicker than having to evaluate code at runtime. Oh well... Regards Steve From accessd666 at yahoo.com Fri Jul 6 05:09:12 2007 From: accessd666 at yahoo.com (Sad Der) Date: Fri, 6 Jul 2007 03:09:12 -0700 (PDT) Subject: [AccessD] Disable left-shift Message-ID: <925380.90087.qm@web31613.mail.mud.yahoo.com> Hi, Just had a very nice moment :-). "Hi Access guru: (people disgust Access around here) Please test the new and improved 250 hour costly SQL Server security modification and see if you can hack it." While they were laughing and smiling I browsed in the explorer to the adp. Opened it using left shift. Selected a table and deleted all records and smiled back. The look on their faces....awsome!!!!!! The user that was implemented in the connection setting was dbo_owner whoehahaha. So the fun is over, does anybody have the 'disable left shift' key code lying around. I can't find it 1-2-3. Thanks in Advance! Regards, Sander ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ From hkotsch at arcor.de Fri Jul 6 05:44:55 2007 From: hkotsch at arcor.de (Helmut Kotsch) Date: Fri, 6 Jul 2007 12:44:55 +0200 Subject: [AccessD] Disable left-shift In-Reply-To: <925380.90087.qm@web31613.mail.mud.yahoo.com> Message-ID: Function faq_DisableShiftKeyBypass() As Boolean 'The next time the database is opened ' after this function has been run, ' the autoexec macro will not be bypassed, ' even if the shift key is pressed. On Error GoTo errDisableShift Dim db As Database Dim prop As Property Const conPropNotFound = 3270 Set db = CurrentDb() db.Properties("AllowByPassKey") = False faq_DisableShiftKeyBypass = True exitDisableShift: Exit Function errDisableShift: 'The AllowBypassKey property is a user-defined ' property of the database that must be created ' before it can be set. This error code will execute ' the first time this function is run in a database. If Err = conPropNotFound Then Set prop = db.CreateProperty("AllowByPassKey", _ dbBoolean, False) db.Properties.Append prop Resume Next Else MsgBox "Function DisableShiftKeyBypass did" & _ " not complete successfully." faq_DisableShiftKeyBypass = False GoTo exitDisableShift End If End Function HTH Helmut -----Ursprungliche Nachricht----- Von: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]Im Auftrag von Sad Der Gesendet: Freitag, 6. Juli 2007 12:09 An: Acces User Group Betreff: [AccessD] Disable left-shift Hi, Just had a very nice moment :-). "Hi Access guru: (people disgust Access around here) Please test the new and improved 250 hour costly SQL Server security modification and see if you can hack it." While they were laughing and smiling I browsed in the explorer to the adp. Opened it using left shift. Selected a table and deleted all records and smiled back. The look on their faces....awsome!!!!!! The user that was implemented in the connection setting was dbo_owner whoehahaha. So the fun is over, does anybody have the 'disable left shift' key code lying around. I can't find it 1-2-3. Thanks in Advance! Regards, Sander ____________________________________________________________________________ ________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Fri Jul 6 07:20:23 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 08:20:23 -0400 Subject: [AccessD] Disable left-shift In-Reply-To: <925380.90087.qm@web31613.mail.mud.yahoo.com> References: <925380.90087.qm@web31613.mail.mud.yahoo.com> Message-ID: <002701c7bfc8$1b6ed040$d1b82ad1@SusanOne> Just goes to show that God really does have a sense of humor, and a soft spot for Access developers.;) Nicely done! Susan H. Hi, Just had a very nice moment :-). "Hi Access guru: (people disgust Access around here) Please test the new and improved 250 hour costly SQL Server security modification and see if you can hack it." From markamatte at hotmail.com Fri Jul 6 07:49:32 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 06 Jul 2007 12:49:32 +0000 Subject: [AccessD] Isolating matching and related records In-Reply-To: <0JKQ003S9LDENDD5@l-daemon> Message-ID: Hey Jim, I sent a response to the SQL list. Thanks, Mark >From: Jim Lawrence >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: [AccessD] Isolating matching and related records >Date: Thu, 05 Jul 2007 19:58:25 -0700 > >Hi All: > >The following question seems like a simple SQL question but I just can not >find the appropriate answer at this minute... too many long nights. > >Given: > >1. A table of many records, with each record having a couple fields called >{section] and [code]. > >2. The content of field [section] has only three possible entries of >"A1","B1" and "C1". The contents of field [code] can be any of a variety of >codes. > >3. There will always be records for group "A1" and "C1" but not always for >"B1" > >What SQL code would find the group where there are no matching "B1" records >and delete all the records in the "C1" group > >An example of data could be; > >5 records of [section] = "A1", [code] = "TTR" >4 records of [section] = "B1", [code] = "TTR" >30 records of [section] = "C1", [code] = "TTR" >3 records of [section] = "A1", [code] = "CYR" >47 records of [section] = "C1", [code] = "CYR" >5 records of [section] = "A1", [code] = "PIJ" >4 records of [section] = "B1", [code] = "PIJ" >30 records of [section] = "C1", [code] = "PIJ" > >After the SQL code was run all 47 records with [section] = "C1' and [code] >= >"CYR" would be gone. > >It does not seem like a difficult process but... > >MTIA > >Jim > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From ssharkins at setel.com Fri Jul 6 08:21:36 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 09:21:36 -0400 Subject: [AccessD] Isolating matching and related records In-Reply-To: References: <0JKQ003S9LDENDD5@l-daemon> Message-ID: <005f01c7bfd0$9560a470$d1b82ad1@SusanOne> Don't forget about the Find Unmatched Query Wizard -- it might not give you the exact results that you need, but it can be a good place to start, especially if you're not an expert at Jet SQL. Susan H. Hey Jim, I sent a response to the SQL list. Thanks, Mark > >The following question seems like a simple SQL question but I just can >not find the appropriate answer at this minute... too many long nights. > From fuller.artful at gmail.com Fri Jul 6 10:14:45 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 6 Jul 2007 11:14:45 -0400 Subject: [AccessD] Search within a subform Message-ID: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> I've forgotten how to do this. There's a combo on the master form, but it relates to the subform (the master is unbound). So I need to tell it to search the subform's recordset. TIA, Arthur From John.Clark at niagaracounty.com Fri Jul 6 10:38:27 2007 From: John.Clark at niagaracounty.com (John Clark) Date: Fri, 06 Jul 2007 11:38:27 -0400 Subject: [AccessD] MDE will not open In-Reply-To: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> References: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> Message-ID: <468E29B1.167F.006B.0@niagaracounty.com> I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? John W. Clark Computer Programmer Niagara County Central Data Processing \\ ^ ^ // From robert at webedb.com Fri Jul 6 11:32:23 2007 From: robert at webedb.com (Robert L. Stewart) Date: Fri, 06 Jul 2007 11:32:23 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: References: Message-ID: <200707061638.l66GcIgV017744@databaseadvisors.com> Framework-Web = Codesmith Tools + .netTiers template Would also work for a Framework-WinForm. Robert At 05:09 AM 7/6/2007, you wrote: >Date: Thu, 05 Jul 2007 20:11:04 -0700 >From: Jim Lawrence >Subject: Re: [AccessD] Performance tips anyone? >To: "'Access Developers discussion and problem solving'" > >Message-ID: <0JKQ002GJLYHG560 at l-daemon> >Content-Type: text/plain; charset=us-ascii > > >Of course you could always make an 'unbound' framework for those >applications that have more than 10 users. > >Think of it John; Framework-Lite ('bound') for 1 to 10 users, Framework-Pro >('unbound') for 11 to 250 users and finally Framework-Web (written in >ASP.Net) for unlimited. :-) > >Jim From ssharkins at setel.com Fri Jul 6 13:09:21 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 14:09:21 -0400 Subject: [AccessD] Syntax for referencing subform in a subform Message-ID: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> I just wrote a quick entry on referencing subforms and a reader wants to know how to reference a subform in a subform. Frankly, I don't think I've ever tried -- I can't remember one single time when I've created a subform in another subform. Since a subform is a control in the form, what's a subform in another subform -- can a control have dependent controls? Susan H. From erbachs at gmail.com Fri Jul 6 13:10:36 2007 From: erbachs at gmail.com (Steve Erbach) Date: Fri, 6 Jul 2007 13:10:36 -0500 Subject: [AccessD] Search within a subform In-Reply-To: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> References: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> Message-ID: <39cb22f30707061110w7bb4d54excb5707d314777b33@mail.gmail.com> Arthur, Are you talking about something like: set rst = Forms("MasterForm")("SubForm").RecordsetClone rst.FindFirst "[KeyField]=123" Steve Erbach On 7/6/07, Arthur Fuller wrote: > I've forgotten how to do this. There's a combo on the master form, but it > relates to the subform (the master is unbound). So I need to tell it to > search the subform's recordset. > > TIA, > Arthur From accessd at shaw.ca Fri Jul 6 13:30:21 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Fri, 06 Jul 2007 11:30:21 -0700 Subject: [AccessD] Isolating matching and related records In-Reply-To: <001101c7bfa2$883106b0$0957a27a@pcadt> Message-ID: <0JKR006D2SIKWQS2@l-daemon> Hi A.D. Tejpal: Your code looks very good but some adjustments would have to be made to make it work in my particular context. I worked backwards, first in MS SQL where SubQueries are available and then translated the result into Access's compound query system. Below is the result for the record: First one record of each match group is created in queries 1 and 2. Then any missing matches are isolated in query 3 and query 4 deletes those matches. I am sure this code could be greatly refined but the results were needed fast. query1: SELECT DISTINCT tblRosterReportTemplate.SectionCode, tblRosterReportTemplate.JobCode FROM tblRosterReportTemplate WHERE (tblRosterReportTemplate.SectionCode="C1") query2: SELECT DISTINCT tblRosterReportTemplate.SectionCode, tblRosterReportTemplate.JobCode FROM tblRosterReportTemplate WHERE (tblRosterReportTemplate.SectionCode="B1") query3: SELECT query1.SectionCode, query1.JobCode FROM query1 LEFT JOIN query2 ON query1.JobCode = query2.JobCode WHERE query2.SectionCode Is Null; query4: DELETE * FROM tblRosterReportTemplate WHERE SectionCode = query3.SectionCode' AND JobCode = query3.JobCode; Thank you so much for your help Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Friday, July 06, 2007 12:51 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Isolating matching and related records Jim, Delete query as given below, should get you the desired results. Best wishes, A.D.Tejpal --------------- ======================================== DELETE * FROM T_Codes WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 WHERE T1.Section = "B1"),0,1),0) > 0; ======================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Friday, July 06, 2007 08:28 Subject: [AccessD] Isolating matching and related records Hi All: The following question seems like a simple SQL question but I just can not find the appropriate answer at this minute... too many long nights. Given: 1. A table of many records, with each record having a couple fields called {section] and [code]. 2. The content of field [section] has only three possible entries of "A1","B1" and "C1". The contents of field [code] can be any of a variety of codes. 3. There will always be records for group "A1" and "C1" but not always for "B1" What SQL code would find the group where there are no matching "B1" records and delete all the records in the "C1" group An example of data could be; 5 records of [section] = "A1", [code] = "TTR" 4 records of [section] = "B1", [code] = "TTR" 30 records of [section] = "C1", [code] = "TTR" 3 records of [section] = "A1", [code] = "CYR" 47 records of [section] = "C1", [code] = "CYR" 5 records of [section] = "A1", [code] = "PIJ" 4 records of [section] = "B1", [code] = "PIJ" 30 records of [section] = "C1", [code] = "PIJ" After the SQL code was run all 47 records with [section] = "C1' and [code] = "CYR" would be gone. It does not seem like a difficult process but... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Fri Jul 6 13:46:30 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 14:46:30 -0400 Subject: [AccessD] Search within a subform In-Reply-To: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> References: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> Message-ID: <009e01c7bffd$f868b030$d1b82ad1@SusanOne> Set the subform's Link Child Fields and Link Master Fields properties? Susan H. I've forgotten how to do this. There's a combo on the master form, but it relates to the subform (the master is unbound). So I need to tell it to search the subform's recordset. From lembit.dbamail at t-online.de Fri Jul 6 13:49:01 2007 From: lembit.dbamail at t-online.de (Lembit Soobik) Date: Fri, 6 Jul 2007 20:49:01 +0200 Subject: [AccessD] Syntax for referencing subform in a subform References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> Message-ID: <001401c7bffe$523e9520$1800a8c0@s1800> Susan, there is a nice document by William Hindman on our website: If you are on ... and want to reference ... Lembit ----- Original Message ----- From: "Susan Harkins" To: "'Access Developers discussion and problem solving'" Sent: Friday, July 06, 2007 8:09 PM Subject: [AccessD] Syntax for referencing subform in a subform >I just wrote a quick entry on referencing subforms and a reader wants to > know how to reference a subform in a subform. Frankly, I don't think I've > ever tried -- I can't remember one single time when I've created a subform > in another subform. > > Since a subform is a control in the form, what's a subform in another > subform -- can a control have dependent controls? > > Susan H. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.1/888 - Release Date: 06.07.2007 > 06:36 > > From adtp at airtelbroadband.in Fri Jul 6 13:50:40 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sat, 7 Jul 2007 00:20:40 +0530 Subject: [AccessD] Search within a subform References: <29f585dd0707060814w35e60497qcd0f44ba0893d336@mail.gmail.com> Message-ID: <029801c7bffe$9cd26120$c257a27a@pcadt> Arthur, Two of my sample db's as mentioned below, might be of interest to you: (a) Form_Search (b) Form_SearchByYearMonthRange These are available at Rogers Access Library (other developers library). Link - http://www.rogersaccesslibrary.com/OtherLibraries.asp#Tejpal,A.D. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Arthur Fuller To: Access Developers discussion and problem solving Sent: Friday, July 06, 2007 20:44 Subject: [AccessD] Search within a subform I've forgotten how to do this. There's a combo on the master form, but it relates to the subform (the master is unbound). So I need to tell it to search the subform's recordset. TIA, Arthur From adtp at airtelbroadband.in Fri Jul 6 14:10:05 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sat, 7 Jul 2007 00:40:05 +0530 Subject: [AccessD] Syntax for referencing subform in a subform References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> Message-ID: <064601c7c001$586c6eb0$c257a27a@pcadt> Susan, My sample db named FormsSubformsReference might be of interest to you. It is available at Rogers Access Library (other developers library). Link - http://www.rogersaccesslibrary.com/OtherLibraries.asp#Tejpal,A.D. The db covers all likely combinations of origin & destination controls located on the parent as well as subforms representing different levels of nesting. Nesting upto three levels deep is represented. It presents a visual ready reckoner as well. On selection of origin & destination controls, corresponding VBA code gets displayed simultaneously - at the bottom. Apart from showing the required syntax for (a) referring to controls of one group of nested subforms from another group of nested subforms and (b) referring to subroutines (contained in form's modules) across various levels of nested subforms, the sample db demonstrates the syntax for referring controls on forms / nested subforms in SQL statements. Dbl clicking any text box on main parent form or various nested subforms at left, causes its value to be picked up by the query, results of which, are displayed in the innermost nested subform at right. Simultaneously, the SQL used in source query, gets displayed at bottom. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Susan Harkins To: 'Access Developers discussion and problem solving' Sent: Friday, July 06, 2007 23:39 Subject: [AccessD] Syntax for referencing subform in a subform I just wrote a quick entry on referencing subforms and a reader wants to know how to reference a subform in a subform. Frankly, I don't think I've ever tried -- I can't remember one single time when I've created a subform in another subform. Since a subform is a control in the form, what's a subform in another subform -- can a control have dependent controls? Susan H. From Patricia.O'Connor at otda.state.ny.us Fri Jul 6 14:11:22 2007 From: Patricia.O'Connor at otda.state.ny.us (O'Connor, Patricia (OTDA)) Date: Fri, 6 Jul 2007 15:11:22 -0400 Subject: [AccessD] Default table value In-Reply-To: References: Message-ID: <01DBAB52E30A9A4AB3D94EF8029EDBE8021BAEF4@EXCNYSM0A1AI.nysemail.nyenet> I have two fields in several tables which use ENVIRON("USERNAME") or ENVIRON("COMPUTERNAME") I tried saving the table after adding two more fields and it will not allow me to because of the ENVIRON I know about M$ stupid blocking of ENVIRON and CURDIR per http://office.microsoft.com/en-us/access/HA011225981033.aspx#050 I added the two functions to the backend MDB hoping it would allow me to save it -- NOPE. Why wouldn't that look at the function while a query would? Is there some other way to have the DEFAULT value for a table field be ENVIRON("USERNAME") or equal to it? I went in and updated my registry to have the value for Sandbox be a 2 instead of 3 which didn't work. I haven't changed the registry to stop it all together yet. I probably will just so I can add fields. Is there some other way without having to mess with the registry? Other people might not have permission to change their registry. Thank you have a great weekend Patti ************************************************** * Patricia O'Connor * Associate Computer Programmer Analyst * OTDA - BDMA * (W) mailto:Patricia.O'Connor at otda.state.ny.us * (w) mailto:aa1160 at nysemail.state.ny.us ************************************************** -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. From ssharkins at setel.com Fri Jul 6 14:20:43 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 15:20:43 -0400 Subject: [AccessD] Syntax for referencing subform in a subform In-Reply-To: <001401c7bffe$523e9520$1800a8c0@s1800> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> <001401c7bffe$523e9520$1800a8c0@s1800> Message-ID: <00ac01c7c002$c0021ce0$d1b82ad1@SusanOne> Thanks Lembit, I was unable to find it though. I'm sure it's there, I just didn't find it. Susan H. Susan, there is a nice document by William Hindman on our website: If you are on ... and want to reference ... From adtp at airtelbroadband.in Fri Jul 6 14:24:52 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sat, 7 Jul 2007 00:54:52 +0530 Subject: [AccessD] Isolating matching and related records References: <0JKR006D2SIKWQS2@l-daemon> Message-ID: <068101c7c003$5fd68e40$c257a27a@pcadt> You are most welcome Jim! The delete query suggested in my post was developed & tested successfully on Access 2003 desktop. A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Saturday, July 07, 2007 00:00 Subject: Re: [AccessD] Isolating matching and related records Hi A.D. Tejpal: Your code looks very good but some adjustments would have to be made to make it work in my particular context. I worked backwards, first in MS SQL where SubQueries are available and then translated the result into Access's compound query system. Below is the result for the record: First one record of each match group is created in queries 1 and 2. Then any missing matches are isolated in query 3 and query 4 deletes those matches. I am sure this code could be greatly refined but the results were needed fast. query1: SELECT DISTINCT tblRosterReportTemplate.SectionCode, tblRosterReportTemplate.JobCode FROM tblRosterReportTemplate WHERE (tblRosterReportTemplate.SectionCode="C1") query2: SELECT DISTINCT tblRosterReportTemplate.SectionCode, tblRosterReportTemplate.JobCode FROM tblRosterReportTemplate WHERE (tblRosterReportTemplate.SectionCode="B1") query3: SELECT query1.SectionCode, query1.JobCode FROM query1 LEFT JOIN query2 ON query1.JobCode = query2.JobCode WHERE query2.SectionCode Is Null; query4: DELETE * FROM tblRosterReportTemplate WHERE SectionCode = query3.SectionCode' AND JobCode = query3.JobCode; Thank you so much for your help Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Friday, July 06, 2007 12:51 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Isolating matching and related records Jim, Delete query as given below, should get you the desired results. Best wishes, A.D.Tejpal --------------- ======================================== DELETE * FROM T_Codes WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 WHERE T1.Section = "B1"),0,1),0) > 0; ======================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Friday, July 06, 2007 08:28 Subject: [AccessD] Isolating matching and related records Hi All: The following question seems like a simple SQL question but I just can not find the appropriate answer at this minute... too many long nights. Given: 1. A table of many records, with each record having a couple fields called {section] and [code]. 2. The content of field [section] has only three possible entries of "A1","B1" and "C1". The contents of field [code] can be any of a variety of codes. 3. There will always be records for group "A1" and "C1" but not always for "B1" What SQL code would find the group where there are no matching "B1" records and delete all the records in the "C1" group An example of data could be; 5 records of [section] = "A1", [code] = "TTR" 4 records of [section] = "B1", [code] = "TTR" 30 records of [section] = "C1", [code] = "TTR" 3 records of [section] = "A1", [code] = "CYR" 47 records of [section] = "C1", [code] = "CYR" 5 records of [section] = "A1", [code] = "PIJ" 4 records of [section] = "B1", [code] = "PIJ" 30 records of [section] = "C1", [code] = "PIJ" After the SQL code was run all 47 records with [section] = "C1' and [code] = "CYR" would be gone. It does not seem like a difficult process but... MTIA Jim From markamatte at hotmail.com Fri Jul 6 15:13:41 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 06 Jul 2007 20:13:41 +0000 Subject: [AccessD] Isolating matching and related records In-Reply-To: <0JKR006D2SIKWQS2@l-daemon> Message-ID: Jim, I went back and read my post since I didn't see a reference. Apparently I didn't include the SQL. Would a single delete statement with a subquery accomplish this? ************SQL************** DELETE tblTest.Section, tblTest.code FROM tblTest WHERE (((tblTest.Section)="C1") AND ((tblTest.code) Not In (SELECT tblTest1.code FROM tblTest AS tblTest1 GROUP BY tblTest1.Section, tblTest1.code HAVING (((tblTest1.Section)="B1"));))); ************SQL************** >From: Jim Lawrence >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Isolating matching and related records >Date: Fri, 06 Jul 2007 11:30:21 -0700 > >Hi A.D. Tejpal: > >Your code looks very good but some adjustments would have to be made to >make >it work in my particular context. I worked backwards, first in MS SQL where >SubQueries are available and then translated the result into Access's >compound query system. Below is the result for the record: > >First one record of each match group is created in queries 1 and 2. Then >any >missing matches are isolated in query 3 and query 4 deletes those matches. >I >am sure this code could be greatly refined but the results were needed >fast. > >query1: >SELECT DISTINCT tblRosterReportTemplate.SectionCode, >tblRosterReportTemplate.JobCode >FROM tblRosterReportTemplate >WHERE (tblRosterReportTemplate.SectionCode="C1") > >query2: >SELECT DISTINCT tblRosterReportTemplate.SectionCode, >tblRosterReportTemplate.JobCode >FROM tblRosterReportTemplate >WHERE (tblRosterReportTemplate.SectionCode="B1") > >query3: >SELECT query1.SectionCode, query1.JobCode >FROM query1 LEFT JOIN query2 >ON query1.JobCode = query2.JobCode >WHERE query2.SectionCode Is Null; > >query4: >DELETE * FROM tblRosterReportTemplate >WHERE SectionCode = query3.SectionCode' >AND JobCode = query3.JobCode; > >Thank you so much for your help > >Jim > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL >Sent: Friday, July 06, 2007 12:51 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Isolating matching and related records > >Jim, > > Delete query as given below, should get you the desired results. > >Best wishes, >A.D.Tejpal >--------------- > >======================================== >DELETE * >FROM T_Codes >WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 >WHERE T1.Section = "B1"),0,1),0) > 0; >======================================== > > ----- Original Message ----- > From: Jim Lawrence > To: 'Access Developers discussion and problem solving' > Sent: Friday, July 06, 2007 08:28 > Subject: [AccessD] Isolating matching and related records > > > Hi All: > > The following question seems like a simple SQL question but I just can >not >find the appropriate answer at this minute... too many long nights. > > Given: > > 1. A table of many records, with each record having a couple fields >called >{section] and [code]. > > 2. The content of field [section] has only three possible entries of > "A1","B1" and "C1". The contents of field [code] can be any of a variety >of codes. > > 3. There will always be records for group "A1" and "C1" but not always >for >"B1" > > What SQL code would find the group where there are no matching "B1" >records and delete all the records in the "C1" group > > An example of data could be; > > 5 records of [section] = "A1", [code] = "TTR" > 4 records of [section] = "B1", [code] = "TTR" > 30 records of [section] = "C1", [code] = "TTR" > 3 records of [section] = "A1", [code] = "CYR" > 47 records of [section] = "C1", [code] = "CYR" > 5 records of [section] = "A1", [code] = "PIJ" > 4 records of [section] = "B1", [code] = "PIJ" > 30 records of [section] = "C1", [code] = "PIJ" > > After the SQL code was run all 47 records with [section] = "C1' and >[code] >= "CYR" would be gone. > > It does not seem like a difficult process but... > > MTIA > > Jim >-- >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 _________________________________________________________________ http://liveearth.msn.com From jwcolby at colbyconsulting.com Fri Jul 6 15:23:39 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 6 Jul 2007 16:23:39 -0400 Subject: [AccessD] Syntax for referencing subform in a subform In-Reply-To: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> Message-ID: <20070706202359.525B5BD34@smtp-auth.no-ip.com> There is a subform control in the parent subform. Thus Me!ctlSubform.form!ctlSubSubForm.Form The ! Refers to a control, the . Refers to a property (the form property of the subform control). And I have done it, in fact the disability insurance call center software has a subform on a tab of the main form. Inside of that subform is another tab control EACH of which has a subform. Every subform is loaded JIT and unloaded as the user clicks off the tab the subform is on. Thus the subform on the tab on the parent form doesn't load unless the user clicks on that tab. If they click on that tab, a subform loads with a tab control on it. On the default tab is a subform that loads immediately. But if the user clicks off onto any of the other tabs in the subform, then the subform on the tab losing the focus (clicked off of) unloads. The main form is a claim. The claim form has about 18 tabs that may or may not be visible, depending on the insurance product line. On one of those tabs is all the stuff having to do with benefits for specific months. My client only issues checks for particular insurance products that they service (their clients), so if a claim is selected which does not get paid directly by my client, then the benefit tab is hidden. The Benefit tab has one big subform which has a tab control. That subform's tab control has a tab (and subform) for benefit history (months already paid). The next tab has a subform for entering new benefit records (current and future months). The next tab has a subform for displaying checks paid. The text tab has a subform for entering offsets against the claim specific to that claim (Social Security deductions, tax deductions, child support and such things). There are a handful of other subforms on tabs as well (about 7 or 8 tabs total). ALL of this stuff is specific to particular lines of insurance for which my client actually issues the checks to the claimant. Since all products are not paid by my client (the insurer issues the checks directly) the entire benefit tab is hidden / unhidden as needed for the product that a claim is paid against. In fact this form has 4 levels of subforms Claim Claimant Policy etc. Benefits tab subform Benefit History Offsets against the benefit Benefits New and future Offsets against the Benefit Payments (checks paid) Possible offsets against the claim etc etc BTW, this is the form discussed in a previous thread that takes 1.25 seconds to load on fast hardware, and 5-6 seconds to load on 4-5 year old hardware. Using a tab metaphor with JIT subforms allows the user to have the entire claim and all the relevant pieces at their fingertips but keep the load speed reasonable. Believe it or not, this whole thing fits on an 800 x 600 screen, though I keep banging on them to move everyone up to at LEAST 17" monitors so I can move to a 1024 x 768 screen and open things up a bit. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 06, 2007 2:09 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Syntax for referencing subform in a subform I just wrote a quick entry on referencing subforms and a reader wants to know how to reference a subform in a subform. Frankly, I don't think I've ever tried -- I can't remember one single time when I've created a subform in another subform. Since a subform is a control in the form, what's a subform in another subform -- can a control have dependent controls? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From lembit.dbamail at t-online.de Fri Jul 6 15:52:04 2007 From: lembit.dbamail at t-online.de (Lembit Soobik) Date: Fri, 6 Jul 2007 22:52:04 +0200 Subject: [AccessD] Syntax for referencing subform in a subform References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne><001401c7bffe$523e9520$1800a8c0@s1800> <00ac01c7c002$c0021ce0$d1b82ad1@SusanOne> Message-ID: <000c01c7c00f$823d8220$1800a8c0@s1800> I searched it too, but seems that it is in revision, and I cannot find my copy. maybe Jim L has it available? Lembit ----- Original Message ----- From: "Susan Harkins" To: "'Access Developers discussion and problem solving'" Sent: Friday, July 06, 2007 9:20 PM Subject: Re: [AccessD] Syntax for referencing subform in a subform > Thanks Lembit, I was unable to find it though. I'm sure it's there, I just > didn't find it. > > Susan H. > > Susan, > there is a nice document by William Hindman on our website: If you are on > ... and want to reference ... > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.1/888 - Release Date: 06.07.2007 > 06:36 > > From ssharkins at setel.com Fri Jul 6 19:27:43 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 20:27:43 -0400 Subject: [AccessD] Syntax for referencing subform in a subform In-Reply-To: <000c01c7c00f$823d8220$1800a8c0@s1800> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne><001401c7bffe$523e9520$1800a8c0@s1800><00ac01c7c002$c0021ce0$d1b82ad1@SusanOne> <000c01c7c00f$823d8220$1800a8c0@s1800> Message-ID: <001e01c7c02d$a36f7340$c2b82ad1@SusanOne> It's Okay -- I found what I needed. Thank you. Susan H. I searched it too, but seems that it is in revision, and I cannot find my copy. maybe Jim L has it available? From ssharkins at setel.com Fri Jul 6 19:27:43 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 6 Jul 2007 20:27:43 -0400 Subject: [AccessD] Syntax for referencing subform in a subform In-Reply-To: <20070706202359.525B5BD34@smtp-auth.no-ip.com> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> <20070706202359.525B5BD34@smtp-auth.no-ip.com> Message-ID: <002201c7c02d$a740eda0$c2b82ad1@SusanOne> There is a subform control in the parent subform. Thus Me!ctlSubform.form!ctlSubSubForm.Form =======I wondered if that would be the case. Susan H. From accessd at shaw.ca Sat Jul 7 02:53:17 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 00:53:17 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <009e01c7bffd$f868b030$d1b82ad1@SusanOne> Message-ID: <0JKS002C7TOOG3T1@l-daemon> Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim From miscellany at mvps.org Sat Jul 7 03:41:14 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 07 Jul 2007 20:41:14 +1200 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <0JKS002C7TOOG3T1@l-daemon> References: <0JKS002C7TOOG3T1@l-daemon> Message-ID: <468F51AA.7070203@mvps.org> Jim, In report design, go to the File|Page Setup menu. On the Columns tab, you can set the number and size of columns, and set the Column Layout to "Across then Down". See if that gets you in the right direction. Regads Steve Jim Lawrence wrote: > Hi All: > > Is there a way to print across the page within an Access report? Like in the > following example: > > Record01 record02 record03 record4 record5 > Record06 record07 record08 record9 record10 > record11 record12 record13 record14 record15 > record16 record17 record18 record19 record20 > etc......... > > MTIA > Jim > From rockysmolin at bchacc.com Sat Jul 7 08:28:07 2007 From: rockysmolin at bchacc.com (rockysmolin at bchacc.com) Date: Sat, 7 Jul 2007 09:28:07 -0400 Subject: [AccessD] Access Reports rinting accross Message-ID: <380-2200776713287938@M2W026.mail2web.com> Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- myhosting.com - Premium Microsoft? Windows? and Linux web and application hosting - http://link.myhosting.com/myhosting From bbruen at unwired.com.au Sat Jul 7 09:13:55 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Sun, 8 Jul 2007 00:13:55 +1000 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <468F51AA.7070203@mvps.org> References: <0JKS002C7TOOG3T1@l-daemon> <468F51AA.7070203@mvps.org> Message-ID: <200707080013.55781.bbruen@unwired.com.au> > Jim Lawrence wrote: > > Hi All: > > > > Is there a way to print across the page within an Access report? Like in > > the following example: > > > > Record01 record02 record03 record4 record5 > > Record06 record07 record08 record9 record10 > > record11 record12 record13 record14 record15 > > record16 record17 record18 record19 record20 > > etc......... > > > > MTIA > > Jim Just for the sake of the stupid question... why? -- regards Bruce From accessd at shaw.ca Sat Jul 7 10:04:56 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 08:04:56 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <200707080013.55781.bbruen@unwired.com.au> Message-ID: <0JKT006CUDO2WP93@l-daemon> Hi Bruce: The client is always right and there are so many records in some sections of the report that it streams on for pages with just only two columns of information. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Saturday, July 07, 2007 7:14 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Access Reports rinting accross > Jim Lawrence wrote: > > Hi All: > > > > Is there a way to print across the page within an Access report? Like in > > the following example: > > > > Record01 record02 record03 record4 record5 > > Record06 record07 record08 record9 record10 > > record11 record12 record13 record14 record15 > > record16 record17 record18 record19 record20 > > etc......... > > > > MTIA > > Jim Just for the sake of the stupid question... why? -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sat Jul 7 11:01:37 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 09:01:37 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <380-2200776713287938@M2W026.mail2web.com> Message-ID: <0JKT002VPGAIKM40@l-daemon> Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- myhosting.com - Premium MicrosoftR WindowsR and Linux web and application hosting - http://link.myhosting.com/myhosting -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sat Jul 7 11:06:19 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 09:06:19 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <468F51AA.7070203@mvps.org> Message-ID: <0JKT0084LGIDB410@l-daemon> Hi Steve: I will investigate that option but there are some additional requirements that will make that not so simple. Check out the response to Rocky's email and see what you think. Thanks for help Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 07, 2007 1:41 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Access Reports rinting accross Jim, In report design, go to the File|Page Setup menu. On the Columns tab, you can set the number and size of columns, and set the Column Layout to "Across then Down". See if that gets you in the right direction. Regads Steve Jim Lawrence wrote: > Hi All: > > Is there a way to print across the page within an Access report? Like in the > following example: > > Record01 record02 record03 record4 record5 > Record06 record07 record08 record9 record10 > record11 record12 record13 record14 record15 > record16 record17 record18 record19 record20 > etc......... > > MTIA > Jim > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sat Jul 7 11:09:30 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 07 Jul 2007 09:09:30 -0700 Subject: [AccessD] Isolating matching and related records In-Reply-To: Message-ID: <0JKT003UFGNOPC20@l-daemon> Hi Mark: That looks like the solution. Brilliant, Thanks you very much. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Friday, July 06, 2007 1:14 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Isolating matching and related records Jim, I went back and read my post since I didn't see a reference. Apparently I didn't include the SQL. Would a single delete statement with a subquery accomplish this? ************SQL************** DELETE tblTest.Section, tblTest.code FROM tblTest WHERE (((tblTest.Section)="C1") AND ((tblTest.code) Not In (SELECT tblTest1.code FROM tblTest AS tblTest1 GROUP BY tblTest1.Section, tblTest1.code HAVING (((tblTest1.Section)="B1"));))); ************SQL************** >From: Jim Lawrence >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Isolating matching and related records >Date: Fri, 06 Jul 2007 11:30:21 -0700 > >Hi A.D. Tejpal: > >Your code looks very good but some adjustments would have to be made to >make >it work in my particular context. I worked backwards, first in MS SQL where >SubQueries are available and then translated the result into Access's >compound query system. Below is the result for the record: > >First one record of each match group is created in queries 1 and 2. Then >any >missing matches are isolated in query 3 and query 4 deletes those matches. >I >am sure this code could be greatly refined but the results were needed >fast. > >query1: >SELECT DISTINCT tblRosterReportTemplate.SectionCode, >tblRosterReportTemplate.JobCode >FROM tblRosterReportTemplate >WHERE (tblRosterReportTemplate.SectionCode="C1") > >query2: >SELECT DISTINCT tblRosterReportTemplate.SectionCode, >tblRosterReportTemplate.JobCode >FROM tblRosterReportTemplate >WHERE (tblRosterReportTemplate.SectionCode="B1") > >query3: >SELECT query1.SectionCode, query1.JobCode >FROM query1 LEFT JOIN query2 >ON query1.JobCode = query2.JobCode >WHERE query2.SectionCode Is Null; > >query4: >DELETE * FROM tblRosterReportTemplate >WHERE SectionCode = query3.SectionCode' >AND JobCode = query3.JobCode; > >Thank you so much for your help > >Jim > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL >Sent: Friday, July 06, 2007 12:51 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Isolating matching and related records > >Jim, > > Delete query as given below, should get you the desired results. > >Best wishes, >A.D.Tejpal >--------------- > >======================================== >DELETE * >FROM T_Codes >WHERE IIf([Section]="C1",IIf([Code] In (SELECT Code FROM T_Codes As T1 >WHERE T1.Section = "B1"),0,1),0) > 0; >======================================== > > ----- Original Message ----- > From: Jim Lawrence > To: 'Access Developers discussion and problem solving' > Sent: Friday, July 06, 2007 08:28 > Subject: [AccessD] Isolating matching and related records > > > Hi All: > > The following question seems like a simple SQL question but I just can >not >find the appropriate answer at this minute... too many long nights. > > Given: > > 1. A table of many records, with each record having a couple fields >called >{section] and [code]. > > 2. The content of field [section] has only three possible entries of > "A1","B1" and "C1". The contents of field [code] can be any of a variety >of codes. > > 3. There will always be records for group "A1" and "C1" but not always >for >"B1" > > What SQL code would find the group where there are no matching "B1" >records and delete all the records in the "C1" group > > An example of data could be; > > 5 records of [section] = "A1", [code] = "TTR" > 4 records of [section] = "B1", [code] = "TTR" > 30 records of [section] = "C1", [code] = "TTR" > 3 records of [section] = "A1", [code] = "CYR" > 47 records of [section] = "C1", [code] = "CYR" > 5 records of [section] = "A1", [code] = "PIJ" > 4 records of [section] = "B1", [code] = "PIJ" > 30 records of [section] = "C1", [code] = "PIJ" > > After the SQL code was run all 47 records with [section] = "C1' and >[code] >= "CYR" would be gone. > > It does not seem like a difficult process but... > > MTIA > > Jim >-- >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 _________________________________________________________________ http://liveearth.msn.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From adtp at airtelbroadband.in Sat Jul 7 15:19:53 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sun, 8 Jul 2007 01:49:53 +0530 Subject: [AccessD] Access Reports rinting accross References: <0JKT002VPGAIKM40@l-daemon> Message-ID: <003901c7c0d4$aa756ad0$7757a27a@pcadt> Jim, If there is no objection to the use of multi-column subreport for Section C, that should be most convenient. However, if there are compelling reasons to explore selective printing of multiple records across each row, it can be done by manipulating the Left property of relevant text boxes, simultaneously with report's MoveLayout property. Sample code in report's module, as given below, will ensure printing of three records on each row. The report has a group header as per field named Account. Detail section has two controls named RefNum & ClientName respectively. (Use of # within the names of fields/controls is not preferred). When the report is opened, printing proceeds normally, till the value "Referral" is detected in the group header. Thereafter, it starts printing three records across each row. If another group value different from "Referral" comes up, the printing will again revert back to normal style (i.e. one record per row). Best wishes, A.D.Tejpal --------------- Code in report's module ==================================== ' Declaration Section Dim RecNum As Long Private RefLeft1 As Long, RefLeft2 As Long Private RefLeft3 As Long, ClientLeft1 As Long Private ClientLeft2 As Long, ClientLeft3 As Long --------------------------------------------------------------- Private Sub Detail_Format(Cancel As Integer, _ FormatCount As Integer) Dim Cnt As Long If Me.Account <> "Referral" Then Exit Sub End If If RecNum > 0 Then Cnt = RecNum Mod 3 Select Case Cnt Case 0 Me.RefNum.Left = RefLeft3 Me.ClientName.Left = ClientLeft3 Case 2 Me.RefNum.Left = RefLeft2 Me.ClientName.Left = ClientLeft2 Case Else Me.RefNum.Left = RefLeft1 Me.ClientName.Left = ClientLeft1 End Select Else Me.RefNum.Left = RefLeft1 Me.ClientName.Left = ClientLeft1 End If End Sub --------------------------------------------------------------- Private Sub Detail_Print(Cancel As Integer, _ PrintCount As Integer) Dim Cnt As Long If Me.Account <> "Referral" Then Me.MoveLayout = True Exit Sub End If If RecNum > 0 Then Cnt = RecNum Mod 3 If Cnt = 0 Then Me.MoveLayout = True Else Me.MoveLayout = False End If Else Me.MoveLayout = True End If RecNum = RecNum + 1 End Sub --------------------------------------------------------------- Private Sub GroupHeader0_Format(Cancel _ As Integer, FormatCount As Integer) ' Start the record counter with commencement ' of Referral account ( Set it only once. This is ' to guard against unwanted re-setting if repeat ' section property of hroup header is set to Yes) If Me.Account = "Referral" Then RecNum = IIf(RecNum > 0, RecNum, 1) End If End Sub --------------------------------------------------------------- Private Sub ReportHeader_Format(Cancel _ As Integer, FormatCount As Integer) RefLeft1 = Me.RefNum.Left ClientLeft1 = Me.ClientName.Left RefLeft2 = ClientLeft1 + Me.ClientName.Width + 50 ClientLeft2 = ClientLeft1 + (RefLeft2 - RefLeft1) RefLeft3 = ClientLeft2 + Me.ClientName.Width + 50 ClientLeft3 = ClientLeft2 + (RefLeft3 - RefLeft2) End Sub ==================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Saturday, July 07, 2007 21:31 Subject: Re: [AccessD] Access Reports rinting accross Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim From rockysmolin at bchacc.com Sat Jul 7 19:20:18 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Sat, 7 Jul 2007 17:20:18 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <0JKT002VPGAIKM40@l-daemon> Message-ID: <005c01c7c0f5$c3f25e70$0301a8c0@HAL9005> Jim: How about section C is one text box with width = width of the report, and Can Grow=True. Are sections A, B, and C sub-reports? Or do you create their controls on the fly? In any event, in the Open event of the report I'd still create a temp table - this time 2 fields, one would be the PK = whatever field it is that ties section C to sections A and B, second field would be the Ref#/Client Name concatenations. Create a temp table record for each section A/B and use that temp table data for section C. Maybe make section C a sub report with the temp table as its record source and linked to the main report through the PK? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Saturday, July 07, 2007 9:02 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Access Reports rinting accross Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- myhosting.com - Premium MicrosoftR WindowsR and Linux web and application hosting - http://link.myhosting.com/myhosting -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/890 - Release Date: 7/7/2007 3:26 PM From accessd at shaw.ca Sun Jul 8 14:13:24 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 08 Jul 2007 12:13:24 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <003901c7c0d4$aa756ad0$7757a27a@pcadt> Message-ID: <0JKV00CB8JU1S4G9@l-daemon> Hi A. D. Tejal: A very eloquent solution. :-) A subreport of course can be used and I have not ruled out that option yet... One day Access reporting may provide the ability to set columns per Group Heading. Until then this will have to be the appropriate solution. Thanks you Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Saturday, July 07, 2007 1:20 PM To: Access Developers discussion and problem solving Cc: A.D.TEJPAL Subject: Re: [AccessD] Access Reports rinting accross Jim, If there is no objection to the use of multi-column subreport for Section C, that should be most convenient. However, if there are compelling reasons to explore selective printing of multiple records across each row, it can be done by manipulating the Left property of relevant text boxes, simultaneously with report's MoveLayout property. Sample code in report's module, as given below, will ensure printing of three records on each row. The report has a group header as per field named Account. Detail section has two controls named RefNum & ClientName respectively. (Use of # within the names of fields/controls is not preferred). When the report is opened, printing proceeds normally, till the value "Referral" is detected in the group header. Thereafter, it starts printing three records across each row. If another group value different from "Referral" comes up, the printing will again revert back to normal style (i.e. one record per row). Best wishes, A.D.Tejpal --------------- Code in report's module ==================================== ' Declaration Section Dim RecNum As Long Private RefLeft1 As Long, RefLeft2 As Long Private RefLeft3 As Long, ClientLeft1 As Long Private ClientLeft2 As Long, ClientLeft3 As Long --------------------------------------------------------------- Private Sub Detail_Format(Cancel As Integer, _ FormatCount As Integer) Dim Cnt As Long If Me.Account <> "Referral" Then Exit Sub End If If RecNum > 0 Then Cnt = RecNum Mod 3 Select Case Cnt Case 0 Me.RefNum.Left = RefLeft3 Me.ClientName.Left = ClientLeft3 Case 2 Me.RefNum.Left = RefLeft2 Me.ClientName.Left = ClientLeft2 Case Else Me.RefNum.Left = RefLeft1 Me.ClientName.Left = ClientLeft1 End Select Else Me.RefNum.Left = RefLeft1 Me.ClientName.Left = ClientLeft1 End If End Sub --------------------------------------------------------------- Private Sub Detail_Print(Cancel As Integer, _ PrintCount As Integer) Dim Cnt As Long If Me.Account <> "Referral" Then Me.MoveLayout = True Exit Sub End If If RecNum > 0 Then Cnt = RecNum Mod 3 If Cnt = 0 Then Me.MoveLayout = True Else Me.MoveLayout = False End If Else Me.MoveLayout = True End If RecNum = RecNum + 1 End Sub --------------------------------------------------------------- Private Sub GroupHeader0_Format(Cancel _ As Integer, FormatCount As Integer) ' Start the record counter with commencement ' of Referral account ( Set it only once. This is ' to guard against unwanted re-setting if repeat ' section property of hroup header is set to Yes) If Me.Account = "Referral" Then RecNum = IIf(RecNum > 0, RecNum, 1) End If End Sub --------------------------------------------------------------- Private Sub ReportHeader_Format(Cancel _ As Integer, FormatCount As Integer) RefLeft1 = Me.RefNum.Left ClientLeft1 = Me.ClientName.Left RefLeft2 = ClientLeft1 + Me.ClientName.Width + 50 ClientLeft2 = ClientLeft1 + (RefLeft2 - RefLeft1) RefLeft3 = ClientLeft2 + Me.ClientName.Width + 50 ClientLeft3 = ClientLeft2 + (RefLeft3 - RefLeft2) End Sub ==================================== ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Saturday, July 07, 2007 21:31 Subject: Re: [AccessD] Access Reports rinting accross Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sun Jul 8 14:32:15 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 08 Jul 2007 12:32:15 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <005c01c7c0f5$c3f25e70$0301a8c0@HAL9005> Message-ID: <0JKV00E41KPHISX8@l-daemon> Hi Rocky: I may go the route of a subreport or use A.D. Tejal's eloquent solution. All the data is assembled on the fly and can basically be grouped in any method. As previously stated, why doesn't MS Access report allow columns to be controlled per Group? Thanks for the suggesting so now I know all of the options available. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Saturday, July 07, 2007 5:20 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Access Reports rinting accross Jim: How about section C is one text box with width = width of the report, and Can Grow=True. Are sections A, B, and C sub-reports? Or do you create their controls on the fly? In any event, in the Open event of the report I'd still create a temp table - this time 2 fields, one would be the PK = whatever field it is that ties section C to sections A and B, second field would be the Ref#/Client Name concatenations. Create a temp table record for each section A/B and use that temp table data for section C. Maybe make section C a sub report with the temp table as its record source and linked to the main report through the PK? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Saturday, July 07, 2007 9:02 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Access Reports rinting accross Hi Rocky: These columns are fixed length. The wrinkle to the design requirements is that there are 3 individual sections within the report and the data source is in one table and it looks like as follows: Ref#, Client-Name, Account-Detail, Date, Payment The data is sorted so it group appropriately; Date, Client-Name etc. Programming within the report determines which section it is and how it will be printed. The following is a text imitation of the report and how it will print: MY REPORT --------- Line 1: Section A: Acquired Line 2: Ref#, Client-Name, Account-Detail, Date, Payment ... Line 11: Section B: Prospect Line 12: Account-Detail, Date, Payment Line 13: Account-Detail, Date, Payment ... Line 25: Section C: Referral Line 26: Ref#, Client-Name Line 27: Ref#, Client-Name Line 28: Ref#, Client-Name Line 29: Ref#, Client-Name Line 30: Ref#, Client-Name Line 31: Ref#, Client-Name ... Section C could go on for pages but would be more compact if it looked like: Line 26: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name Line 27: Ref#, Client-Name, Ref#, Client-Name, Ref#, Client-Name ... The Report would have to be able to something as follows. Within program control the report would have to pause while continuing to step through the data, accumulating the records in an array and when 3 records were gathered or the end of that section was reached, it would release the pause, print out and continue... I am sure it is doable... Any suggestions would be greatly appreciated. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of rockysmolin at bchacc.com Sent: Saturday, July 07, 2007 6:28 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Access Reports rinting accross Are the records fixed length or variable? For variable, I'd use a temp table with one record, and concatenate the original records into temp table records, using a fixed width font. Then bind the report to the temp table. I suppose you could do the same for fixed length records as well. HTH Rocky Original Message: ----------------- From: Jim Lawrence accessd at shaw.ca Date: Sat, 07 Jul 2007 00:53:17 -0700 To: accessd at databaseadvisors.com Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -------------------------------------------------------------------- myhosting.com - Premium MicrosoftR WindowsR and Linux web and application hosting - http://link.myhosting.com/myhosting -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/890 - Release Date: 7/7/2007 3:26 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Sun Jul 8 16:14:12 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 8 Jul 2007 17:14:12 -0400 Subject: [AccessD] Syntax for loading a specific version of Access Message-ID: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, Arthur From miscellany at mvps.org Sun Jul 8 16:37:15 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 09 Jul 2007 09:37:15 +1200 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: <4691590B.4000000@mvps.org> Arthur, You mean a desktop shortcut? I think you can just specify which installation of Msaccess.exe you want to use. I.e. in the Target setting of the shortcut's Properties, something like this... "C:\Program Files\Microsoft Office\Office9\Msaccess.exe" "C:\YourFolder\YourApp.mdb" Regards Steve Arthur Fuller wrote: > I scouted the archives but didn't locate what I want, which is to create a > shortcut that knows that I want to load this particular MDB | ADP using > Access 2000, not Access 2003 or Access 2007. > > TIA, > Arthur From bill_patten at earthlink.net Sun Jul 8 16:39:05 2007 From: bill_patten at earthlink.net (Bill Patten) Date: Sun, 8 Jul 2007 14:39:05 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: Arthur, You need to know where Access 2K is located on the PC and put it in the path, like this "C:\Program Files (x86)\Microsoft Office XP\Office10\MSACCESS.EXE" "c:\program files\Mysoftware\mysoftware.MDB" If there are any spaces each must be in quotations marks. Bill ----- Original Message ----- From: "Arthur Fuller" To: "Access Developers discussion and problem solving" Sent: Sunday, July 08, 2007 2:14 PM Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From rusty.hammond at cpiqpc.com Sun Jul 8 16:50:46 2007 From: rusty.hammond at cpiqpc.com (rusty.hammond at cpiqpc.com) Date: Sun, 8 Jul 2007 16:50:46 -0500 Subject: [AccessD] Syntax for loading a specific version of Access Message-ID: <8301C8A868251E4C8ECD3D4FFEA40F8A2584BC3F@cpixchng-1.cpiqpc.net> Arthur, As long as they installed the version of office in the same folder across machines, or if you are putting the app on a single machine, adding the path to the desired exe file will work just fine. If you need a bit more dynamic approach FMS has a solution called Total Access Startup (www.fmsinc.com). I know the FMS products can be pricey but they work and I'm sure there are other programs out there that do the same thing. HTH, Rusty -----Original Message----- From: Bill Patten [mailto:bill_patten at earthlink.net] Sent: Sunday, July 08, 2007 4:39 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access Arthur, You need to know where Access 2K is located on the PC and put it in the path, like this "C:\Program Files (x86)\Microsoft Office XP\Office10\MSACCESS.EXE" "c:\program files\Mysoftware\mysoftware.MDB" If there are any spaces each must be in quotations marks. Bill ----- Original Message ----- From: "Arthur Fuller" To: "Access Developers discussion and problem solving" Sent: Sunday, July 08, 2007 2:14 PM Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, 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 ********************************************************************** WARNING: All e-mail sent to and from this address will be received, scanned or otherwise recorded by the CPI Qualified Plan Consultants, Inc. corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. ********************************************************************** From accessd at shaw.ca Sun Jul 8 17:18:53 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 08 Jul 2007 15:18:53 -0700 Subject: [AccessD] Access DB onlt read In-Reply-To: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: <0JKV003EVSF5NH58@l-daemon> Hi All: Sent a database to a client and now when they attempt to run certain code it displays the following message ''Run Time error 30267', cannot update database or object is read-only'. Within the problem module there are a number of tables created, cleared and re-populated within the code. The DB works just fine here. What could be wrong? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 08, 2007 2:14 PM To: Access Developers discussion and problem solving Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From joeo at appoli.com Sun Jul 8 17:23:45 2007 From: joeo at appoli.com (Joe O'Connell) Date: Sun, 8 Jul 2007 18:23:45 -0400 Subject: [AccessD] Access DB onlt read References: <0JKV003EVSF5NH58@l-daemon> Message-ID: If you sent it on a CD, it will be read only. Have the client change the file's protection. Right click on the file in Windows Explorer, select Properties. Uncheck the Attribute "Read-only". Joe O'Connell -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Sunday, July 08, 2007 6:19 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Access DB onlt read Hi All: Sent a database to a client and now when they attempt to run certain code it displays the following message ''Run Time error 30267', cannot update database or object is read-only'. Within the problem module there are a number of tables created, cleared and re-populated within the code. The DB works just fine here. What could be wrong? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 08, 2007 2:14 PM To: Access Developers discussion and problem solving Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, 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 accessd at shaw.ca Sun Jul 8 20:18:03 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 08 Jul 2007 18:18:03 -0700 Subject: [AccessD] Access DB onlt read In-Reply-To: Message-ID: <0JKW0062H0PRWVR3@l-daemon> Hi Joe: The file was sent by email but zipped. I have sent the client a list of things to try and your suggestion was the first option on the list. Nothing has come back yet... Thanks Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe O'Connell Sent: Sunday, July 08, 2007 3:24 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Access DB onlt read If you sent it on a CD, it will be read only. Have the client change the file's protection. Right click on the file in Windows Explorer, select Properties. Uncheck the Attribute "Read-only". Joe O'Connell -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Sunday, July 08, 2007 6:19 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Access DB onlt read Hi All: Sent a database to a client and now when they attempt to run certain code it displays the following message ''Run Time error 30267', cannot update database or object is read-only'. Within the problem module there are a number of tables created, cleared and re-populated within the code. The DB works just fine here. What could be wrong? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 08, 2007 2:14 PM To: Access Developers discussion and problem solving Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, 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 accessd666 at yahoo.com Mon Jul 9 01:54:54 2007 From: accessd666 at yahoo.com (Sad Der) Date: Sun, 8 Jul 2007 23:54:54 -0700 (PDT) Subject: [AccessD] Disable left-shift In-Reply-To: <002701c7bfc8$1b6ed040$d1b82ad1@SusanOne> Message-ID: <460215.12971.qm@web31605.mail.mud.yahoo.com> Yes, it was a blast haha. A nice suit alone can do it at the exec table...not for code ;-) --- Susan Harkins wrote: > Just goes to show that God really does have a sense > of humor, and a soft > spot for Access developers.;) > > Nicely done! > > Susan H. > > Hi, > > Just had a very nice moment :-). > "Hi Access guru: (people disgust Access around here) > Please test the new and > improved 250 hour costly SQL Server security > modification and see if you > can hack it." > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 From fuller.artful at gmail.com Mon Jul 9 09:08:02 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 9 Jul 2007 10:08:02 -0400 Subject: [AccessD] Current recordset and such Message-ID: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> Hi all, I am writing an Access app designed to replace a commercial app that the client now despises. I am trying to emulate all the cool features that she likes. Among them are a bunch of filter buttons on the form header (such as Age, Status, Balance, Skill Level and so on). All this works nicely. The datasheet form begins by showing all persons (in this case horse-riders). Then filters may be applied to the existing recordset. This is done with code that writes something into Me.Filter and sets FilterOn to True. There is also an option group whose options include Mark All, Find Marked and Unmark all. At the moment the first and third options use a stored procedure, but it addresses the whole table, not the filtered set. That's what I need to address. Perhaps a stored procedure is not the correct way, since a WHERE clause is tough to pass in. So perhaps an alternative is to use the RecordSet object, but I'm not quite sure how. Let's walk through a scenario. 1. Form displays all Riders. 2. User filters the list to include only Riders who are 12 years old. (List drops from 1000 to about 300.) 3. User clicks "Mark All". At the moment, because I'm firing a sproc against the table, all 1000 get marked (there is a column called Marked) rather than the 300 currently selected. I know what I need to do, I'm just shaky on how to manipulate the current recordset. What I need to do is something like this: Dim rs as ADODB.RecordSet bla bla bla Update rs SET Marked = True SET rs = Nothing Me.Requery It's the bla bla bla part that I'm unsure how to code. Next question: At the moment, exerting any of the filter options erases any previous filter. There is a button that clears all filters, but ideally I would like the filter mechanism to be additive. As described above, all I do currently is supply a string to the Filter property (such as "Age = 12" or "Status = 'Active'). I'm thinking that it would be much more powerful if I AND these filter strings. So that if the current filter is "Age = 12" and then I select the Status filter and set it to "Active", the resulting filter will be "Age = 12 and Status = 'Active'. OR is going to be a problem, however, but I can live without it. So, is this simply a case of appending the new filter spec to the old one with an AND in betwixt? I think so, but I thought I'd run it past you experts before coding it. Next question: Does there exist somewhere a list of the commands that appear on the Access menu? I have more than one reason for wanting such a list, but in the immediate context I want to create a button that does "Filter by Form". TIA, Arthur From rockysmolin at bchacc.com Mon Jul 9 09:29:12 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 9 Jul 2007 07:29:12 -0700 Subject: [AccessD] Current recordset and such In-Reply-To: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> Message-ID: <001901c7c235$8563bd70$0301a8c0@HAL9005> Since it's a bound set how about db.Execute "UPDATE....." etc.? I'm assuming the 'selected' check box on the form is bound to a 'selected' field in the bound recordset. I've done this for a custom app. I usually gen these update queries in the QBE grid, then copy the SQL from the SQL view. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 7:08 AM To: Access Developers discussion and problem solving Subject: [AccessD] Current recordset and such Hi all, I am writing an Access app designed to replace a commercial app that the client now despises. I am trying to emulate all the cool features that she likes. Among them are a bunch of filter buttons on the form header (such as Age, Status, Balance, Skill Level and so on). All this works nicely. The datasheet form begins by showing all persons (in this case horse-riders). Then filters may be applied to the existing recordset. This is done with code that writes something into Me.Filter and sets FilterOn to True. There is also an option group whose options include Mark All, Find Marked and Unmark all. At the moment the first and third options use a stored procedure, but it addresses the whole table, not the filtered set. That's what I need to address. Perhaps a stored procedure is not the correct way, since a WHERE clause is tough to pass in. So perhaps an alternative is to use the RecordSet object, but I'm not quite sure how. Let's walk through a scenario. 1. Form displays all Riders. 2. User filters the list to include only Riders who are 12 years old. (List drops from 1000 to about 300.) 3. User clicks "Mark All". At the moment, because I'm firing a sproc against the table, all 1000 get marked (there is a column called Marked) rather than the 300 currently selected. I know what I need to do, I'm just shaky on how to manipulate the current recordset. What I need to do is something like this: Dim rs as ADODB.RecordSet bla bla bla Update rs SET Marked = True SET rs = Nothing Me.Requery It's the bla bla bla part that I'm unsure how to code. Next question: At the moment, exerting any of the filter options erases any previous filter. There is a button that clears all filters, but ideally I would like the filter mechanism to be additive. As described above, all I do currently is supply a string to the Filter property (such as "Age = 12" or "Status = 'Active'). I'm thinking that it would be much more powerful if I AND these filter strings. So that if the current filter is "Age = 12" and then I select the Status filter and set it to "Active", the resulting filter will be "Age = 12 and Status = 'Active'. OR is going to be a problem, however, but I can live without it. So, is this simply a case of appending the new filter spec to the old one with an AND in betwixt? I think so, but I thought I'd run it past you experts before coding it. Next question: Does there exist somewhere a list of the commands that appear on the Access menu? I have more than one reason for wanting such a list, but in the immediate context I want to create a button that does "Filter by Form". TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM From Jim.Hale at FleetPride.com Mon Jul 9 09:51:11 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Mon, 9 Jul 2007 09:51:11 -0500 Subject: [AccessD] Current recordset and such In-Reply-To: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> References: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> Message-ID: How about using a pass through query that sends the built sql string to be executed? Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 9:08 AM To: Access Developers discussion and problem solving Subject: [AccessD] Current recordset and such Hi all, I am writing an Access app designed to replace a commercial app that the client now despises. I am trying to emulate all the cool features that she likes. Among them are a bunch of filter buttons on the form header (such as Age, Status, Balance, Skill Level and so on). All this works nicely. The datasheet form begins by showing all persons (in this case horse-riders). Then filters may be applied to the existing recordset. This is done with code that writes something into Me.Filter and sets FilterOn to True. There is also an option group whose options include Mark All, Find Marked and Unmark all. At the moment the first and third options use a stored procedure, but it addresses the whole table, not the filtered set. That's what I need to address. Perhaps a stored procedure is not the correct way, since a WHERE clause is tough to pass in. So perhaps an alternative is to use the RecordSet object, but I'm not quite sure how. Let's walk through a scenario. 1. Form displays all Riders. 2. User filters the list to include only Riders who are 12 years old. (List drops from 1000 to about 300.) 3. User clicks "Mark All". At the moment, because I'm firing a sproc against the table, all 1000 get marked (there is a column called Marked) rather than the 300 currently selected. I know what I need to do, I'm just shaky on how to manipulate the current recordset. What I need to do is something like this: Dim rs as ADODB.RecordSet bla bla bla Update rs SET Marked = True SET rs = Nothing Me.Requery It's the bla bla bla part that I'm unsure how to code. Next question: At the moment, exerting any of the filter options erases any previous filter. There is a button that clears all filters, but ideally I would like the filter mechanism to be additive. As described above, all I do currently is supply a string to the Filter property (such as "Age = 12" or "Status = 'Active'). I'm thinking that it would be much more powerful if I AND these filter strings. So that if the current filter is "Age = 12" and then I select the Status filter and set it to "Active", the resulting filter will be "Age = 12 and Status = 'Active'. OR is going to be a problem, however, but I can live without it. So, is this simply a case of appending the new filter spec to the old one with an AND in betwixt? I think so, but I thought I'd run it past you experts before coding it. Next question: Does there exist somewhere a list of the commands that appear on the Access menu? I have more than one reason for wanting such a list, but in the immediate context I want to create a button that does "Filter by Form". TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From cfoust at infostatsystems.com Mon Jul 9 09:53:00 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 07:53:00 -0700 Subject: [AccessD] Access Reports rinting accross In-Reply-To: <0JKS002C7TOOG3T1@l-daemon> References: <009e01c7bffd$f868b030$d1b82ad1@SusanOne> <0JKS002C7TOOG3T1@l-daemon> Message-ID: Check out snaking columns, across then down, and see if that would work for you. If the "record" is a single item, like a name, that would work. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Saturday, July 07, 2007 12:53 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Access Reports rinting accross Hi All: Is there a way to print across the page within an Access report? Like in the following example: Record01 record02 record03 record4 record5 Record06 record07 record08 record9 record10 record11 record12 record13 record14 record15 record16 record17 record18 record19 record20 etc......... MTIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon Jul 9 09:54:28 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 07:54:28 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: Are you talking about a "send to" or "open with" shortcut, Arthur? Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 08, 2007 2:14 PM To: Access Developers discussion and problem solving Subject: [AccessD] Syntax for loading a specific version of Access I scouted the archives but didn't locate what I want, which is to create a shortcut that knows that I want to load this particular MDB | ADP using Access 2000, not Access 2003 or Access 2007. TIA, Arthur -- 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 Jul 9 10:04:31 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 9 Jul 2007 11:04:31 -0400 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> Message-ID: <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> Open with. Things keep screwing up when I run the app on my box, which has every version of Access loaded since O97, but the default seems to be to load the latest. I want to tell the shortcut to load A2K and then the specific MDB|ADP in question. A. On 7/9/07, Charlotte Foust wrote: > > Are you talking about a "send to" or "open with" shortcut, Arthur? > > Charlotte Foust > From rockysmolin at bchacc.com Mon Jul 9 10:57:54 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 9 Jul 2007 08:57:54 -0700 Subject: [AccessD] Converting to MySql Message-ID: <003201c7c241$e9619de0$0301a8c0@HAL9005> Dear List: I have a request to make my manufacturing package compatible with MySql. I use some bound forms, and a lot of DAO. The app is split FE/BE with linked tables pointing to the BE. I also allow the user to select the BE they want so they can run multiple BEs if desired. What would be involved in doing this? Would it be enough of a rewrite that it would require a separate product? Or can the current product be made 'switchable' between an Access BE and a MySql BE? MTIA Rocky From cfoust at infostatsystems.com Mon Jul 9 11:07:48 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 09:07:48 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> Message-ID: Then I haven't a clue. I use the Send To shortcuts on my machines, so I can specify the precise version of Access to use. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 8:05 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access Open with. Things keep screwing up when I run the app on my box, which has every version of Access loaded since O97, but the default seems to be to load the latest. I want to tell the shortcut to load A2K and then the specific MDB|ADP in question. A. On 7/9/07, Charlotte Foust wrote: > > Are you talking about a "send to" or "open with" shortcut, Arthur? > > Charlotte Foust > -- 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 Jul 9 11:16:01 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 9 Jul 2007 12:16:01 -0400 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> Message-ID: <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so I > can specify the precise version of Access to use. > > Charlotte Foust > From cfoust at infostatsystems.com Mon Jul 9 11:47:58 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 09:47:58 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com><29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> Message-ID: Unless someone else has it at their fingertips, I'll check my laptop tonight. I never bothered to put it on this office machine, since I'm working with a single version of Access here. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 9:16 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so > I can specify the precise version of Access to use. > > Charlotte Foust > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon Jul 9 12:02:32 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 9 Jul 2007 10:02:32 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com><29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com><29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> Message-ID: OK, digging into my memory banks, locate the Send To folder on your machine. It's in different places in different Windows versions, so I can't tell you where. In XP its in the user profile in Documents and Settings and it's a hidden folder. Just add a shortcut with a replaceable parameter for each version of Access you run. Here's an old example: "D:\Program Files\Office2K\Office\MSACCESS.EXE" "%1" Rename each shortcut to indicate the version and they'll show up in your shortcut menus after that. There used to be a registry hack too, but I've lost track of that one. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 09, 2007 9:48 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access Unless someone else has it at their fingertips, I'll check my laptop tonight. I never bothered to put it on this office machine, since I'm working with a single version of Access here. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 9:16 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so > I can specify the precise version of Access to use. > > Charlotte Foust > -- 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 Mon Jul 9 12:17:06 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 09 Jul 2007 19:17:06 +0200 Subject: [AccessD] Current recordset and such Message-ID: Hi Arthur This is where DAO would come in as your speedy and extremely simple tool for your bound updatable form. Skip the stored procedure as well as reloading/requering the form by running code like this: Dim rst As DAO.Recordset Set rst = Forms!frmYourForm.RecordsetClone Debug.Print rst.RecordCount ' Apply your filter. rst.Filter = "Include = True" Set rst = rst.OpenRecordset rst.MoveLast Debug.Print rst.RecordCount With rst .MoveFirst While Not .EOF .Edit !YourField.Value = .Update .MoveNext Wend .Close End With Set rst = Nothing /gustav >>> fuller.artful at gmail.com 09-07-2007 16:08 >>> Hi all, I am writing an Access app designed to replace a commercial app that the client now despises. I am trying to emulate all the cool features that she likes. Among them are a bunch of filter buttons on the form header (such as Age, Status, Balance, Skill Level and so on). All this works nicely. The datasheet form begins by showing all persons (in this case horse-riders). Then filters may be applied to the existing recordset. This is done with code that writes something into Me.Filter and sets FilterOn to True. There is also an option group whose options include Mark All, Find Marked and Unmark all. At the moment the first and third options use a stored procedure, but it addresses the whole table, not the filtered set. That's what I need to address. Perhaps a stored procedure is not the correct way, since a WHERE clause is tough to pass in. So perhaps an alternative is to use the RecordSet object, but I'm not quite sure how. Let's walk through a scenario. 1. Form displays all Riders. 2. User filters the list to include only Riders who are 12 years old. (List drops from 1000 to about 300.) 3. User clicks "Mark All". At the moment, because I'm firing a sproc against the table, all 1000 get marked (there is a column called Marked) rather than the 300 currently selected. I know what I need to do, I'm just shaky on how to manipulate the current recordset. What I need to do is something like this: Dim rs as ADODB.RecordSet bla bla bla Update rs SET Marked = True SET rs = Nothing Me.Requery It's the bla bla bla part that I'm unsure how to code. Next question: At the moment, exerting any of the filter options erases any previous filter. There is a button that clears all filters, but ideally I would like the filter mechanism to be additive. As described above, all I do currently is supply a string to the Filter property (such as "Age = 12" or "Status = 'Active'). I'm thinking that it would be much more powerful if I AND these filter strings. So that if the current filter is "Age = 12" and then I select the Status filter and set it to "Active", the resulting filter will be "Age = 12 and Status = 'Active'. OR is going to be a problem, however, but I can live without it. So, is this simply a case of appending the new filter spec to the old one with an AND in betwixt? I think so, but I thought I'd run it past you experts before coding it. Next question: Does there exist somewhere a list of the commands that appear on the Access menu? I have more than one reason for wanting such a list, but in the immediate context I want to create a button that does "Filter by Form". TIA, Arthur -- From martyconnelly at shaw.ca Mon Jul 9 14:33:05 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Mon, 09 Jul 2007 12:33:05 -0700 Subject: [AccessD] Syntax for loading a specific version of Access In-Reply-To: <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> References: <29f585dd0707081414s305c272fl5bf7f79fa7a94eca@mail.gmail.com> <29f585dd0707090804l6178cd32r4f4dd3ebb4551e56@mail.gmail.com> <29f585dd0707090916y50b52de2t4182ec63e4541912@mail.gmail.com> Message-ID: <46928D71.8000101@shaw.ca> Here is how to setup the Open With. 1. Start Windows Explorer, 2. Select Tools and then Folder Options... 3. Click on the File Types Tab 4. Find the MDB file type 5. Click Advanced 6. Chances are there are 2 options. Open in bold font (denoting default) and New. You can pretty much add what you want here. For decompile, 7. Click New 8. Under action type Decompile 9. Under Application used to perform action type the equivalent for your install: "C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" /decompile "%1" 10 Click OK and exit out And wallah! You now right click an mdb and have the context option of decompiling it. But it doesn't stop there. For those of us juggling multiple versions of Access you can setup a right click option to open in each. Eg Open in 97 Open in 2000 Open in XP And make sure the path points to the correct version of access. Look up the paths first and store in notepad you are going to cut and paste them in the New edit Also I hope they have changed the Access 2007 icon otherwise it may look like the Access 2003 icon. Arthur Fuller wrote: >That might do, Charlotte. Tell me how to do that and I'll try it out. > >A. > > >On 7/9/07, Charlotte Foust wrote: > > >>Then I haven't a clue. I use the Send To shortcuts on my machines, so I >>can specify the precise version of Access to use. >> >>Charlotte Foust >> >> >> -- Marty Connelly Victoria, B.C. Canada From miscellany at mvps.org Mon Jul 9 15:16:18 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 10 Jul 2007 08:16:18 +1200 Subject: [AccessD] Converting to MySql In-Reply-To: <003201c7c241$e9619de0$0301a8c0@HAL9005> References: <003201c7c241$e9619de0$0301a8c0@HAL9005> Message-ID: <46929792.5040101@mvps.org> Rocky, I have not done this from the point of view of MySQL database as either/or to Jet database. But I have a couple of apps that link to MySQL tables *and* Jet tables, and transfer data one to the other via Update queries or Append queries etc. The link to the MySQL database is via ODBC, so you need the appropriate MySQL ODBC driver installed, and the creation of a DSN (well, I think you can do it dsn-less as well). So I imagine what you are trying would be reasonably easy. If the user chooses the MySQL BE, then delete the linked Jet tables, and create the links to the MySQL tables. Here is a sample of the code I have used to link to MySQL talbes: Dim dbs As DAO.Database Dim tdf As DAO.TableDef Dim tblName As String Dim srcTblName As String Dim Conn As String Set dbs = CurrentDb tblName = "NameYouWantTheTableToHaveLocally" srcTblName = "NameOfTheMySQLTableToLinkTo" Conn = "ODBC;DATABASE=NameOfMySQLDatabase;DESCRIPTION=description;DSN=NameOfDSN;OPTION=0;PORT=3306;SERVER=NameOfServer;;TABLE=NameOfTheMySQLTableToLinkTo" Set tdf = dbs.CreateTableDef(tblName) tdf.SourceTableName = srcTblName tdf.Connect = Conn dbs.TableDefs.Append tdf dbs.TableDefs.Refresh I guess one potential hiccup could be the use of non-corresponding data types. Regards Steve Rocky Smolin at Beach Access Software wrote: > Dear List: > > I have a request to make my manufacturing package compatible with MySql. I > use some bound forms, and a lot of DAO. The app is split FE/BE with linked > tables pointing to the BE. I also allow the user to select the BE they want > so they can run multiple BEs if desired. > > What would be involved in doing this? Would it be enough of a rewrite that > it would require a separate product? Or can the current product be made > 'switchable' between an Access BE and a MySql BE? From rockysmolin at bchacc.com Mon Jul 9 18:18:57 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 9 Jul 2007 16:18:57 -0700 Subject: [AccessD] Converting to MySql In-Reply-To: <46929792.5040101@mvps.org> Message-ID: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> Steve: Thanks for the snip. Raises a few more questions than it answers. Like how does the user know the Server Name. San with the DNS. And I suppose I'd have to prompt for those values. Most of my users are not very adept with computers, although in a company using MySql would I expect to find a DBA on staff? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Monday, July 09, 2007 1:16 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Converting to MySql Rocky, I have not done this from the point of view of MySQL database as either/or to Jet database. But I have a couple of apps that link to MySQL tables *and* Jet tables, and transfer data one to the other via Update queries or Append queries etc. The link to the MySQL database is via ODBC, so you need the appropriate MySQL ODBC driver installed, and the creation of a DSN (well, I think you can do it dsn-less as well). So I imagine what you are trying would be reasonably easy. If the user chooses the MySQL BE, then delete the linked Jet tables, and create the links to the MySQL tables. Here is a sample of the code I have used to link to MySQL talbes: Dim dbs As DAO.Database Dim tdf As DAO.TableDef Dim tblName As String Dim srcTblName As String Dim Conn As String Set dbs = CurrentDb tblName = "NameYouWantTheTableToHaveLocally" srcTblName = "NameOfTheMySQLTableToLinkTo" Conn = "ODBC;DATABASE=NameOfMySQLDatabase;DESCRIPTION=description;DSN=NameOfDSN;OPT ION=0;PORT=3306;SERVER=NameOfServer;;TABLE=NameOfTheMySQLTableToLinkTo" Set tdf = dbs.CreateTableDef(tblName) tdf.SourceTableName = srcTblName tdf.Connect = Conn dbs.TableDefs.Append tdf dbs.TableDefs.Refresh I guess one potential hiccup could be the use of non-corresponding data types. Regards Steve Rocky Smolin at Beach Access Software wrote: > Dear List: > > I have a request to make my manufacturing package compatible with > MySql. I use some bound forms, and a lot of DAO. The app is split > FE/BE with linked tables pointing to the BE. I also allow the user to > select the BE they want so they can run multiple BEs if desired. > > What would be involved in doing this? Would it be enough of a rewrite > that it would require a separate product? Or can the current product > be made 'switchable' between an Access BE and a MySql BE? -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM From greg at worthey.com Mon Jul 9 18:49:20 2007 From: greg at worthey.com (Greg Worthey) Date: Mon, 9 Jul 2007 16:49:20 -0700 Subject: [AccessD] MS Sql In-Reply-To: Message-ID: <000001c7c283$c95eb540$1701a8c0@fb2a618> Rocky, I've worked with mysql. Just use myodbc driver to connect to backend, like you would link to ms sql server. Pretty easy to set up. To make it switchable, I haven't tried that, but I think that wouldn't be too hard. Greg Worthey Worthey Solutions www.worthey.com -----Original Message----- Message: 17 Date: Mon, 9 Jul 2007 08:57:54 -0700 From: "Rocky Smolin at Beach Access Software" Subject: [AccessD] Converting to MySql To: "'Access Developers discussion and problem solving'" Message-ID: <003201c7c241$e9619de0$0301a8c0 at HAL9005> Content-Type: text/plain; charset="US-ASCII" Dear List: I have a request to make my manufacturing package compatible with MySql. I use some bound forms, and a lot of DAO. The app is split FE/BE with linked tables pointing to the BE. I also allow the user to select the BE they want so they can run multiple BEs if desired. What would be involved in doing this? Would it be enough of a rewrite that it would require a separate product? Or can the current product be made 'switchable' between an Access BE and a MySql BE? MTIA Rocky ------------------------------ Message: 18 Date: Mon, 9 Jul 2007 09:07:48 -0700 From: "Charlotte Foust" Subject: Re: [AccessD] Syntax for loading a specific version of Access To: "Access Developers discussion and problem solving" Message-ID: Content-Type: text/plain; charset="us-ascii" Then I haven't a clue. I use the Send To shortcuts on my machines, so I can specify the precise version of Access to use. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 8:05 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access Open with. Things keep screwing up when I run the app on my box, which has every version of Access loaded since O97, but the default seems to be to load the latest. I want to tell the shortcut to load A2K and then the specific MDB|ADP in question. A. On 7/9/07, Charlotte Foust wrote: > > Are you talking about a "send to" or "open with" shortcut, Arthur? > > Charlotte Foust > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com ------------------------------ Message: 19 Date: Mon, 9 Jul 2007 12:16:01 -0400 From: "Arthur Fuller" Subject: Re: [AccessD] Syntax for loading a specific version of Access To: "Access Developers discussion and problem solving" Message-ID: <29f585dd0707090916y50b52de2t4182ec63e4541912 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so I > can specify the precise version of Access to use. > > Charlotte Foust > ------------------------------ Message: 20 Date: Mon, 9 Jul 2007 09:47:58 -0700 From: "Charlotte Foust" Subject: Re: [AccessD] Syntax for loading a specific version of Access To: "Access Developers discussion and problem solving" Message-ID: Content-Type: text/plain; charset="us-ascii" Unless someone else has it at their fingertips, I'll check my laptop tonight. I never bothered to put it on this office machine, since I'm working with a single version of Access here. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 09, 2007 9:16 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Syntax for loading a specific version of Access That might do, Charlotte. Tell me how to do that and I'll try it out. A. On 7/9/07, Charlotte Foust wrote: > > Then I haven't a clue. I use the Send To shortcuts on my machines, so > I can specify the precise version of Access to use. > > Charlotte Foust > -- 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 End of AccessD Digest, Vol 53, Issue 15 *************************************** From miscellany at mvps.org Mon Jul 9 18:53:22 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 10 Jul 2007 11:53:22 +1200 Subject: [AccessD] Converting to MySql In-Reply-To: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> References: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> Message-ID: <4692CA72.2000300@mvps.org> Hi Rocky, I can't advise on doing this without a DSN, as I have never tried it. If you use a DSN, is has to be created on the PC. You would get the MySQL ODBC driver, and install it on the PC. This driver is free, and easily found on the internet. On a Windows XP PC, you create the DSN via: Start Control Panel Administrative Tools Data Sources (ODBC) (tab) System DSN Add... MySQL ODBC 3.51 Driver I would say that yes, this would probably need to be done by an admin, or on advice by someone who knows what to do. You need the name of the server. In my case, the MySQL databases are on hosted web servers, and I got the details of server name, user, password, and database name, from the web hosting service. Your situation may be different, in which case I am unable to advise, I've only done this a couple of times, it was easy and works sweet. Regards Steve Rocky Smolin at Beach Access Software wrote: > Steve: > > Thanks for the snip. Raises a few more questions than it answers. Like how > does the user know the Server Name. San with the DNS. And I suppose I'd > have to prompt for those values. > > Most of my users are not very adept with computers, although in a company > using MySql would I expect to find a DBA on staff? > From miscellany at mvps.org Mon Jul 9 18:56:06 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 10 Jul 2007 11:56:06 +1200 Subject: [AccessD] Converting to MySql In-Reply-To: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> References: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> Message-ID: <4692CB16.6070808@mvps.org> Rocky, Rocky Smolin at Beach Access Software wrote: > ... I suppose I'd > have to prompt for those values. No, once you have the DSN set up, you can hard-wire these values into your code. Regards Steve From rockysmolin at bchacc.com Mon Jul 9 19:14:44 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 9 Jul 2007 17:14:44 -0700 Subject: [AccessD] Converting to MySql In-Reply-To: <4692CB16.6070808@mvps.org> Message-ID: <005501c7c287$51b3cd60$0301a8c0@HAL9005> This is a distributable product. Do you think it would be better to force the end user to use my hard-wired DSN or allow them to create their own and prompt? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Monday, July 09, 2007 4:56 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Converting to MySql Rocky, Rocky Smolin at Beach Access Software wrote: > ... I suppose I'd > have to prompt for those values. No, once you have the DSN set up, you can hard-wire these values into your code. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM From bhjohnson at verizon.net Mon Jul 9 19:18:51 2007 From: bhjohnson at verizon.net (Bruce H. Johnson) Date: Mon, 09 Jul 2007 17:18:51 -0700 Subject: [AccessD] Converting to MySql In-Reply-To: <4692CA72.2000300@mvps.org> References: <004e01c7c27f$86cceac0$0301a8c0@HAL9005> <4692CA72.2000300@mvps.org> Message-ID: <001b01c7c287$e4cbbf40$0201a8c0@HALSR> If you do an install on the client's PC for the front end, you can easily make the DNS entries as part of it. Most of it is registry entries; take a working one and duplicate it. I did a set of DSNs for a local Access database, an AS400 and an SQL server and was able to change the SQL and AS400 DSNs on the fly to flip between production and testing databases. Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Monday, July 09, 2007 4:53 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Converting to MySql Hi Rocky, I can't advise on doing this without a DSN, as I have never tried it. If you use a DSN, is has to be created on the PC. You would get the MySQL ODBC driver, and install it on the PC. This driver is free, and easily found on the internet. On a Windows XP PC, you create the DSN via: Start Control Panel Administrative Tools Data Sources (ODBC) (tab) System DSN Add... MySQL ODBC 3.51 Driver I would say that yes, this would probably need to be done by an admin, or on advice by someone who knows what to do. You need the name of the server. In my case, the MySQL databases are on hosted web servers, and I got the details of server name, user, password, and database name, from the web hosting service. Your situation may be different, in which case I am unable to advise, I've only done this a couple of times, it was easy and works sweet. Regards Steve Rocky Smolin at Beach Access Software wrote: > Steve: > > Thanks for the snip. Raises a few more questions than it answers. Like how > does the user know the Server Name. San with the DNS. And I suppose I'd > have to prompt for those values. > > Most of my users are not very adept with computers, although in a company > using MySql would I expect to find a DBA on staff? > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 7/8/2007 6:32 PM From jwelz at hotmail.com Mon Jul 9 19:25:38 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Mon, 09 Jul 2007 18:25:38 -0600 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: I don't understand the comment about 'goofiness' with callbacks and debug I use callbacks more often than not and have never had a problem with breaking into code. I've said before what I say again below, and it needs to be repeated. My concern with unbound forms is the scenario where two users open the same record and each performs an edit. Generally, unbound edits are written when the form closed or unloads. In such a case, the last user to close 'wins' and the first user's eits are lost without notice. In the environments where I have worked, we frequently have multiple users working in a single record. User 'A' will open the record to update an address. User 'B' will open the record to update a contract value field. User 'B' will close the record and his edit is writen to the table. User 'A' answers the phone and closes the record a moment later and the database is updated with the current unbound form data. The record has the updated address but the change to the contract value is lost and no one is warned. Sure you can write code to handle the situation. For example, you could update only edited fields and the overwrite will only happen if two users concurrently edit the same field to different values. Or you could add an edit flag and update it anytime a user has a pending edit and clear it when the record closes. But I believe Drew said earlier that since it's a Jet BE, there is no difference bound or unbound in regard to locking. With a bound form, you can get a notification that another user has edited the record and gives 'A' the option to abandon the edit. My users see this message with a degree of regularity and they have been taught always to drop their edits, reopen the record and then redo any required edits. I have seen many unbound databases created by reasonably competent Access developers who blithely ignore this issue. They don't mention the additional things that need to be done in order to ensure data integrity. I am not adverse to unbound forms and use them where appropriate. If a person is in a web driven database where a user may have a personal shopping cart and need to log in to access his cart, no problem with unbound. If you take appropriate steps to ensure the integirty of the data, no problem. My primary reason for working unbound has been the formatting limitations of bound controls in continuous forms and my environment has never permitted 3rd party controls. I've heard reference to 'boundaries' or limitations of bound forms but still manage to use them without compromising the user interface. You can even populate a bound form with a series of values that did not exist in any table. Some people assume that a bound form contains as many records as some table to which a form is bound, but all of my parent forms are populated by a single record determined by a primary key parameter. The recordset is determined in the open event and the recordsource property is empty. It is just as fast as unbound, and faster than unbound that includes the setting of edit flags. I have 47 concurrent users today and among the only unbound forms I use today are a few that allow drag and drop of categories of employees (4 categories, 4 colours in 4 columns, each its own subform) onto and from a list of projects, and the dragged employees drop in to a subform of projects containing sublists of employees that retain their formatting where dropped. I counln't figure out how to intersperse the types of records with their various colours in a bound form. And of course forms for search, report selection, navigation, calculations, calendars and such ancilliary forms that do not need to update their own values. 47 users, Access 2003, Access 2000 format, nearly entirely bound and no reports of data conflicts that shouldn't be reported. I anticipate more users in the coming months and see no difference between the bound and unbound approach in terms of locked data pages, indexes or corruptions because my recordsets are tiny compared to the tables and rarely, but occasionally, involve concurrent edits. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Drew Wutka" > >But Access is just as well suited for unbound solutions too. The only >exception to that rule is it's goofiness with callback routines. (Can't >go into debug if you have a callback routine ANYWHERE. Goes haywire). > >Drew _________________________________________________________________ http://liveearth.msn.com From DWUTKA at Marlow.com Mon Jul 9 20:26:18 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 9 Jul 2007 20:26:18 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: A little clarification on the 'callback' issue. I am NOT referring to the callback capabilities of Access list and combo boxes. What I am referring too is API call backs. For example, if you want to enumerate all of the windows on your machine, you call the EnumWindows API, and in that call, you give it the address of your callback routine, using AddressOf. In 97, there was not a native AddressOf function, there was one available on the web that worked great. In 2000 and later (with VBA being a subset of VB 6, instead of VB 5), AddressOf became available as a native function. However, if you have a function that uses this, and it has run (doesn't need to still be running), if you go into the code in debug mode.....zap, everything locks up. I know that was the case in 2000, and I'm 99% sure it does the same thing in 2003 (never had 2002). As for what you posted about simultaneous data 'editing', here's my take on this. I know there are times when an application may run into this, but with good developing, this situation can be very easily avoided. I can't think of a single application I have written that would have two people updating the same record. First, I normalize out the data. So, in your example, one person may be changing an address, while another edits a 'contract value' field, in both cases, the users would be using different tables. Also, when I have a class structure built, if I am even remotely worried that two people can edit a record at the same time, I have the class only update the fields that have been changed. That is something you can't do with a bound found. So if one person changes someone's first name, and one person changes someone's last name, my class will only change the first name for the first person, and last name for the second person. Smooth as silk. In that same process, data integrity can be checked, so if there is a clash on the exact same field, it can warn the user. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Monday, July 09, 2007 7:26 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? I don't understand the comment about 'goofiness' with callbacks and debug I use callbacks more often than not and have never had a problem with breaking into code. I've said before what I say again below, and it needs to be repeated. My concern with unbound forms is the scenario where two users open the same record and each performs an edit. Generally, unbound edits are written when the form closed or unloads. In such a case, the last user to close 'wins' and the first user's eits are lost without notice. In the environments where I have worked, we frequently have multiple users working in a single record. User 'A' will open the record to update an address. User 'B' will open the record to update a contract value field. User 'B' will close the record and his edit is writen to the table. User 'A' answers the phone and closes the record a moment later and the database is updated with the current unbound form data. The record has the updated address but the change to the contract value is lost and no one is warned. Sure you can write code to handle the situation. For example, you could update only edited fields and the overwrite will only happen if two users concurrently edit the same field to different values. Or you could add an edit flag and update it anytime a user has a pending edit and clear it when the record closes. But I believe Drew said earlier that since it's a Jet BE, there is no difference bound or unbound in regard to locking. With a bound form, you can get a notification that another user has edited the record and gives 'A' the option to abandon the edit. My users see this message with a degree of regularity and they have been taught always to drop their edits, reopen the record and then redo any required edits. I have seen many unbound databases created by reasonably competent Access developers who blithely ignore this issue. They don't mention the additional things that need to be done in order to ensure data integrity. I am not adverse to unbound forms and use them where appropriate. If a person is in a web driven database where a user may have a personal shopping cart and need to log in to access his cart, no problem with unbound. If you take appropriate steps to ensure the integirty of the data, no problem. My primary reason for working unbound has been the formatting limitations of bound controls in continuous forms and my environment has never permitted 3rd party controls. I've heard reference to 'boundaries' or limitations of bound forms but still manage to use them without compromising the user interface. You can even populate a bound form with a series of values that did not exist in any table. Some people assume that a bound form contains as many records as some table to which a form is bound, but all of my parent forms are populated by a single record determined by a primary key parameter. The recordset is determined in the open event and the recordsource property is empty. It is just as fast as unbound, and faster than unbound that includes the setting of edit flags. I have 47 concurrent users today and among the only unbound forms I use today are a few that allow drag and drop of categories of employees (4 categories, 4 colours in 4 columns, each its own subform) onto and from a list of projects, and the dragged employees drop in to a subform of projects containing sublists of employees that retain their formatting where dropped. I counln't figure out how to intersperse the types of records with their various colours in a bound form. And of course forms for search, report selection, navigation, calculations, calendars and such ancilliary forms that do not need to update their own values. 47 users, Access 2003, Access 2000 format, nearly entirely bound and no reports of data conflicts that shouldn't be reported. I anticipate more users in the coming months and see no difference between the bound and unbound approach in terms of locked data pages, indexes or corruptions because my recordsets are tiny compared to the tables and rarely, but occasionally, involve concurrent edits. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Drew Wutka" > >But Access is just as well suited for unbound solutions too. The only >exception to that rule is it's goofiness with callback routines. (Can't >go into debug if you have a callback routine ANYWHERE. Goes haywire). > >Drew _________________________________________________________________ http://liveearth.msn.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwelz at hotmail.com Mon Jul 9 22:02:03 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Mon, 09 Jul 2007 21:02:03 -0600 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: Drew: I'm familiar with the 'use at your own risk' 'AddressOf' function since the days of Access97 at 'The Access Web' of Dev Ashish, but this is not the sense in which most Access programmers ordinarily are familiar with callback functions. Of couse the whole callback thing has little bearing on the initial question about performance tips or on the question of bound or unbound. I still haven't seen an explanation of how unbound is inherently faster than bound. I've heard discussion about being able to do certain kinds of things unbound that can't be done bound and have given a couple examples myslef. I still don't see how it provides additional performance so don't understand in what sense proposing it is an answer to the question. There is also little sense in making the assumption that everyone is a good developer and is aware of the issues that may come with losing record locking. It is irresponsible to say that jet looks after record locking, no difference, bound or unbound. You can't advocate something that will undoubtedly hurt people if you don't mention the caveats. What constitutes 'good developing' depends on a number of factors. In terms of performance, a degree of denormalization may be good thing as it can cut down the number of joins to be processed. In the database from which I drew the contract value/address example, we never had identical addresses for multiple projects. Sure we have addresses for various kinds of entities and they could be stored in a single table, but placing all the addresses in a separate table would have resulted in a table with a much larger number of records that would have to be hit to populate a record fore each kind of entity. Querying for any kind of related record by address, that would be possible by normalizing, was of no advantage in this database. Worse yet, the physical address of a project never changes, but if you join that address to a company and some bright bulb changes the address of the company when it moves rather than adding a new address and 'deactivating' or date ranging the validity of the address, the edit to the address changes the AddressOf (pun intended) the project. In the example I gave, both the contract value and the addresses were appropriate characteristics of the project. I've also gotten performance gains out of mapping data to bit flags; another normalization no no. Callback functions are very useful to me in cases where I do use foreign keys as I frequently fill a combo or list from an array and avoid a hit on the database. In addition to what Colby calls JIT sub forms, together with limiting the data to only needed data, you can do the same thing with combos, displaying a text value in a delimited list and converting to an SQL rowsource on GotFocus provided you store the text value in the table together with the FK. One of the slower built in functions in Access is the CurrentDb function and it can crawl when called in a loop. I use a function that keeps a static variable that points to a database object and returns a reference to that object. The database for which this question was asked is large in terms of numbers of objects. CurrentDb forces a refresh of all the database objects so I use an optional parameter that allows me to specify should I need to refresh the collection. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Drew Wutka" > >A little clarification on the 'callback' issue. I am NOT referring to the >callback capabilities of Access list and combo boxes. What I am referring >too is API call backs. For example, if you want to enumerate all of the >windows on your machine, you call the EnumWindows API, and in that call, >you give it the address of your callback routine, using AddressOf. In 97, >there was not a native AddressOf function, there was one available on the >web that worked great. In 2000 and later (with VBA being a subset of VB 6, >instead of VB 5), AddressOf became available as a native function. > >However, if you have a function that uses this, and it has run (doesn't >need to still be running), if you go into the code in debug mode.....zap, >everything locks up. I know that was the case in 2000, and I'm 99% sure it >does the same thing in 2003 (never had 2002). > >As for what you posted about simultaneous data 'editing', here's my take on >this. I know there are times when an application may run into this, but >with good developing, this situation can be very easily avoided. I can't >think of a single application I have written that would have two people >updating the same record. First, I normalize out the data. So, in your >example, one person may be changing an address, while another edits a >'contract value' field, in both cases, the users would be using different >tables. Also, when I have a class structure built, if I am even remotely >worried that two people can edit a record at the same time, I have the >class only update the fields that have been changed. That is something you >can't do with a bound found. So if one person changes someone's first >name, and one person changes someone's last name, my class will only change >the first name for the first person, and last name for the second person. >Smooth as silk. In that same process, data integrity can be checked, so if >there is a clash on the exact same field, it can warn the user. > >Drew > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Monday, July 09, 2007 7:26 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Performance tips anyone? > >I don't understand the comment about 'goofiness' with callbacks and debug >I >use callbacks more often than not and have never had a problem with >breaking >into code. > >I've said before what I say again below, and it needs to be repeated. > >My concern with unbound forms is the scenario where two users open the same >record and each performs an edit. Generally, unbound edits are written >when >the form closed or unloads. In such a case, the last user to close 'wins' >and the first user's eits are lost without notice. In the environments >where I have worked, we frequently have multiple users working in a single >record. User 'A' will open the record to update an address. User 'B' will >open the record to update a contract value field. User 'B' will close the >record and his edit is writen to the table. User 'A' answers the phone and >closes the record a moment later and the database is updated with the >current unbound form data. The record has the updated address but the >change to the contract value is lost and no one is warned. > >Sure you can write code to handle the situation. For example, you could >update only edited fields and the overwrite will only happen if two users >concurrently edit the same field to different values. Or you could add an >edit flag and update it anytime a user has a pending edit and clear it when >the record closes. But I believe Drew said earlier that since it's a Jet >BE, there is no difference bound or unbound in regard to locking. With a >bound form, you can get a notification that another user has edited the >record and gives 'A' the option to abandon the edit. My users see this >message with a degree of regularity and they have been taught always to >drop >their edits, reopen the record and then redo any required edits. > >I have seen many unbound databases created by reasonably competent Access >developers who blithely ignore this issue. They don't mention the >additional things that need to be done in order to ensure data integrity. >I >am not adverse to unbound forms and use them where appropriate. If a >person >is in a web driven database where a user may have a personal shopping cart >and need to log in to access his cart, no problem with unbound. If you >take >appropriate steps to ensure the integirty of the data, no problem. > >My primary reason for working unbound has been the formatting limitations >of >bound controls in continuous forms and my environment has never permitted >3rd party controls. I've heard reference to 'boundaries' or limitations of >bound forms but still manage to use them without compromising the user >interface. You can even populate a bound form with a series of values that >did not exist in any table. > >Some people assume that a bound form contains as many records as some table >to which a form is bound, but all of my parent forms are populated by a >single record determined by a primary key parameter. The recordset is >determined in the open event and the recordsource property is empty. It is >just as fast as unbound, and faster than unbound that includes the setting >of edit flags. I have 47 concurrent users today and among the only unbound >forms I use today are a few that allow drag and drop of categories of >employees (4 categories, 4 colours in 4 columns, each its own subform) onto >and from a list of projects, and the dragged employees drop in to a subform >of projects containing sublists of employees that retain their formatting >where dropped. I counln't figure out how to intersperse the types of >records with their various colours in a bound form. And of course forms >for >search, report selection, navigation, calculations, calendars and such >ancilliary forms that do not need to update their own values. > >47 users, Access 2003, Access 2000 format, nearly entirely bound and no >reports of data conflicts that shouldn't be reported. I anticipate more >users in the coming months and see no difference between the bound and >unbound approach in terms of locked data pages, indexes or corruptions >because my recordsets are tiny compared to the tables and rarely, but >occasionally, involve concurrent edits. > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > > > > > > >From: "Drew Wutka" > > > >But Access is just as well suited for unbound solutions too. The only > >exception to that rule is it's goofiness with callback routines. (Can't > >go into debug if you have a callback routine ANYWHERE. Goes haywire). > > > >Drew _________________________________________________________________ New Windows Live Hotmail is here. Upgrade for free and get a better look. www.newhotmail.ca?icid=WLHMENCA150 From jwcolby at colbyconsulting.com Mon Jul 9 23:18:44 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 10 Jul 2007 00:18:44 -0400 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: <20070710041911.A6797BE11@smtp-auth.no-ip.com> Hey Jurgen, long time no see. Welcome back. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Monday, July 09, 2007 8:26 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? I don't understand the comment about 'goofiness' with callbacks and debug I use callbacks more often than not and have never had a problem with breaking into code. I've said before what I say again below, and it needs to be repeated. My concern with unbound forms is the scenario where two users open the same record and each performs an edit. Generally, unbound edits are written when the form closed or unloads. In such a case, the last user to close 'wins' and the first user's eits are lost without notice. In the environments where I have worked, we frequently have multiple users working in a single record. User 'A' will open the record to update an address. User 'B' will open the record to update a contract value field. User 'B' will close the record and his edit is writen to the table. User 'A' answers the phone and closes the record a moment later and the database is updated with the current unbound form data. The record has the updated address but the change to the contract value is lost and no one is warned. Sure you can write code to handle the situation. For example, you could update only edited fields and the overwrite will only happen if two users concurrently edit the same field to different values. Or you could add an edit flag and update it anytime a user has a pending edit and clear it when the record closes. But I believe Drew said earlier that since it's a Jet BE, there is no difference bound or unbound in regard to locking. With a bound form, you can get a notification that another user has edited the record and gives 'A' the option to abandon the edit. My users see this message with a degree of regularity and they have been taught always to drop their edits, reopen the record and then redo any required edits. I have seen many unbound databases created by reasonably competent Access developers who blithely ignore this issue. They don't mention the additional things that need to be done in order to ensure data integrity. I am not adverse to unbound forms and use them where appropriate. If a person is in a web driven database where a user may have a personal shopping cart and need to log in to access his cart, no problem with unbound. If you take appropriate steps to ensure the integirty of the data, no problem. My primary reason for working unbound has been the formatting limitations of bound controls in continuous forms and my environment has never permitted 3rd party controls. I've heard reference to 'boundaries' or limitations of bound forms but still manage to use them without compromising the user interface. You can even populate a bound form with a series of values that did not exist in any table. Some people assume that a bound form contains as many records as some table to which a form is bound, but all of my parent forms are populated by a single record determined by a primary key parameter. The recordset is determined in the open event and the recordsource property is empty. It is just as fast as unbound, and faster than unbound that includes the setting of edit flags. I have 47 concurrent users today and among the only unbound forms I use today are a few that allow drag and drop of categories of employees (4 categories, 4 colours in 4 columns, each its own subform) onto and from a list of projects, and the dragged employees drop in to a subform of projects containing sublists of employees that retain their formatting where dropped. I counln't figure out how to intersperse the types of records with their various colours in a bound form. And of course forms for search, report selection, navigation, calculations, calendars and such ancilliary forms that do not need to update their own values. 47 users, Access 2003, Access 2000 format, nearly entirely bound and no reports of data conflicts that shouldn't be reported. I anticipate more users in the coming months and see no difference between the bound and unbound approach in terms of locked data pages, indexes or corruptions because my recordsets are tiny compared to the tables and rarely, but occasionally, involve concurrent edits. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Drew Wutka" > >But Access is just as well suited for unbound solutions too. The only >exception to that rule is it's goofiness with callback routines. (Can't >go into debug if you have a callback routine ANYWHERE. Goes haywire). > >Drew _________________________________________________________________ http://liveearth.msn.com From miscellany at mvps.org Mon Jul 9 23:44:43 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 10 Jul 2007 16:44:43 +1200 Subject: [AccessD] Converting to MySql In-Reply-To: <005501c7c287$51b3cd60$0301a8c0@HAL9005> References: <005501c7c287$51b3cd60$0301a8c0@HAL9005> Message-ID: <46930EBB.3030303@mvps.org> Rocky, I don't think prompting them for the DSN parameters would be too good. It sounds like Bruce has got some clues about creating a DSN as part of your application installation. You would also have to include the installation of the ODBC driver as part of your installation as well. So perhaps you could explore further down that track, and maybe Bruce can provide some more specifics. Otherwise, you would have to give instructions to them to set up the DSN themselves - and those instructions would include them giving the same name etc to the DSN as the one you used. But then, I suppose the location of the MySQL database would be different for each user, so maybe you would have to set up a process for them to enter this in (server, password), and store it in a table, and get your code to refer to this. Sorry, I didn't realise it was a distributed application. This seems such a specific requirement, so I assumed it was part of a customised solution for a particular user. Regards Steve Rocky Smolin at Beach Access Software wrote: > This is a distributable product. Do you think it would be better to force > the end user to use my hard-wired DSN or allow them to create their own and > prompt? From adtp at airtelbroadband.in Mon Jul 9 23:04:54 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Tue, 10 Jul 2007 09:34:54 +0530 Subject: [AccessD] Access Reports rinting accross References: <0JKV00CB8JU1S4G9@l-daemon> Message-ID: <01d701c7c2b2$1b1fbae0$5357a27a@pcadt> You are most welcome Jim! A.D.Tejpal --------------- ----- Original Message ----- From: Jim Lawrence To: 'Access Developers discussion and problem solving' Sent: Monday, July 09, 2007 00:43 Subject: Re: [AccessD] Access Reports rinting accross Hi A. D. Tejal: A very eloquent solution. :-) A subreport of course can be used and I have not ruled out that option yet... One day Access reporting may provide the ability to set columns per Group Heading. Until then this will have to be the appropriate solution. Thanks you Jim << SNIPPED >> From fuller.artful at gmail.com Tue Jul 10 04:34:57 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 10 Jul 2007 05:34:57 -0400 Subject: [AccessD] Update the current recordset Message-ID: <29f585dd0707100234m5712b530u8c899514ff19d6b4@mail.gmail.com> I have continuous form that is a subform. On the parent form's header are some buttons and combo boxes that are used to filter the continuous subform. This all works fine. There's an option group that contains "Mark All", "Find Marked" and "Unmark All" options. When I first wrote it, "Mark All" applied to all the records in the table but I want it to be smarter than that. To wit, when you filter, say, by age, and select 20 as the age, then only a small subset of the total rows are shown. I want "Mark all" to apply to the subset not the whole table. The Marking is done using a column in the table called Marked. The first version invokes a stored procedure to mark and unmark all the records and it is amazingly quick. I thought that if I used the recordsetclone it would present only the filtered subset, but apparently that doesn't work. Here's the code I wrote: Sub MarkAllRecords() Dim rst As ADODB.Recordset With Me Set rst = .Riders_Browser_fsub.Form.RecordsetClone Do While Not rst.EOF rst.Fields("Marked") = -1 rst.Update Debug.Print rst("RiderID"), rst("Marked") rst.MoveNext Loop Debug.Print rst.RecordCount & " rows changed." rst.Close Set rst = Nothing End With End Sub This marks all the records in the table, not the filtered subset. How do I get a handle on just the subset? I suppose that I could use a SQL statement that specifies the current filter, which I shall try now, but I'm wondering why the code above doesn't work -- or rather, how to make it work. TIA, Arthur From Gustav at cactus.dk Tue Jul 10 05:48:30 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Tue, 10 Jul 2007 12:48:30 +0200 Subject: [AccessD] Update the current recordset Message-ID: Hi Arthur > This marks all the records in the table, not the filtered subset. > How do I get a handle on just the subset? Didn't you study the gems of my previous posting? The code included does exactly that: Set rst = Forms!frmYourForm.RecordsetClone Debug.Print rst.RecordCount ' Apply your filter. rst.Filter = "Include = True" Set rst = rst.OpenRecordset rst.MoveLast Debug.Print rst.RecordCount /gustav >>> fuller.artful at gmail.com 10-07-2007 11:34 >>> I have continuous form that is a subform. On the parent form's header are some buttons and combo boxes that are used to filter the continuous subform. This all works fine. There's an option group that contains "Mark All", "Find Marked" and "Unmark All" options. When I first wrote it, "Mark All" applied to all the records in the table but I want it to be smarter than that. To wit, when you filter, say, by age, and select 20 as the age, then only a small subset of the total rows are shown. I want "Mark all" to apply to the subset not the whole table. The Marking is done using a column in the table called Marked. The first version invokes a stored procedure to mark and unmark all the records and it is amazingly quick. I thought that if I used the recordsetclone it would present only the filtered subset, but apparently that doesn't work. Here's the code I wrote: Sub MarkAllRecords() Dim rst As ADODB.Recordset With Me Set rst = .Riders_Browser_fsub.Form.RecordsetClone Do While Not rst.EOF rst.Fields("Marked") = -1 rst.Update Debug.Print rst("RiderID"), rst("Marked") rst.MoveNext Loop Debug.Print rst.RecordCount & " rows changed." rst.Close Set rst = Nothing End With End Sub This marks all the records in the table, not the filtered subset. How do I get a handle on just the subset? I suppose that I could use a SQL statement that specifies the current filter, which I shall try now, but I'm wondering why the code above doesn't work -- or rather, how to make it work. TIA, Arthur From accessd666 at yahoo.com Tue Jul 10 06:37:42 2007 From: accessd666 at yahoo.com (Sad Der) Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) Subject: [AccessD] Upsize wizard => Queries Message-ID: <460545.53873.qm@web31611.mail.mud.yahoo.com> Hi group, Using the upgrade wizard I can migrate the tables and data in a couple of minutes to SQL Server. (Action) Queries are not migrated. Does anybody know of a tool that migrates queries to sql server views and/or sp's? TIA!!!! Regards, Sander ____________________________________________________________________________________ Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php From fuller.artful at gmail.com Tue Jul 10 07:26:00 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 10 Jul 2007 08:26:00 -0400 Subject: [AccessD] Writing to the Access status bar Message-ID: <29f585dd0707100526p316620b7i7e7dece2f48a9266@mail.gmail.com> Can someone point me in the right direction to write a message to the status bar? I've done it before but forgotten how. I know that it has something to do with acSysCmdSetStatus but that's all I can remember. TIA, Arthur From jwcolby at colbyconsulting.com Tue Jul 10 07:36:22 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 10 Jul 2007 08:36:22 -0400 Subject: [AccessD] Update the current recordset In-Reply-To: <29f585dd0707100234m5712b530u8c899514ff19d6b4@mail.gmail.com> Message-ID: <20070710123624.52451BDAE@smtp-auth.no-ip.com> First of all, using a field called "Marked" may cause multi-user issues. It definitely will in a bound form, because the records are live linked back to the table. If another user clears the marked flag for a record the current user is looking at... John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, July 10, 2007 5:35 AM To: Access Developers discussion and problem solving Subject: [AccessD] Update the current recordset I have continuous form that is a subform. On the parent form's header are some buttons and combo boxes that are used to filter the continuous subform. This all works fine. There's an option group that contains "Mark All", "Find Marked" and "Unmark All" options. When I first wrote it, "Mark All" applied to all the records in the table but I want it to be smarter than that. To wit, when you filter, say, by age, and select 20 as the age, then only a small subset of the total rows are shown. I want "Mark all" to apply to the subset not the whole table. The Marking is done using a column in the table called Marked. The first version invokes a stored procedure to mark and unmark all the records and it is amazingly quick. I thought that if I used the recordsetclone it would present only the filtered subset, but apparently that doesn't work. Here's the code I wrote: Sub MarkAllRecords() Dim rst As ADODB.Recordset With Me Set rst = .Riders_Browser_fsub.Form.RecordsetClone Do While Not rst.EOF rst.Fields("Marked") = -1 rst.Update Debug.Print rst("RiderID"), rst("Marked") rst.MoveNext Loop Debug.Print rst.RecordCount & " rows changed." rst.Close Set rst = Nothing End With End Sub This marks all the records in the table, not the filtered subset. How do I get a handle on just the subset? I suppose that I could use a SQL statement that specifies the current filter, which I shall try now, but I'm wondering why the code above doesn't work -- or rather, how to make it work. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd666 at yahoo.com Tue Jul 10 08:05:18 2007 From: accessd666 at yahoo.com (Sad Der) Date: Tue, 10 Jul 2007 06:05:18 -0700 (PDT) Subject: [AccessD] Writing to the Access status bar In-Reply-To: <29f585dd0707100526p316620b7i7e7dece2f48a9266@mail.gmail.com> Message-ID: <671421.18251.qm@web31606.mail.mud.yahoo.com> Hi Arthur, SysCmd acSysCmdSetStatus, "Elapsed Time: " & _ lngMin \ 60 & Format(lngMin Mod 60, "\:00") HTH Sander --- Arthur Fuller wrote: > Can someone point me in the right direction to write > a message to the status > bar? I've done it before but forgotten how. I know > that it has something to > do with acSysCmdSetStatus but that's all I can > remember. > > TIA, > Arthur > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From robert at webedb.com Tue Jul 10 08:21:35 2007 From: robert at webedb.com (Robert L. Stewart) Date: Tue, 10 Jul 2007 08:21:35 -0500 Subject: [AccessD] Upsize wizard => Queries In-Reply-To: References: Message-ID: <200707101325.l6ADPVPa023938@databaseadvisors.com> The syntax for the queries is too different to be migrated. You had to do that yourself. Or, you can change your default to be SQL-92 (I think) compliant. Then you can simply copy and paste the SQL between them. But, either way, you still have to do it yourself. Robert At 07:26 AM 7/10/2007, you wrote: >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) >From: Sad Der >Subject: [AccessD] Upsize wizard => Queries >To: Acces User Group >Message-ID: <460545.53873.qm at web31611.mail.mud.yahoo.com> >Content-Type: text/plain; charset=iso-8859-1 > >Hi group, > >Using the upgrade wizard I can migrate the tables and >data in a couple of minutes to SQL Server. > >(Action) Queries are not migrated. > >Does anybody know of a tool that migrates queries to >sql server views and/or sp's? > >TIA!!!! > >Regards, > >Sander From phpons at gmail.com Tue Jul 10 08:48:51 2007 From: phpons at gmail.com (philippe pons) Date: Tue, 10 Jul 2007 15:48:51 +0200 Subject: [AccessD] How to print a report? Message-ID: <57144ced0707100648v170b79fbvebb7d3af3a978506@mail.gmail.com> Hi all, I tried to print a report, but unsuccessfully till now! I need to print the report but prior to this I set it'sFilter property: Report_BULLETIN.Filter = "COLL_ID=" & Me.cboSelColl.Value Report_BULLETIN.FilterOn = True I discover I have to open the report and then set the Filter and FilterOn property. All is ok, I can see my filtered report. Now I want to print it. I user DoCmd.OpenReport "BULLETIN", acViewPreview Report_BULLETIN.Filter = "COLL_ID=" & Me.cboSelColl.Value Report_BULLETIN.FilterOn = True DoCmd.OpenReport sNomEtat, acViewNormal The report is printed with the correct number of records, but it remains open in design view!! What is the correct way of doing that? Regards, Philippe From DWUTKA at Marlow.com Tue Jul 10 09:24:29 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Tue, 10 Jul 2007 09:24:29 -0500 Subject: [AccessD] Performance tips anyone? In-Reply-To: Message-ID: This is starting to degrade into a full blown bound/unbound debate. There's no point. There is a time and a place for both. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Monday, July 09, 2007 10:02 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Performance tips anyone? Drew: I'm familiar with the 'use at your own risk' 'AddressOf' function since the days of Access97 at 'The Access Web' of Dev Ashish, but this is not the sense in which most Access programmers ordinarily are familiar with callback functions. Of couse the whole callback thing has little bearing on the initial question about performance tips or on the question of bound or unbound. I still haven't seen an explanation of how unbound is inherently faster than bound. I've heard discussion about being able to do certain kinds of things unbound that can't be done bound and have given a couple examples myslef. I still don't see how it provides additional performance so don't understand in what sense proposing it is an answer to the question. There is also little sense in making the assumption that everyone is a good developer and is aware of the issues that may come with losing record locking. It is irresponsible to say that jet looks after record locking, no difference, bound or unbound. You can't advocate something that will undoubtedly hurt people if you don't mention the caveats. What constitutes 'good developing' depends on a number of factors. In terms of performance, a degree of denormalization may be good thing as it can cut down the number of joins to be processed. In the database from which I drew the contract value/address example, we never had identical addresses for multiple projects. Sure we have addresses for various kinds of entities and they could be stored in a single table, but placing all the addresses in a separate table would have resulted in a table with a much larger number of records that would have to be hit to populate a record fore each kind of entity. Querying for any kind of related record by address, that would be possible by normalizing, was of no advantage in this database. Worse yet, the physical address of a project never changes, but if you join that address to a company and some bright bulb changes the address of the company when it moves rather than adding a new address and 'deactivating' or date ranging the validity of the address, the edit to the address changes the AddressOf (pun intended) the project. In the example I gave, both the contract value and the addresses were appropriate characteristics of the project. I've also gotten performance gains out of mapping data to bit flags; another normalization no no. Callback functions are very useful to me in cases where I do use foreign keys as I frequently fill a combo or list from an array and avoid a hit on the database. In addition to what Colby calls JIT sub forms, together with limiting the data to only needed data, you can do the same thing with combos, displaying a text value in a delimited list and converting to an SQL rowsource on GotFocus provided you store the text value in the table together with the FK. One of the slower built in functions in Access is the CurrentDb function and it can crawl when called in a loop. I use a function that keeps a static variable that points to a database object and returns a reference to that object. The database for which this question was asked is large in terms of numbers of objects. CurrentDb forces a refresh of all the database objects so I use an optional parameter that allows me to specify should I need to refresh the collection. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From fuller.artful at gmail.com Tue Jul 10 09:42:50 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 10 Jul 2007 10:42:50 -0400 Subject: [AccessD] Writing to the Access status bar In-Reply-To: <671421.18251.qm@web31606.mail.mud.yahoo.com> References: <29f585dd0707100526p316620b7i7e7dece2f48a9266@mail.gmail.com> <671421.18251.qm@web31606.mail.mud.yahoo.com> Message-ID: <29f585dd0707100742x755cb1aepe84f03f43cf40034@mail.gmail.com> That's what I thought, but the behabiour (or lack thereof) puzzles me. What I see instead is "calculating" and then "form" on the status line. On 7/10/07, Sad Der wrote: > > Hi Arthur, > > SysCmd acSysCmdSetStatus, "Elapsed Time: " & _ > lngMin \ 60 & Format(lngMin Mod 60, "\:00") > > HTH > > Sander > --- Arthur Fuller wrote: > > > Can someone point me in the right direction to write > > a message to the status > > bar? I've done it before but forgotten how. I know > > that it has something to > > do with acSysCmdSetStatus but that's all I can > > remember. > > > > TIA, > > Arthur > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > ____________________________________________________________________________________ > Shape Yahoo! in your own image. Join our Network Research Panel today! > http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From John.Clark at niagaracounty.com Tue Jul 10 09:47:46 2007 From: John.Clark at niagaracounty.com (John Clark) Date: Tue, 10 Jul 2007 10:47:46 -0400 Subject: [AccessD] MDE Will not open (resent?) In-Reply-To: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> Message-ID: <469363D1.167F.006B.0@niagaracounty.com> I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? I did not write this thing...I'm not getting a good answer on who exactly did...so I don't know much about it's origins. From jwelz at hotmail.com Tue Jul 10 09:59:48 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Tue, 10 Jul 2007 08:59:48 -0600 Subject: [AccessD] Update the current recordset In-Reply-To: <20070710123624.52451BDAE@smtp-auth.no-ip.com> Message-ID: If you use a long for the 'Marked' field, you can assign 32 users a bit position within the long. I've done this to flag users in our office for appointments and meetings. Alternatively you could use a text field with delimited User IDs and query with 'Like *" & UserID & "*', though querying on the bit is more efficient. Hence this needn't necessarily be a bound limitation. In terms of marking a field based on a filtered recordset, I'd be inclined to run a dbExecute rather than iterating a recordset: "Update tblDivision Set Marked = True Where " & Forms("frmDivision").Filter or you could write the Where clause based on the buttons and combos. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "jwcolby" > >First of all, using a field called "Marked" may cause multi-user issues. >It >definitely will in a bound form, because the records are live linked back >to >the table. If another user clears the marked flag for a record the current >user is looking at... > > >John W. Colby >Colby Consulting > >I have continuous form that is a subform. On the parent form's header are >some buttons and combo boxes that are used to filter the continuous >subform. >This all works fine. There's an option group that contains "Mark All", >"Find >Marked" and "Unmark All" options. When I first wrote it, "Mark All" applied >to all the records in the table but I want it to be smarter than that. To >wit, when you filter, say, by age, and select 20 as the age, then only a >small subset of the total rows are shown. I want "Mark all" to apply to the >subset not the whole table. > >The Marking is done using a column in the table called Marked. The first >version invokes a stored procedure to mark and unmark all the records and >it >is amazingly quick. > >I thought that if I used the recordsetclone it would present only the >filtered subset, but apparently that doesn't work. Here's the code I wrote: > > >Sub MarkAllRecords() > Dim rst As ADODB.Recordset > With Me > Set rst = .Riders_Browser_fsub.Form.RecordsetClone > > Do While Not rst.EOF > rst.Fields("Marked") = -1 > rst.Update > Debug.Print rst("RiderID"), rst("Marked") > rst.MoveNext > Loop > Debug.Print rst.RecordCount & " rows changed." > rst.Close > Set rst = Nothing > End With >End Sub > > >This marks all the records in the table, not the filtered subset. How do I >get a handle on just the subset? I suppose that I could use a SQL statement >that specifies the current filter, which I shall try now, but I'm wondering >why the code above doesn't work -- or rather, how to make it work. > >TIA, >Arthur _________________________________________________________________ New Windows Live Hotmail is here. Upgrade for free and get a better look. www.newhotmail.ca?icid=WLHMENCA150 From garykjos at gmail.com Tue Jul 10 10:02:12 2007 From: garykjos at gmail.com (Gary Kjos) Date: Tue, 10 Jul 2007 10:02:12 -0500 Subject: [AccessD] MDE Will not open (resent?) In-Reply-To: <469363D1.167F.006B.0@niagaracounty.com> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> <469363D1.167F.006B.0@niagaracounty.com> Message-ID: Are your users using multiple versions of Access? This is a bad thing. Does each user open their own copy? If not this is a problem too. Is it split into front end back end? Is it actually a A2K3 database? Or is is maybe a A2K database? Are their multiple users in it at once? Sorry I don't have any answers. Only questions. GK On 7/10/07, John Clark wrote: > I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? > > I did not write this thing...I'm not getting a good answer on who exactly did...so I don't know much about it's origins. > > > -- > 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 jwcolby at colbyconsulting.com Tue Jul 10 10:03:05 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 10 Jul 2007 11:03:05 -0400 Subject: [AccessD] MDE Will not open (resent?) In-Reply-To: <469363D1.167F.006B.0@niagaracounty.com> Message-ID: <20070710150307.849DCBC80@smtp-auth.no-ip.com> Sounds like an opportunity... To write them a new application. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Clark Sent: Tuesday, July 10, 2007 10:48 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] MDE Will not open (resent?) I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? I did not write this thing...I'm not getting a good answer on who exactly did...so I don't know much about it's origins. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue Jul 10 10:21:29 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 10 Jul 2007 08:21:29 -0700 Subject: [AccessD] Writing to the Access status bar In-Reply-To: <29f585dd0707100742x755cb1aepe84f03f43cf40034@mail.gmail.com> References: <29f585dd0707100526p316620b7i7e7dece2f48a9266@mail.gmail.com><671421.18251.qm@web31606.mail.mud.yahoo.com> <29f585dd0707100742x755cb1aepe84f03f43cf40034@mail.gmail.com> Message-ID: The problem is that if you're running a query or have some other operations being performed, their messages show up in the same place in the status bar (i.e. "Calculating ..."). Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Tuesday, July 10, 2007 7:43 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Writing to the Access status bar That's what I thought, but the behabiour (or lack thereof) puzzles me. What I see instead is "calculating" and then "form" on the status line. On 7/10/07, Sad Der wrote: > > Hi Arthur, > > SysCmd acSysCmdSetStatus, "Elapsed Time: " & _ lngMin \ 60 & > Format(lngMin Mod 60, "\:00") > > HTH > > Sander > --- Arthur Fuller wrote: > > > Can someone point me in the right direction to write a message to > > the status bar? I've done it before but forgotten how. I know that > > it has something to do with acSysCmdSetStatus but that's all I can > > remember. > > > > TIA, > > Arthur > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > ______________________________________________________________________ > ______________ Shape Yahoo! in your own image. Join our Network > Research Panel today! > http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > -- > 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 accessd at shaw.ca Tue Jul 10 10:40:17 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 10 Jul 2007 08:40:17 -0700 Subject: [AccessD] Compile errors In-Reply-To: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> Message-ID: <0JKY0051NZANZUQ0@l-daemon> Hi All: Has anyone had a similar error: "compile error: User defined type not defined" I can not duplicate the error on my system and the client can not resolve the error on their system. They have the complete application, to the letter, running on their site. What could be causing this error as it appears they have virtually the same MS Access version that I do? TIA Jim From Gustav at cactus.dk Tue Jul 10 10:53:36 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Tue, 10 Jul 2007 17:53:36 +0200 Subject: [AccessD] Compile errors Message-ID: Hi Jim This sounds like one of our all time classics. Broken References in Runtime AXP and A97: http://databaseadvisors.com/mailman/htdig/accessd/2003-July/011034.html The issue is caused by the two installations being not fully identical even though it may appear so. /gustav >>> accessd at shaw.ca 10-07-2007 17:40 >>> Hi All: Has anyone had a similar error: "compile error: User defined type not defined" I can not duplicate the error on my system and the client can not resolve the error on their system. They have the complete application, to the letter, running on their site. What could be causing this error as it appears they have virtually the same MS Access version that I do? TIA Jim From carbonnb at gmail.com Tue Jul 10 11:08:48 2007 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Tue, 10 Jul 2007 12:08:48 -0400 Subject: [AccessD] Compile errors In-Reply-To: <0JKY0051NZANZUQ0@l-daemon> References: <29f585dd0707090708x179b9429t32d6b78dc76b3558@mail.gmail.com> <0JKY0051NZANZUQ0@l-daemon> Message-ID: On 7/10/07, Jim Lawrence wrote: > Has anyone had a similar error: "compile error: User defined type not > defined" I can not duplicate the error on my system and the client can not > resolve the error on their system. They have the complete application, to > the letter, running on their site. > > What could be causing this error as it appears they have virtually the same > MS Access version that I do? Jet SP levels is what I have found causes these errors. I had this error once because I had Jet SP6 and the users workstations had Jet SP3. Once I upgraded the workstations to Jet SP6 the error went away. MS has a tool, MDAC Utility: Component Checker, to see what versions and SP level the install is at. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From miscellany at mvps.org Tue Jul 10 14:35:15 2007 From: miscellany at mvps.org (Steve Schapel) Date: Wed, 11 Jul 2007 07:35:15 +1200 Subject: [AccessD] How to print a report? In-Reply-To: <57144ced0707100648v170b79fbvebb7d3af3a978506@mail.gmail.com> References: <57144ced0707100648v170b79fbvebb7d3af3a978506@mail.gmail.com> Message-ID: <4693DF73.2010704@mvps.org> Philippe, I think it would be neater to use the Where Condition argument of the OpenReport method, rather than Filter. That way you would only need the one line of code, like this... DoCmd.OpenReport "BULLETIN", , , "COLL_ID=" & Me.cboSelColl Regards Steve philippe pons wrote: > Hi all, > > I tried to print a report, but unsuccessfully till now! > > I need to print the report but prior to this I set it'sFilter property: > Report_BULLETIN.Filter = "COLL_ID=" & Me.cboSelColl.Value > Report_BULLETIN.FilterOn = True > > I discover I have to open the report and then set the Filter and FilterOn > property. > All is ok, I can see my filtered report. > > Now I want to print it. > I user > DoCmd.OpenReport "BULLETIN", acViewPreview > Report_BULLETIN.Filter = "COLL_ID=" & Me.cboSelColl.Value > Report_BULLETIN.FilterOn = True > DoCmd.OpenReport sNomEtat, acViewNormal > > The report is printed with the correct number of records, but it remains > open in design view!! > > What is the correct way of doing that? > > Regards, Philippe From martyconnelly at shaw.ca Tue Jul 10 15:12:54 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Tue, 10 Jul 2007 13:12:54 -0700 Subject: [AccessD] MDE Will not open (resent?) In-Reply-To: <469363D1.167F.006B.0@niagaracounty.com> References: <009401c7bff8$c7f3b260$d1b82ad1@SusanOne> <469363D1.167F.006B.0@niagaracounty.com> Message-ID: <4693E846.2020808@shaw.ca> You could try JetComp.exe on a copy of the MDE http://support.microsoft.com/kb/295334/en-us John Clark wrote: >I've got a user on the line. There is an A2K3 DB that opened this morning and now it give an error, "You can't convert or enable an MDE file." This happens whether we hit convert or open. It didn't even prompt for these when it worked this morning. I have no MDB....just the MDE...any options here? > >I did not write this thing...I'm not getting a good answer on who exactly did...so I don't know much about it's origins. > > > > -- Marty Connelly Victoria, B.C. Canada From accessd666 at yahoo.com Wed Jul 11 01:45:03 2007 From: accessd666 at yahoo.com (Sad Der) Date: Tue, 10 Jul 2007 23:45:03 -0700 (PDT) Subject: [AccessD] Upsize wizard => Queries In-Reply-To: <200707101325.l6ADPVPa023938@databaseadvisors.com> Message-ID: <505071.24605.qm@web31605.mail.mud.yahoo.com> Ok, was afraid of that. Is there a way to retrieve the SQL text of the query in a automated way? Regards, Sander --- "Robert L. Stewart" wrote: > The syntax for the queries is too different to be > migrated. You had to do that yourself. > > Or, you can change your default to be SQL-92 (I > think) > compliant. Then you can simply copy and paste the > SQL > between them. But, either way, you still have to do > it > yourself. > > Robert > > At 07:26 AM 7/10/2007, you wrote: > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > >From: Sad Der > >Subject: [AccessD] Upsize wizard => Queries > >To: Acces User Group > >Message-ID: > <460545.53873.qm at web31611.mail.mud.yahoo.com> > >Content-Type: text/plain; charset=iso-8859-1 > > > >Hi group, > > > >Using the upgrade wizard I can migrate the tables > and > >data in a couple of minutes to SQL Server. > > > >(Action) Queries are not migrated. > > > >Does anybody know of a tool that migrates queries > to > >sql server views and/or sp's? > > > >TIA!!!! > > > >Regards, > > > >Sander > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 From paul.hartland at fsmail.net Wed Jul 11 08:44:24 2007 From: paul.hartland at fsmail.net (paul.hartland at fsmail.net) Date: Wed, 11 Jul 2007 15:44:24 +0200 (CEST) Subject: [AccessD] Interfacing with CardScan Executive 800 Message-ID: <12402995.165111184161464092.JavaMail.www@wwinf3205> To all, Just a shot in the dark here, but we have purchased a CardScan 800 & would like to put our own front-end on either Access or VB to make it easy for a couple of our employees so they basically only have to put the photo into the scanner, click a button type a payroll number then it automatically saves to a certain directory (possibly after automatically sizing the image) Anyone done this or anything similar ? Thanks in advance for any help on this.... Paul Hartland paul.hartland at fsmail.net 07730 523179 From Lambert.Heenan at AIG.com Wed Jul 11 08:54:11 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Wed, 11 Jul 2007 09:54:11 -0400 Subject: [AccessD] Upsize wizard => Queries Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6BD3@xlivmbx35.aig.com> Sure. Dim qd as QueryDef Dim strSQL as String For Each qd in QueryDefs strSQL = qd.SQL ' Save the sql somewhere Next qd Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der Sent: Wednesday, July 11, 2007 2:45 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Upsize wizard => Queries Ok, was afraid of that. Is there a way to retrieve the SQL text of the query in a automated way? Regards, Sander --- "Robert L. Stewart" wrote: > The syntax for the queries is too different to be > migrated. You had to do that yourself. > > Or, you can change your default to be SQL-92 (I > think) > compliant. Then you can simply copy and paste the > SQL > between them. But, either way, you still have to do > it > yourself. > > Robert > > At 07:26 AM 7/10/2007, you wrote: > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > >From: Sad Der > >Subject: [AccessD] Upsize wizard => Queries > >To: Acces User Group > >Message-ID: > <460545.53873.qm at web31611.mail.mud.yahoo.com> > >Content-Type: text/plain; charset=iso-8859-1 > > > >Hi group, > > > >Using the upgrade wizard I can migrate the tables > and > >data in a couple of minutes to SQL Server. > > > >(Action) Queries are not migrated. > > > >Does anybody know of a tool that migrates queries > to > >sql server views and/or sp's? > > > >TIA!!!! > > > >Regards, > > > >Sander > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > ____________________________________________________________________________ ________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 11 09:19:36 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 10:19:36 -0400 Subject: [AccessD] Visual studio help Message-ID: <20070711141940.0F966BE2C@smtp-auth.no-ip.com> I am still locked in to the SQL Server help when inside of visual Studio. If I hit F1 at any time, anywhere, with anything selected, help opens but it is SQL Server 2005 help. I need it to be VB.Net help, at least as the default. I cannot for the life of me determine where I can select a different default help file to open when I press F1. Does anyone out there have a clue? John W. Colby Colby Consulting www.ColbyConsulting.com From jwcolby at colbyconsulting.com Wed Jul 11 10:51:28 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 11:51:28 -0400 Subject: [AccessD] [dba-VB] Visual studio help In-Reply-To: Message-ID: <20070711155131.9F8C9BE74@smtp-auth.no-ip.com> Yes, but if you hit F1 then it opens a help file of some sort. I can say whether it is going to use the local help or the internet help first etc. As for books online, well... I only know that term in terms of SQL Server. 1) Go into code. 2) Select some something, keyword, whatever. 3) Hit F1. What do you see? I see a help window. On the top blue bar it says "Microsoft Visual Studio 2005 Documentation". That is a good sign. However on the left hand side there is a Pane (or PAIN depending on your point of view), which has a "filter by" combo. The ONLY CHOICES (for me) are: SQL Server 2005 SQL Server Analysis Service SQL Server... SQL Server... SQL Server... Etc etc. I am locked in to filtering on SQL Server help. I DON'T WANT SQL SERVER HELP, I WANT VB HELP. Actually I want to be able to select VB, C#, Java, SQL Server and whatever else is appropriate in the context I am using. I am flying Visual Studio blind, unless all I am interested in is SQL Server help in which case I am ducky. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 11, 2007 11:14 AM To: dba-vb at databaseadvisors.com Subject: Re: [dba-VB] Visual studio help By SQL Server Help, do you mean BOL, John? I don't find the F1 especially usefull in VS 2005 except as a way to open the help window. I usually wind up doing a search once the help window has come up because it never seems to locate what I'm looking for otherwise. Charlotte Foust -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 11, 2007 7:20 AM To: 'Access Developers discussion and problem solving'; dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com Subject: [dba-VB] Visual studio help I am still locked in to the SQL Server help when inside of visual Studio. If I hit F1 at any time, anywhere, with anything selected, help opens but it is SQL Server 2005 help. I need it to be VB.Net help, at least as the default. I cannot for the life of me determine where I can select a different default help file to open when I press F1. Does anyone out there have a clue? John W. Colby Colby Consulting www.ColbyConsulting.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com From iggy at nanaimo.ark.com Wed Jul 11 11:13:35 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Wed, 11 Jul 2007 09:13:35 -0700 Subject: [AccessD] Visual Studio Message-ID: <469501AF.6000501@nanaimo.ark.com> Hey All Sorry this may sound like a dumb question. I have just had a local computer store order me a copy of Office 2003. I asked them about ordering Visual Studio 2005 Tools for the Microsoft Office System They cannot seem to find it. Does this package have to be ordered through Microsoft? I live in Nanaimo, B.C. Canada. Anyone know of anyone local on the island or Vancouver that may carry the product? Thank you From jwcolby at colbyconsulting.com Wed Jul 11 11:29:03 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 12:29:03 -0400 Subject: [AccessD] [dba-SQLServer] Visual studio help In-Reply-To: <200707111605.l6BG50a6018086@databaseadvisors.com> Message-ID: <20070711162907.4016CBE1D@smtp-auth.no-ip.com> Robert, Yep, a reinstall of MSDN fixed the problem. Thanks for the heads up John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert Sent: Wednesday, July 11, 2007 12:00 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Visual studio help John, The help files for Visual Studio are not installed automatically. You have to run the install on the MSDN disk(s) that came with it to get help of any kind. Robert At 10:51 AM 7/11/2007, you wrote: >Date: Wed, 11 Jul 2007 11:51:28 -0400 >From: "jwcolby" >Subject: Re: [dba-SQLServer] [dba-VB] Visual studio help >To: , > , "'Access Developers discussion and > problem solving'" >Message-ID: <20070711155131.9F8C9BE74 at smtp-auth.no-ip.com> >Content-Type: text/plain; charset="us-ascii" > >Yes, but if you hit F1 then it opens a help file of some sort. I can >say whether it is going to use the local help or the internet help first etc. >As for books online, well... I only know that term in terms of SQL Server. > >1) Go into code. >2) Select some something, keyword, whatever. >3) Hit F1. > >What do you see? > >I see a help window. On the top blue bar it says "Microsoft Visual >Studio >2005 Documentation". That is a good sign. > >However on the left hand side there is a Pane (or PAIN depending on >your point of view), which has a "filter by" combo. The ONLY CHOICES >(for me) >are: > >SQL Server 2005 >SQL Server Analysis Service >SQL Server... >SQL Server... >SQL Server... >Etc etc. > >I am locked in to filtering on SQL Server help. I DON'T WANT SQL >SERVER HELP, I WANT VB HELP. > >Actually I want to be able to select VB, C#, Java, SQL Server and >whatever else is appropriate in the context I am using. I am flying >Visual Studio blind, unless all I am interested in is SQL Server help >in which case I am ducky. > >John W. Colby _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 11 12:28:45 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 11 Jul 2007 10:28:45 -0700 Subject: [AccessD] Visual Studio In-Reply-To: <469501AF.6000501@nanaimo.ark.com> References: <469501AF.6000501@nanaimo.ark.com> Message-ID: For 2003, you need the VSTO for 2003. The tools for 2007 were briefly available for download but I think were then pulled for problems. To my knowledge, there is no VSTO 2005, since there was no Office 2005. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Tony Septav Sent: Wednesday, July 11, 2007 9:14 AM To: Access Developers discussion and problem solving Subject: [AccessD] Visual Studio Hey All Sorry this may sound like a dumb question. I have just had a local computer store order me a copy of Office 2003. I asked them about ordering Visual Studio 2005 Tools for the Microsoft Office System They cannot seem to find it. Does this package have to be ordered through Microsoft? I live in Nanaimo, B.C. Canada. Anyone know of anyone local on the island or Vancouver that may carry the product? Thank you -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Wed Jul 11 14:20:34 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 11 Jul 2007 15:20:34 -0400 Subject: [AccessD] Upsize wizard => Queries In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6BD3@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6BD3@xlivmbx35.aig.com> Message-ID: <29f585dd0707111220if71501fxcc4a3c35e43c6783@mail.gmail.com> The biggest single thing you can do to get from Here to There is check all your recordsouces and rowsources for instances that begin with "SELECT". Before you migrate, visit every instance and turn it into a named query. Failure to do this results in a) a bunch of views/sprocs with names similar to "~#;flkjh", which may be meaningful to you but certainly are not to me. Following this simple rule results in error messages that precisely identify the queries that wouldn't port. These failures can occur for several reasons, among which are: 1. use of a built-in Access function that doesn't exist in SQL. 2. (the one that got me many times) use of static functions that I wrote that don't exist in SQL. 3. differences in syntax (they're aren't a lot but there are more than a dozen). So. My recommendation is, if you're not already too deep in the puddle to retreat, back up and start again. Somewhere around I have code that walks all the rowsources and recordsources looking for the word SELECT as the first part of the string, then dumps all those and their consumers to a file. I haven't needed it for a while, so it may take a bit of time to dig it up. Alternatively, if you have Rick Fisher's FR or Speed Ferret you can narrow the search scope and quickly locate these errant bits of code. My second recommendation is, even if you think you're going to work in Access to your twilight days, STOP planting SELECT statements in the code and control properties. It's asinine. Create named queries. In case my point wasn't clear, Create Named Queries! (With respect, your air code misses most of the problems that arise. QueryDefs are easily identified and fixed or rewritten. It's the embedded SELECTs that kill ya.) Arthur On 7/11/07, Heenan, Lambert wrote: > > Sure. > > > > Dim qd as QueryDef > Dim strSQL as String > > For Each qd in QueryDefs > strSQL = qd.SQL > ' Save the sql somewhere > Next qd > > > > Lambert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der > Sent: Wednesday, July 11, 2007 2:45 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Upsize wizard => Queries > > > Ok, was afraid of that. Is there a way to retrieve the > SQL text of the query in a automated way? > > Regards, > > Sander > > > > --- "Robert L. Stewart" wrote: > > > The syntax for the queries is too different to be > > migrated. You had to do that yourself. > > > > Or, you can change your default to be SQL-92 (I > > think) > > compliant. Then you can simply copy and paste the > > SQL > > between them. But, either way, you still have to do > > it > > yourself. > > > > Robert > > > > At 07:26 AM 7/10/2007, you wrote: > > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > > >From: Sad Der > > >Subject: [AccessD] Upsize wizard => Queries > > >To: Acces User Group > > >Message-ID: > > <460545.53873.qm at web31611.mail.mud.yahoo.com> > > >Content-Type: text/plain; charset=iso-8859-1 > > > > > >Hi group, > > > > > >Using the upgrade wizard I can migrate the tables > > and > > >data in a couple of minutes to SQL Server. > > > > > >(Action) Queries are not migrated. > > > > > >Does anybody know of a tool that migrates queries > > to > > >sql server views and/or sp's? > > > > > >TIA!!!! > > > > > >Regards, > > > > > >Sander > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > > ____________________________________________________________________________ > ________ > Be a PS3 game guru. > Get your game face on with the latest PS3 news and previews at Yahoo! > Games. > http://videogames.yahoo.com/platform?platform=120121 > -- > 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 Wed Jul 11 14:26:16 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Wed, 11 Jul 2007 14:26:16 -0500 Subject: [AccessD] Upsize wizard => Queries Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6BDB@xlivmbx35.aig.com> With respect, at no point did I see the term "embedded SELECTs" or anything like it. The questioner was asking about "Queries", which are of course QueryDefs in code land. That said, you're quite right. SQL code in modules come back to bight because of their poor maintainability. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 11, 2007 3:21 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Upsize wizard => Queries The biggest single thing you can do to get from Here to There is check all your recordsouces and rowsources for instances that begin with "SELECT". Before you migrate, visit every instance and turn it into a named query. Failure to do this results in a) a bunch of views/sprocs with names similar to "~#;flkjh", which may be meaningful to you but certainly are not to me. Following this simple rule results in error messages that precisely identify the queries that wouldn't port. These failures can occur for several reasons, among which are: 1. use of a built-in Access function that doesn't exist in SQL. 2. (the one that got me many times) use of static functions that I wrote that don't exist in SQL. 3. differences in syntax (they're aren't a lot but there are more than a dozen). So. My recommendation is, if you're not already too deep in the puddle to retreat, back up and start again. Somewhere around I have code that walks all the rowsources and recordsources looking for the word SELECT as the first part of the string, then dumps all those and their consumers to a file. I haven't needed it for a while, so it may take a bit of time to dig it up. Alternatively, if you have Rick Fisher's FR or Speed Ferret you can narrow the search scope and quickly locate these errant bits of code. My second recommendation is, even if you think you're going to work in Access to your twilight days, STOP planting SELECT statements in the code and control properties. It's asinine. Create named queries. In case my point wasn't clear, Create Named Queries! (With respect, your air code misses most of the problems that arise. QueryDefs are easily identified and fixed or rewritten. It's the embedded SELECTs that kill ya.) Arthur On 7/11/07, Heenan, Lambert wrote: > > Sure. > > > > Dim qd as QueryDef > Dim strSQL as String > > For Each qd in QueryDefs > strSQL = qd.SQL > ' Save the sql somewhere > Next qd > > > > Lambert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der > Sent: Wednesday, July 11, 2007 2:45 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Upsize wizard => Queries > > > Ok, was afraid of that. Is there a way to retrieve the > SQL text of the query in a automated way? > > Regards, > > Sander > > > > --- "Robert L. Stewart" wrote: > > > The syntax for the queries is too different to be > > migrated. You had to do that yourself. > > > > Or, you can change your default to be SQL-92 (I > > think) > > compliant. Then you can simply copy and paste the > > SQL > > between them. But, either way, you still have to do > > it > > yourself. > > > > Robert > > > > At 07:26 AM 7/10/2007, you wrote: > > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > > >From: Sad Der > > >Subject: [AccessD] Upsize wizard => Queries > > >To: Acces User Group > > >Message-ID: > > <460545.53873.qm at web31611.mail.mud.yahoo.com> > > >Content-Type: text/plain; charset=iso-8859-1 > > > > > >Hi group, > > > > > >Using the upgrade wizard I can migrate the tables > > and > > >data in a couple of minutes to SQL Server. > > > > > >(Action) Queries are not migrated. > > > > > >Does anybody know of a tool that migrates queries > > to > > >sql server views and/or sp's? > > > > > >TIA!!!! > > > > > >Regards, > > > > > >Sander > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > > ______________________________________________________________________ > ______ > ________ > Be a PS3 game guru. > Get your game face on with the latest PS3 news and previews at Yahoo! > Games. > http://videogames.yahoo.com/platform?platform=120121 > -- > 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 jwcolby at colbyconsulting.com Wed Jul 11 14:38:20 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 15:38:20 -0400 Subject: [AccessD] Upsize wizard => Queries In-Reply-To: <29f585dd0707111220if71501fxcc4a3c35e43c6783@mail.gmail.com> Message-ID: <20070711193824.10F94BD2E@smtp-auth.no-ip.com> LOL, Right you are Arthur. And stop using static functions, and references to controls on forms and functions that are VBA but don't exist elsewhere and... Hmmm... You are correct on all counts Arthur, however I think that if a move to SQL Server is in order, then they probably got a huge usage out of the database and should just pay up to do a conversion. All of the things mentioned are shortcuts that only work in Access and are part of what makes Access a RAD environment. Moving to client server is a whole nother ball game and trying to build every app in anticipation of that trip is not useful IMHO. Those who need it pay for it, those who don't, don't. It is relatively trivial to write code to open forms and look for SQL statements in combos etc, and even to build saved queries using that SQL statement, embedding the object name in the querydef name. For example qfrmXyzCboAbc. That would "build stored queries" and voila, you can then try the upsize and see what fails now. If I have a major upgrade happening I could write such code quickly enough. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 11, 2007 3:21 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Upsize wizard => Queries The biggest single thing you can do to get from Here to There is check all your recordsouces and rowsources for instances that begin with "SELECT". Before you migrate, visit every instance and turn it into a named query. Failure to do this results in a) a bunch of views/sprocs with names similar to "~#;flkjh", which may be meaningful to you but certainly are not to me. Following this simple rule results in error messages that precisely identify the queries that wouldn't port. These failures can occur for several reasons, among which are: 1. use of a built-in Access function that doesn't exist in SQL. 2. (the one that got me many times) use of static functions that I wrote that don't exist in SQL. 3. differences in syntax (they're aren't a lot but there are more than a dozen). So. My recommendation is, if you're not already too deep in the puddle to retreat, back up and start again. Somewhere around I have code that walks all the rowsources and recordsources looking for the word SELECT as the first part of the string, then dumps all those and their consumers to a file. I haven't needed it for a while, so it may take a bit of time to dig it up. Alternatively, if you have Rick Fisher's FR or Speed Ferret you can narrow the search scope and quickly locate these errant bits of code. My second recommendation is, even if you think you're going to work in Access to your twilight days, STOP planting SELECT statements in the code and control properties. It's asinine. Create named queries. In case my point wasn't clear, Create Named Queries! (With respect, your air code misses most of the problems that arise. QueryDefs are easily identified and fixed or rewritten. It's the embedded SELECTs that kill ya.) Arthur On 7/11/07, Heenan, Lambert wrote: > > Sure. > > > > Dim qd as QueryDef > Dim strSQL as String > > For Each qd in QueryDefs > strSQL = qd.SQL > ' Save the sql somewhere > Next qd > > > > Lambert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der > Sent: Wednesday, July 11, 2007 2:45 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Upsize wizard => Queries > > > Ok, was afraid of that. Is there a way to retrieve the SQL text of the > query in a automated way? > > Regards, > > Sander > > > > --- "Robert L. Stewart" wrote: > > > The syntax for the queries is too different to be migrated. You had > > to do that yourself. > > > > Or, you can change your default to be SQL-92 (I > > think) > > compliant. Then you can simply copy and paste the SQL between them. > > But, either way, you still have to do it yourself. > > > > Robert > > > > At 07:26 AM 7/10/2007, you wrote: > > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > > >From: Sad Der > > >Subject: [AccessD] Upsize wizard => Queries > > >To: Acces User Group > > >Message-ID: > > <460545.53873.qm at web31611.mail.mud.yahoo.com> > > >Content-Type: text/plain; charset=iso-8859-1 > > > > > >Hi group, > > > > > >Using the upgrade wizard I can migrate the tables > > and > > >data in a couple of minutes to SQL Server. > > > > > >(Action) Queries are not migrated. > > > > > >Does anybody know of a tool that migrates queries > > to > > >sql server views and/or sp's? > > > > > >TIA!!!! > > > > > >Regards, > > > > > >Sander > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > > ____________________________________________________________________________ > ________ > Be a PS3 game guru. > Get your game face on with the latest PS3 news and previews at Yahoo! > Games. > http://videogames.yahoo.com/platform?platform=120121 > -- > 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 markamatte at hotmail.com Wed Jul 11 15:10:18 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Wed, 11 Jul 2007 20:10:18 +0000 Subject: [AccessD] Upsize wizard => Queries In-Reply-To: <29f585dd0707111220if71501fxcc4a3c35e43c6783@mail.gmail.com> Message-ID: Sander, Can you use the DOCUMENTER in MS Access...select your queries...when it opens as a report...goto file save as table...open table and filter OBJECT TYPE field for "SQL Statement"...and this will give you the SQL for each query? Just an after thought... Mark A. matte >From: "Arthur Fuller" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Upsize wizard => Queries >Date: Wed, 11 Jul 2007 15:20:34 -0400 > >The biggest single thing you can do to get from Here to There is check all >your recordsouces and rowsources for instances that begin with "SELECT". >Before you migrate, visit every instance and turn it into a named query. >Failure to do this results in a) a bunch of views/sprocs with names similar >to "~#;flkjh", which may be meaningful to you but certainly are not to me. >Following this simple rule results in error messages that precisely >identify >the queries that wouldn't port. These failures can occur for several >reasons, among which are: > >1. use of a built-in Access function that doesn't exist in SQL. >2. (the one that got me many times) use of static functions that I wrote >that don't exist in SQL. >3. differences in syntax (they're aren't a lot but there are more than a >dozen). > >So. My recommendation is, if you're not already too deep in the puddle to >retreat, back up and start again. Somewhere around I have code that walks >all the rowsources and recordsources looking for the word SELECT as the >first part of the string, then dumps all those and their consumers to a >file. I haven't needed it for a while, so it may take a bit of time to dig >it up. Alternatively, if you have Rick Fisher's FR or Speed Ferret you can >narrow the search scope and quickly locate these errant bits of code. > >My second recommendation is, even if you think you're going to work in >Access to your twilight days, STOP planting SELECT statements in the code >and control properties. It's asinine. Create named queries. > >In case my point wasn't clear, Create Named Queries! > >(With respect, your air code misses most of the problems that arise. >QueryDefs are easily identified and fixed or rewritten. It's the embedded >SELECTs that kill ya.) > >Arthur > > >On 7/11/07, Heenan, Lambert wrote: > > > > Sure. > > > > > > > > Dim qd as QueryDef > > Dim strSQL as String > > > > For Each qd in QueryDefs > > strSQL = qd.SQL > > ' Save the sql somewhere > > Next qd > > > > > > > > Lambert > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der > > Sent: Wednesday, July 11, 2007 2:45 AM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] Upsize wizard => Queries > > > > > > Ok, was afraid of that. Is there a way to retrieve the > > SQL text of the query in a automated way? > > > > Regards, > > > > Sander > > > > > > > > --- "Robert L. Stewart" wrote: > > > > > The syntax for the queries is too different to be > > > migrated. You had to do that yourself. > > > > > > Or, you can change your default to be SQL-92 (I > > > think) > > > compliant. Then you can simply copy and paste the > > > SQL > > > between them. But, either way, you still have to do > > > it > > > yourself. > > > > > > Robert > > > > > > At 07:26 AM 7/10/2007, you wrote: > > > >Date: Tue, 10 Jul 2007 04:37:42 -0700 (PDT) > > > >From: Sad Der > > > >Subject: [AccessD] Upsize wizard => Queries > > > >To: Acces User Group > > > >Message-ID: > > > <460545.53873.qm at web31611.mail.mud.yahoo.com> > > > >Content-Type: text/plain; charset=iso-8859-1 > > > > > > > >Hi group, > > > > > > > >Using the upgrade wizard I can migrate the tables > > > and > > > >data in a couple of minutes to SQL Server. > > > > > > > >(Action) Queries are not migrated. > > > > > > > >Does anybody know of a tool that migrates queries > > > to > > > >sql server views and/or sp's? > > > > > > > >TIA!!!! > > > > > > > >Regards, > > > > > > > >Sander _________________________________________________________________ http://newlivehotmail.com From ssharkins at setel.com Wed Jul 11 17:35:16 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 11 Jul 2007 18:35:16 -0400 Subject: [AccessD] Export Outlook folder to Access Message-ID: <002901c7c40b$c176a110$23b62ad1@SusanOne> I thought that because Outlook could export email to Access so easily, manually, that there'd be a simple export method, but I'm not finding it. Do I really have to map each field to an Access table? When doing this manually, Outlook lets you map, but you don't have to -- so seems like there ought to be a more streamlined process in VBA too. I'm going hunting, but if anyone knows how to do this without running a loop to map each field for each record, I'd be glad for some direction. Susan H. From jmhecht at earthlink.net Wed Jul 11 21:30:49 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Wed, 11 Jul 2007 19:30:49 -0700 Subject: [AccessD] Query Question Message-ID: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> I I have a table with employee's five different certifications they need to work and the expiration date of these certificates. It is a one to one relationship between employee and certification. Professional license Medical Cert Dot Cert Cpr Drivers License It is a one to one relation between the license and expiration date. I need report that goes some thing this. Parameter = # of days into the future to check (user entered) For any expiration date in the criteria Return the employee, the license that is expiring and the name of that license only (not all their valid licensees) Or If returning all the licensees bold the license that is meeting the criteria and adding the employee to the report. TIA Joe Hecht jmhecht at earthlink.net From jwcolby at colbyconsulting.com Wed Jul 11 22:03:42 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 11 Jul 2007 23:03:42 -0400 Subject: [AccessD] Windows 2003 x64; SQL Server 2005 X64 Message-ID: <20070712030347.0B7E8BDA9@smtp-auth.no-ip.com> Is anyone out there running Windows 2003 X64? If so would you care to comment on what was involved in getting it to happen, drivers, getting the software etc. Same question for SQl Server 2005 X64. John W. Colby Colby Consulting www.ColbyConsulting.com From miscellany at mvps.org Thu Jul 12 04:46:17 2007 From: miscellany at mvps.org (Steve Schapel) Date: Thu, 12 Jul 2007 21:46:17 +1200 Subject: [AccessD] Query Question In-Reply-To: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> References: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> Message-ID: <4695F869.7060805@mvps.org> Joe, As it stands, I think it would be a case for a User Defined Function. But before going down that track... Are you able to consider a change in your table design, so that these certification expiries are listed as separate records in a related table, instead of separate fields? Regards Steve Joe Hecht wrote: > I I have a table with employee's five different certifications they need to > work and the expiration date of these certificates. > > > > It is a one to one relationship between employee and certification. > > > > Professional license > > Medical Cert > > Dot Cert > > Cpr > > Drivers License > > > > It is a one to one relation between the license and expiration date. > > > > I need report that goes some thing this. > > > > Parameter = # of days into the future to check (user entered) > > > > For any expiration date in the criteria > > > > Return the employee, the license that is expiring and the name of that > license only (not all their valid licensees) > > > > Or > > > > If returning all the licensees bold the license that is meeting the criteria > and adding the employee to the report. > > > > TIA > > > > Joe Hecht > > jmhecht at earthlink.net > > > From jwelz at hotmail.com Thu Jul 12 07:14:55 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 12 Jul 2007 06:14:55 -0600 Subject: [AccessD] Query Question In-Reply-To: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> Message-ID: 1 table for Certs 1 table for Employees 1 table for EmployeeCerts with date of expiry I've found that certifications change with time. Expiry ranges change, we track new certifications, we've added locations with different certs. You can place a date taken in the junction table and use a duration from the Certs table, as this is more flexible. You can place a unique index on the EmployeeCerts table, on the EmployeeID and CertID combination, but then you cannot track history of certifications, only update the date taken or expired depending on the design. Placing an exclusive index on the combination of IDs and date would prevent accidental duplicates. Reporting may be done with a Parent report of employees with a sub report of Certs including the EmployeeID and expiry from the EmployeeCerts junction. You can place a parameter on expiry 'Between Now() and UserChosenExpiryMax'. My employees have a course that only has a date taken (non-expiry), though most entities requiring this cert will only recognize it for 3 years. Personally, I think it makes more sense to include course validity range in the course table as a characteristic of the course and the date taken as a characteristic of the Employee Course junction table because users can pick the date taken more accurately than some future expiry date. This complicates the expiry query a bit as it requires a calculated field so it slows things up a bit. Recalling the 'Performance' thread, normalization is usually a good thing, but it can hurt performance. A one to one relationship, or storing the cert expirys in the Employee table directly is a denormalized approach that would give significantly better performance. Sometimes you need to choose between performance and flexibilty. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Joe Hecht" >I I have a table with employee's five different certifications they need to >work and the expiration date of these certificates. > > > >It is a one to one relationship between employee and certification. > > > >Professional license > >Medical Cert > >Dot Cert > >Cpr > >Drivers License > > > >It is a one to one relation between the license and expiration date. > > > >I need report that goes some thing this. > > > >Parameter = # of days into the future to check (user entered) > > > >For any expiration date in the criteria > > > >Return the employee, the license that is expiring and the name of that >license only (not all their valid licensees) > > > >Or > > > >If returning all the licensees bold the license that is meeting the >criteria >and adding the employee to the report. > > > >TIA > > > >Joe Hecht > >jmhecht at earthlink.net _________________________________________________________________ Upgrade to Windows Live Hotmail for free today! www.newhotmail.ca?icid=WLHMENCA151 From jmhecht at earthlink.net Thu Jul 12 08:47:46 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Thu, 12 Jul 2007 06:47:46 -0700 Subject: [AccessD] Query Question In-Reply-To: <4695F869.7060805@mvps.org> References: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> <4695F869.7060805@mvps.org> Message-ID: <001301c7c48b$3b362190$6701a8c0@ACER2G> I can. tblMain Basic Employee Info Subtable Cert and Exp date Is that what you are thinking? Joe Hecht jmhecht at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Thursday, July 12, 2007 2:46 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Query Question Joe, As it stands, I think it would be a case for a User Defined Function. But before going down that track... Are you able to consider a change in your table design, so that these certification expiries are listed as separate records in a related table, instead of separate fields? Regards Steve Joe Hecht wrote: > I I have a table with employee's five different certifications they need to > work and the expiration date of these certificates. > > > > It is a one to one relationship between employee and certification. > > > > Professional license > > Medical Cert > > Dot Cert > > Cpr > > Drivers License > > > > It is a one to one relation between the license and expiration date. > > > > I need report that goes some thing this. > > > > Parameter = # of days into the future to check (user entered) > > > > For any expiration date in the criteria > > > > Return the employee, the license that is expiring and the name of that > license only (not all their valid licensees) > > > > Or > > > > If returning all the licensees bold the license that is meeting the criteria > and adding the employee to the report. > > > > TIA > > > > Joe Hecht > > jmhecht at earthlink.net > > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Thu Jul 12 10:20:33 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Thu, 12 Jul 2007 11:20:33 -0400 Subject: [AccessD] SelPos Message-ID: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> I have a memo field for Notes. There is a button to add a new Note. This enables the note control and plonks in the date and sets focus to the note control. This part works nicely. I want to add a CRLF and then place the cursor on the next line. I think it has something to do with SelPos, but I can't remember how to do it. TIA, Arthur From cfoust at infostatsystems.com Thu Jul 12 11:08:21 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 12 Jul 2007 09:08:21 -0700 Subject: [AccessD] SelPos In-Reply-To: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> References: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> Message-ID: I did this in a popup form for editing a memo field in an old app, but I don't have a sample on this machine. If no one else comes up with an answer, I'll dig it out tonight. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Thursday, July 12, 2007 8:21 AM To: Access Developers discussion and problem solving Subject: [AccessD] SelPos I have a memo field for Notes. There is a button to add a new Note. This enables the note control and plonks in the date and sets focus to the note control. This part works nicely. I want to add a CRLF and then place the cursor on the next line. I think it has something to do with SelPos, but I can't remember how to do it. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Thu Jul 12 13:13:58 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 12 Jul 2007 18:13:58 +0000 Subject: [AccessD] SelPos In-Reply-To: Message-ID: Arthur, I have an old example that does something simliar...but it takes text from an unbound field...and places it in Me!History(my notes field). This approach was to keep anyone from editting old notes/history. Hope it helps: Me!History = Me!History & vbCrLf & "*****" & Now() & "**" & Forms!Switchboard!UserName & "**" & vbCrLf & Me!NewHistory Thanks, Mark A. Matte >From: "Charlotte Foust" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] SelPos >Date: Thu, 12 Jul 2007 09:08:21 -0700 > >I did this in a popup form for editing a memo field in an old app, but I >don't have a sample on this machine. If no one else comes up with an >answer, I'll dig it out tonight. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller >Sent: Thursday, July 12, 2007 8:21 AM >To: Access Developers discussion and problem solving >Subject: [AccessD] SelPos > >I have a memo field for Notes. There is a button to add a new Note. This >enables the note control and plonks in the date and sets focus to the >note control. This part works nicely. I want to add a CRLF and then >place the cursor on the next line. I think it has something to do with >SelPos, but I can't remember how to do it. > >TIA, >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 _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From miscellany at mvps.org Thu Jul 12 14:54:30 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 13 Jul 2007 07:54:30 +1200 Subject: [AccessD] Query Question In-Reply-To: <001301c7c48b$3b362190$6701a8c0@ACER2G> References: <000c01c7c42c$a9bb7bb0$6701a8c0@ACER2G> <4695F869.7060805@mvps.org> <001301c7c48b$3b362190$6701a8c0@ACER2G> Message-ID: <469686F6.6080800@mvps.org> Yes, Joe, that's exactly what I was thinking. The "subtable" would have these fields: - EmployeeID - Licence - ExpiryDate A more normalised data structure like this would make the type of query you are asking about a lot simpler. Rergards Steve Joe Hecht wrote: > I can. > > tblMain > > Basic Employee Info > > Subtable > > > Cert and Exp date > > Is that what you are thinking? From miscellany at mvps.org Thu Jul 12 15:17:32 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 13 Jul 2007 08:17:32 +1200 Subject: [AccessD] SelPos In-Reply-To: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> References: <29f585dd0707120820w32e3947hbe9429c65fce4c05@mail.gmail.com> Message-ID: <46968C5C.10007@mvps.org> Arthur, I think this might be the kind of thing you are after: Me.Notes.SelStart = Len(Me.Notes) + 1 By the way, aside from rich text formatting, another of the very nice new features in Access 2007 is the Append Only property, which does pretty much the kind of thing you are doing here, i.e. dated progressive additions to memo field data. Regards Steve Arthur Fuller wrote: > I have a memo field for Notes. There is a button to add a new Note. This > enables the note control and plonks in the date and sets focus to the note > control. This part works nicely. I want to add a CRLF and then place the > cursor on the next line. I think it has something to do with SelPos, but I > can't remember how to do it. > > TIA, > Arthur From fuller.artful at gmail.com Thu Jul 12 18:20:25 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Thu, 12 Jul 2007 19:20:25 -0400 Subject: [AccessD] SelPos In-Reply-To: References: Message-ID: <29f585dd0707121620k526f62ctd249afbfc545f408@mail.gmail.com> Thanks, Mark! That's precisely what I wanted to do, and I also like the embellishment of adding the user name. Arthur On 7/12/07, Mark A Matte wrote: > > Arthur, > > I have an old example that does something simliar...but it takes text from > an unbound field...and places it in Me!History(my notes field). This > approach was to keep anyone from editting old notes/history. > > Hope it helps: > Me!History = Me!History & vbCrLf & "*****" & Now() & "**" & > Forms!Switchboard!UserName & "**" & vbCrLf & Me!NewHistory > > Thanks, > > Mark A. Matte > > From jwcolby at colbyconsulting.com Fri Jul 13 18:26:43 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 13 Jul 2007 19:26:43 -0400 Subject: [AccessD] Checkbox dates Message-ID: <20070713232646.EA437BD09@smtp-auth.no-ip.com> I often like to use dates as flags, i.e. if a process happened I want a date that the process happened, if it did not happen, then I have a void for the date. However it is often convenient for the user to see the flag as a check box, i.e. they only care THAT it happened, not WHEN it happened. Obviously a checkbox is about Boolean values, not dates. In order to provide a check box interface to a date field in the database I designed a WithEvents class. The class is passed in an UNBOUND checkbox (for the visual display) and a BOUND text box (for the date storage). When the user checks the check box for the flag, the class sets or voids the TEXTBOX VALUE property. The txt.Value is set to Date() if the checkbox is set, and to VOID if the checkbox is cleared. Likewise the checkbox DISPLAYS a true if the value of the textbox is NOT NULL and DISPLAYS a FALSE if the textbox.Value is NULL. This code is in actual use in one of my forms, and represents flags for check stop payments and check voids in the database. The code for the class is as follows: '*************************************** ' 'This is the CLASS module. Cut and paste this into a new class, 'then save to the name clsCtlChk2Date ' Option Compare Database Option Explicit ' 'This class uses a check box to set / void a date in a record 'The objective is to allow the form to set a date to date() if a check box is checked 'and set that date to void if the check box is cleared. ' 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID 'and should display a FALSE if the date is VOID ' 'The class functions by passing in an UNBOUND check box which is the visual indicator 'A BOUND text box is passed in which actually stores the state of the flag as a date data type ' 'Thus as the user clicks the check box, this class sets the underlying (and invisible) text box 'The text box VALUE property is set to DATE if the check box displays a TRUE (is checked) 'and the textbox VALUE property is set to NULL if the checkbox displays a FALSE (is not checked) ' Private WithEvents mchk As CheckBox Private mtxt As TextBox Private Sub Class_Terminate() Set mchk = Nothing Set mtxt = Nothing End Sub Function init(lchk As CheckBox, ltxt As TextBox) Set mchk = lchk Set mtxt = ltxt SetChkState End Function ' 'This function causes the text box to track the visual state of the control 'If the user clicks the check box and the check box ends up TRUE then set the text box to Date() 'else set the text box to VOID ' Private Sub mchk_Click() On Error GoTo Err_mchk_Click If IsNull(mtxt) Then mtxt = Date Else mtxt = Null End If SetChkState Exit_mchk_Click: Exit Sub Err_mchk_Click: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" Resume Exit_mchk_Click End Select Resume 0 '.FOR TROUBLESHOOTING End Sub ' 'This sub causes the visual state of the checkbox to track the text box 'If the text box is VOID (no date) then display a FALSE 'else display a TRUE ' Public Sub SetChkState() On Error GoTo Err_SetChkState If IsNull(mtxt) Then mchk.Value = False Else mchk.Value = True End If Exit_SetChkState: Exit Sub Err_SetChkState: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" Resume Exit_SetChkState End Select Resume 0 '.FOR TROUBLESHOOTING End Sub '*************************************** It hooks in to the form as follows: '*************************************** ' 'This is the form's "code behind" module ' Option Compare Database Option Explicit Private fclsCtlVoidReq As clsctlChk2Date 'Dimension four instances of the class Private fclsCtlVoidProc As clsctlChk2Date Private fclsCtlStopReq As clsctlChk2Date Private fclsCtlStopProc As clsctlChk2Date Private Sub Form_Open(Cancel As Integer) Set fclsCtlStopReq = New clsctlChk2Date 'Instantiate the first one fclsCtlStopReq.init chkStopRequest, txtStopReq 'pass in an UNBOUND check box and a BOUND text box Set fclsCtlStopProc = New clsctlChk2Date fclsCtlStopProc.init chkStopProcessed, txtStopProcessed Set fclsCtlVoidReq = New clsctlChk2Date fclsCtlVoidReq.init chkVoidRequest, txtVoidReq Set fclsCtlVoidProc = New clsctlChk2Date fclsCtlVoidProc.init chkVoidProcessed, txtVoidProcessed End sub Private Sub Form_Current() fclsCtlStopReq.SetChkState 'As the form moves through records, make the checkbox display correctly fclsCtlStopProc.SetChkState fclsCtlVoidReq.SetChkState fclsCtlVoidProc.SetChkState End Sub '*************************************** That is all there is to it. This is another demonstration of where a class sinking events can replace a TON of code placed directly in the form, making code maintenance easier and also fo course making the concept usable in other forms as well as the current form. I hope those who don't use classes find this useful in understanding how classes can be useful, and how to implement classes and WithEvents to solve everyday problems. Enjoy, John W. Colby Colby Consulting www.ColbyConsulting.com From DWUTKA at Marlow.com Fri Jul 13 18:29:01 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Fri, 13 Jul 2007 18:29:01 -0500 Subject: [AccessD] Talking between Applications. Message-ID: Ya learn something new every day, don't ya? I've been re-writing an application I built 7 years ago. The new version is already in production, but I'll be adding new features probably for years to come. It's a help desk application, and one issue I'm working on is that there are several things that are 'monitored' events. Some events are lightning fast, some are a bit slower. The slower ones slow down the interface a bit, because it's all running in the same .exe. To fix this I thought about multithreading, but decided on just creating another application to do the monitoring. So how do you have one application talk to another? Before, I have used winsocks to do this. But it involves making socket connections, etc. This time, I dug into Window Messaging. I've done a lot of things with windows (in Windows) before, but I had to share this little tidbit with the List. To bring everyone up to snuff, every window on your machine has an hWnd value. That's the ID of each window. Windows sends all sorts of messages to each window, for every single thing that you do. When you move the mouse over a window, windows is firing window messages to that window with the mouse position. Clicking, typing, resizing, redrawing and more are all sent to the windows through window messages. When you close an application, that too is a window message. The fun part is, we can use that same process for our own purposes. There's a simple API call, called SendMessage, that requires the hWnd of the window you want to send a message too, the message ID (every process has a static ID, but you can use RegisterWindowMessage to create your own messageid (Unique to that particular machine)) and then two parameters (both long integers). Hey, but wait, if all I can send between two applications is two integers, what's the point? Well, you can also create a window on the fly, with a single API, you can then set it's window text to anything you want, and your recipient applications can read that window text and destroy the window. I have this process in place (the communication part, now I'm on to actually doing something with the comms), and it works great. Virtually no overhead in the communication process, runs as smoothly as moving a window across your screen. If there's interest in something like this, I'll post some code for it. Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From fuller.artful at gmail.com Fri Jul 13 18:41:33 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 13 Jul 2007 19:41:33 -0400 Subject: [AccessD] Talking between Applications. In-Reply-To: References: Message-ID: <29f585dd0707131641k49abbb2dud087ac3c605a81a2@mail.gmail.com> I've done something similar a few years back in PowerBuilder, but would love a look at your method. I don't have any immediate use for it, but this old dog does like to learn occasional new tricks. Arthur On 7/13/07, Drew Wutka wrote: > > Ya learn something new every day, don't ya? I've been re-writing an > application I built 7 years ago. The new version is already in > production, but I'll be adding new features probably for years to come. > It's a help desk application, and one issue I'm working on is that there > are several things that are 'monitored' events. Some events are > lightning fast, some are a bit slower. The slower ones slow down the > interface a bit, because it's all running in the same .exe. To fix this > I thought about multithreading, but decided on just creating another > application to do the monitoring. So how do you have one application > talk to another? > > > > Before, I have used winsocks to do this. But it involves making socket > connections, etc. This time, I dug into Window Messaging. I've done a > lot of things with windows (in Windows) before, but I had to share this > little tidbit with the List. > > > > To bring everyone up to snuff, every window on your machine has an hWnd > value. That's the ID of each window. Windows sends all sorts of > messages to each window, for every single thing that you do. When you > move the mouse over a window, windows is firing window messages to that > window with the mouse position. Clicking, typing, resizing, redrawing > and more are all sent to the windows through window messages. When you > close an application, that too is a window message. > > > > The fun part is, we can use that same process for our own purposes. > There's a simple API call, called SendMessage, that requires the hWnd of > the window you want to send a message too, the message ID (every process > has a static ID, but you can use RegisterWindowMessage to create your > own messageid (Unique to that particular machine)) and then two > parameters (both long integers). Hey, but wait, if all I can send > between two applications is two integers, what's the point? Well, you > can also create a window on the fly, with a single API, you can then set > it's window text to anything you want, and your recipient applications > can read that window text and destroy the window. > > > > I have this process in place (the communication part, now I'm on to > actually doing something with the comms), and it works great. Virtually > no overhead in the communication process, runs as smoothly as moving a > window across your screen. > > > > If there's interest in something like this, I'll post some code for it. > > > > Drew > > > > > The information contained in this transmission is intended only for the > person or entity to which it is addressed and may contain II-VI Proprietary > and/or II-VI BusinessSensitve material. If you are not the intended > recipient, please contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. You are notified that any > review, retransmission, copying, disclosure, dissemination, or other use of, > or taking of any action in reliance upon this information by persons or > entities other than the intended recipient is prohibited. > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From miscellany at mvps.org Fri Jul 13 18:53:00 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 14 Jul 2007 11:53:00 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <20070713232646.EA437BD09@smtp-auth.no-ip.com> References: <20070713232646.EA437BD09@smtp-auth.no-ip.com> Message-ID: <4698105C.4080509@mvps.org> John, That is very cool. Thanks. I am just learning about writing classes, given that there is such an emphasis on it in Access 2007. However, in this specific example, are you able to say whether this approach has any advantage over simple setting the Control Source property of the checkbox to: =[YourDateField] Is Not Null Regards Steve jwcolby wrote: > I often like to use dates as flags, i.e. if a process happened I want a date > that the process happened, if it did not happen, then I have a void for the > date. However it is often convenient for the user to see the flag as a > check box, i.e. they only care THAT it happened, not WHEN it happened. > Obviously a checkbox is about Boolean values, not dates. In order to > provide a check box interface to a date field in the database I designed a > WithEvents class. The class is passed in an UNBOUND checkbox (for the > visual display) and a BOUND text box (for the date storage). > > When the user checks the check box for the flag, the class sets or voids the > TEXTBOX VALUE property. The txt.Value is set to Date() if the checkbox is > set, and to VOID if the checkbox is cleared. > > Likewise the checkbox DISPLAYS a true if the value of the textbox is NOT > NULL and DISPLAYS a FALSE if the textbox.Value is NULL. > > This code is in actual use in one of my forms, and represents flags for > check stop payments and check voids in the database. > > The code for the class is as follows: > > '*************************************** > ' > 'This is the CLASS module. Cut and paste this into a new class, > 'then save to the name clsCtlChk2Date > ' > Option Compare Database > Option Explicit > ' > 'This class uses a check box to set / void a date in a record > 'The objective is to allow the form to set a date to date() if a check box > is checked > 'and set that date to void if the check box is cleared. > ' > 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID > 'and should display a FALSE if the date is VOID > ' > 'The class functions by passing in an UNBOUND check box which is the visual > indicator > 'A BOUND text box is passed in which actually stores the state of the flag > as a date data type > ' > 'Thus as the user clicks the check box, this class sets the underlying (and > invisible) text box > 'The text box VALUE property is set to DATE if the check box displays a TRUE > (is checked) > 'and the textbox VALUE property is set to NULL if the checkbox displays a > FALSE (is not checked) > ' > Private WithEvents mchk As CheckBox > Private mtxt As TextBox > > Private Sub Class_Terminate() > Set mchk = Nothing > Set mtxt = Nothing > End Sub > > Function init(lchk As CheckBox, ltxt As TextBox) > Set mchk = lchk > Set mtxt = ltxt > SetChkState > End Function > ' > 'This function causes the text box to track the visual state of the control > 'If the user clicks the check box and the check box ends up TRUE then set > the text box to Date() > 'else set the text box to VOID > ' > Private Sub mchk_Click() > On Error GoTo Err_mchk_Click > If IsNull(mtxt) Then > mtxt = Date > Else > mtxt = Null > End If > SetChkState > Exit_mchk_Click: > Exit Sub > Err_mchk_Click: > Select Case Err > Case 0 '.insert Errors you wish to ignore here > Resume Next > Case Else '.All other errors will trap > Beep > MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" > Resume Exit_mchk_Click > End Select > Resume 0 '.FOR TROUBLESHOOTING > End Sub > ' > 'This sub causes the visual state of the checkbox to track the text box > 'If the text box is VOID (no date) then display a FALSE > 'else display a TRUE > ' > Public Sub SetChkState() > On Error GoTo Err_SetChkState > If IsNull(mtxt) Then > mchk.Value = False > Else > mchk.Value = True > End If > Exit_SetChkState: > Exit Sub > Err_SetChkState: > Select Case Err > Case 0 '.insert Errors you wish to ignore here > Resume Next > Case Else '.All other errors will trap > Beep > MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" > Resume Exit_SetChkState > End Select > Resume 0 '.FOR TROUBLESHOOTING > End Sub > > '*************************************** > > It hooks in to the form as follows: > > '*************************************** > ' > 'This is the form's "code behind" module > ' > Option Compare Database > Option Explicit > Private fclsCtlVoidReq As clsctlChk2Date 'Dimension four > instances of the class > Private fclsCtlVoidProc As clsctlChk2Date > Private fclsCtlStopReq As clsctlChk2Date > Private fclsCtlStopProc As clsctlChk2Date > > Private Sub Form_Open(Cancel As Integer) > > Set fclsCtlStopReq = New clsctlChk2Date 'Instantiate the > first one > fclsCtlStopReq.init chkStopRequest, txtStopReq 'pass in an UNBOUND > check box and a BOUND text box > > Set fclsCtlStopProc = New clsctlChk2Date > fclsCtlStopProc.init chkStopProcessed, txtStopProcessed > > Set fclsCtlVoidReq = New clsctlChk2Date > fclsCtlVoidReq.init chkVoidRequest, txtVoidReq > > Set fclsCtlVoidProc = New clsctlChk2Date > fclsCtlVoidProc.init chkVoidProcessed, txtVoidProcessed > > End sub > > Private Sub Form_Current() > fclsCtlStopReq.SetChkState 'As the form moves through records, make the > checkbox display correctly > fclsCtlStopProc.SetChkState > fclsCtlVoidReq.SetChkState > fclsCtlVoidProc.SetChkState > End Sub > > '*************************************** > > That is all there is to it. This is another demonstration of where a class > sinking events can replace a TON of code placed directly in the form, making > code maintenance easier and also fo course making the concept usable in > other forms as well as the current form. > > I hope those who don't use classes find this useful in understanding how > classes can be useful, and how to implement classes and WithEvents to solve > everyday problems. > > Enjoy, > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > From jwcolby at colbyconsulting.com Fri Jul 13 23:22:47 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 14 Jul 2007 00:22:47 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <4698105C.4080509@mvps.org> Message-ID: <20070714042249.D0C17BD80@smtp-auth.no-ip.com> I suspect that would work for displaying the value, but I suspect that it would also prevent checking / unchecking the box since the check box could not set / clear what it is bound to. I haven't tried it yet though. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 13, 2007 7:53 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates John, That is very cool. Thanks. I am just learning about writing classes, given that there is such an emphasis on it in Access 2007. However, in this specific example, are you able to say whether this approach has any advantage over simple setting the Control Source property of the checkbox to: =[YourDateField] Is Not Null Regards Steve jwcolby wrote: > I often like to use dates as flags, i.e. if a process happened I want > a date that the process happened, if it did not happen, then I have a > void for the date. However it is often convenient for the user to see > the flag as a check box, i.e. they only care THAT it happened, not WHEN it happened. > Obviously a checkbox is about Boolean values, not dates. In order to > provide a check box interface to a date field in the database I > designed a WithEvents class. The class is passed in an UNBOUND > checkbox (for the visual display) and a BOUND text box (for the date storage). > > When the user checks the check box for the flag, the class sets or > voids the TEXTBOX VALUE property. The txt.Value is set to Date() if > the checkbox is set, and to VOID if the checkbox is cleared. > > Likewise the checkbox DISPLAYS a true if the value of the textbox is > NOT NULL and DISPLAYS a FALSE if the textbox.Value is NULL. > > This code is in actual use in one of my forms, and represents flags > for check stop payments and check voids in the database. > > The code for the class is as follows: > > '*************************************** > ' > 'This is the CLASS module. Cut and paste this into a new class, 'then > save to the name clsCtlChk2Date ' > Option Compare Database > Option Explicit > ' > 'This class uses a check box to set / void a date in a record 'The > objective is to allow the form to set a date to date() if a check box > is checked 'and set that date to void if the check box is cleared. > ' > 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID > 'and should display a FALSE if the date is VOID ' > 'The class functions by passing in an UNBOUND check box which is the > visual indicator 'A BOUND text box is passed in which actually stores > the state of the flag as a date data type ' > 'Thus as the user clicks the check box, this class sets the underlying > (and > invisible) text box > 'The text box VALUE property is set to DATE if the check box displays > a TRUE (is checked) 'and the textbox VALUE property is set to NULL if > the checkbox displays a FALSE (is not checked) ' > Private WithEvents mchk As CheckBox > Private mtxt As TextBox > > Private Sub Class_Terminate() > Set mchk = Nothing > Set mtxt = Nothing > End Sub > > Function init(lchk As CheckBox, ltxt As TextBox) > Set mchk = lchk > Set mtxt = ltxt > SetChkState > End Function > ' > 'This function causes the text box to track the visual state of the > control 'If the user clicks the check box and the check box ends up > TRUE then set the text box to Date() 'else set the text box to VOID ' > Private Sub mchk_Click() > On Error GoTo Err_mchk_Click > If IsNull(mtxt) Then > mtxt = Date > Else > mtxt = Null > End If > SetChkState > Exit_mchk_Click: > Exit Sub > Err_mchk_Click: > Select Case Err > Case 0 '.insert Errors you wish to ignore here > Resume Next > Case Else '.All other errors will trap > Beep > MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" > Resume Exit_mchk_Click > End Select > Resume 0 '.FOR TROUBLESHOOTING > End Sub > ' > 'This sub causes the visual state of the checkbox to track the text > box 'If the text box is VOID (no date) then display a FALSE 'else > display a TRUE ' > Public Sub SetChkState() > On Error GoTo Err_SetChkState > If IsNull(mtxt) Then > mchk.Value = False > Else > mchk.Value = True > End If > Exit_SetChkState: > Exit Sub > Err_SetChkState: > Select Case Err > Case 0 '.insert Errors you wish to ignore here > Resume Next > Case Else '.All other errors will trap > Beep > MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" > Resume Exit_SetChkState > End Select > Resume 0 '.FOR TROUBLESHOOTING > End Sub > > '*************************************** > > It hooks in to the form as follows: > > '*************************************** > ' > 'This is the form's "code behind" module ' > Option Compare Database > Option Explicit > Private fclsCtlVoidReq As clsctlChk2Date 'Dimension four > instances of the class > Private fclsCtlVoidProc As clsctlChk2Date Private fclsCtlStopReq As > clsctlChk2Date Private fclsCtlStopProc As clsctlChk2Date > > Private Sub Form_Open(Cancel As Integer) > > Set fclsCtlStopReq = New clsctlChk2Date 'Instantiate the > first one > fclsCtlStopReq.init chkStopRequest, txtStopReq 'pass in an UNBOUND > check box and a BOUND text box > > Set fclsCtlStopProc = New clsctlChk2Date > fclsCtlStopProc.init chkStopProcessed, txtStopProcessed > > Set fclsCtlVoidReq = New clsctlChk2Date > fclsCtlVoidReq.init chkVoidRequest, txtVoidReq > > Set fclsCtlVoidProc = New clsctlChk2Date > fclsCtlVoidProc.init chkVoidProcessed, txtVoidProcessed > > End sub > > Private Sub Form_Current() > fclsCtlStopReq.SetChkState 'As the form moves through records, make the > checkbox display correctly > fclsCtlStopProc.SetChkState > fclsCtlVoidReq.SetChkState > fclsCtlVoidProc.SetChkState > End Sub > > '*************************************** > > That is all there is to it. This is another demonstration of where a > class sinking events can replace a TON of code placed directly in the > form, making code maintenance easier and also fo course making the > concept usable in other forms as well as the current form. > > I hope those who don't use classes find this useful in understanding > how classes can be useful, and how to implement classes and WithEvents > to solve everyday problems. > > Enjoy, > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Sat Jul 14 00:38:58 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 14 Jul 2007 17:38:58 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <20070714042249.D0C17BD80@smtp-auth.no-ip.com> References: <20070714042249.D0C17BD80@smtp-auth.no-ip.com> Message-ID: <46986172.2070607@mvps.org> You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve jwcolby wrote: > I suspect that would work for displaying the value, but I suspect that it > would also prevent checking / unchecking the box since the check box could > not set / clear what it is bound to. I haven't tried it yet though. From jwcolby at colbyconsulting.com Sat Jul 14 00:47:36 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 14 Jul 2007 01:47:36 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <46986172.2070607@mvps.org> Message-ID: <20070714054738.CFE3DBD33@smtp-auth.no-ip.com> And that is what the code in the class does. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 14, 2007 1:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve jwcolby wrote: > I suspect that would work for displaying the value, but I suspect that > it would also prevent checking / unchecking the box since the check > box could not set / clear what it is bound to. I haven't tried it yet though. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Sat Jul 14 00:56:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 14 Jul 2007 01:56:23 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <46986172.2070607@mvps.org> Message-ID: <20070714055625.721BABC08@smtp-auth.no-ip.com> Oh, never mind. I see that you do it in the On Enter as opposed to the OnClick. Doing it this way would get rid of the need for the code in the OnCurrent event of the form. I will test that and see what I see. Simpler is better. Thanks for the feedback. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 14, 2007 1:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve jwcolby wrote: > I suspect that would work for displaying the value, but I suspect that > it would also prevent checking / unchecking the box since the check > box could not set / clear what it is bound to. I haven't tried it yet though. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Sat Jul 14 07:16:03 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sat, 14 Jul 2007 08:16:03 -0400 Subject: [AccessD] Bold tabs Message-ID: <29f585dd0707140516p7ce5f75dv72fda7d026ee4952@mail.gmail.com> I used to know how to do this. (My senior moments seem to be increasing in their frequency day by day by day!) I want to bold-face the tab strings. I cannot remember how I achieved this before. TIA, Arthur From dwaters at usinternet.com Sat Jul 14 08:18:40 2007 From: dwaters at usinternet.com (Dan Waters) Date: Sat, 14 Jul 2007 08:18:40 -0500 Subject: [AccessD] Bold tabs In-Reply-To: <29f585dd0707140516p7ce5f75dv72fda7d026ee4952@mail.gmail.com> References: <29f585dd0707140516p7ce5f75dv72fda7d026ee4952@mail.gmail.com> Message-ID: <000601c7c619$7edad0a0$0200a8c0@danwaters> In Design Mode, select the tab control (not one of the tabs). Then push the Bold formatting button. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Saturday, July 14, 2007 7:16 AM To: Access Developers discussion and problem solving Subject: [AccessD] Bold tabs I used to know how to do this. (My senior moments seem to be increasing in their frequency day by day by day!) I want to bold-face the tab strings. I cannot remember how I achieved this before. TIA, Arthur -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From adtp at airtelbroadband.in Sat Jul 14 09:27:32 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sat, 14 Jul 2007 19:57:32 +0530 Subject: [AccessD] Checkbox dates References: <20070714055625.721BABC08@smtp-auth.no-ip.com> Message-ID: <017701c7c623$ff888300$f857a27a@pcadt> Apparently the hidden bound text box used for storing date stamp is meant to act as a slave to the check box in question. This would imply that the contents of this text box are not to be disturbed unless there is user action on the check box. Is this correct ? If so, would it not be convenient to make the check box also a bound one ? AfterUpdate event of the check box should then be the most suitable event for placing Steve's code, and as already indicated by him, no code should be needed anywhere else. A.D.Tejpal --------------- ----- Original Message ----- From: jwcolby To: 'Access Developers discussion and problem solving' Sent: Saturday, July 14, 2007 11:26 Subject: Re: [AccessD] Checkbox dates Oh, never mind. I see that you do it in the On Enter as opposed to the OnClick. Doing it this way would get rid of the need for the code in the OnCurrent event of the form. I will test that and see what I see. Simpler is better. Thanks for the feedback. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 14, 2007 1:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve << SNIPPED >> From fuller.artful at gmail.com Sat Jul 14 11:03:57 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sat, 14 Jul 2007 12:03:57 -0400 Subject: [AccessD] Bold tabs In-Reply-To: <000601c7c619$7edad0a0$0200a8c0@danwaters> References: <29f585dd0707140516p7ce5f75dv72fda7d026ee4952@mail.gmail.com> <000601c7c619$7edad0a0$0200a8c0@danwaters> Message-ID: <29f585dd0707140903q9a3540cu63ce6eb161049d10@mail.gmail.com> That did it. Thank you so much! I kept selecting the tabs and it wouldn't work. Totally forgot about selecting the tab control itself. A. On 7/14/07, Dan Waters wrote: > > In Design Mode, select the tab control (not one of the tabs). Then push > the > Bold formatting button. > > Dan > From miscellany at mvps.org Sat Jul 14 16:44:53 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sun, 15 Jul 2007 09:44:53 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <017701c7c623$ff888300$f857a27a@pcadt> References: <20070714055625.721BABC08@smtp-auth.no-ip.com> <017701c7c623$ff888300$f857a27a@pcadt> Message-ID: <469943D5.9020603@mvps.org> Indoctrination in the evils of storing redundant data has thus far prevented me from considering this option, A.D., but I agree that it is a good solution, and a reminder that rules are to be interpreted flexibly. Regards Steve A.D.TEJPAL wrote: > Apparently the hidden bound text box used for storing date stamp is > meant to act as a slave to the check box in question. This would > imply that the contents of this text box are not to be disturbed > unless there is user action on the check box. Is this correct ? > > If so, would it not be convenient to make the check box also a bound > one ? AfterUpdate event of the check box should then be the most > suitable event for placing Steve's code, and as already indicated by > him, no code should be needed anywhere else. From jwcolby at colbyconsulting.com Sat Jul 14 16:48:32 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 14 Jul 2007 17:48:32 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <017701c7c623$ff888300$f857a27a@pcadt> Message-ID: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> In fact you really need a click event. Otherwise if a user tabbed through the control it would change just by getting the focus so to speak. The check box cannot be bound because it is a binary value, not a date type. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Saturday, July 14, 2007 10:28 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates Apparently the hidden bound text box used for storing date stamp is meant to act as a slave to the check box in question. This would imply that the contents of this text box are not to be disturbed unless there is user action on the check box. Is this correct ? If so, would it not be convenient to make the check box also a bound one ? AfterUpdate event of the check box should then be the most suitable event for placing Steve's code, and as already indicated by him, no code should be needed anywhere else. A.D.Tejpal --------------- ----- Original Message ----- From: jwcolby To: 'Access Developers discussion and problem solving' Sent: Saturday, July 14, 2007 11:26 Subject: Re: [AccessD] Checkbox dates Oh, never mind. I see that you do it in the On Enter as opposed to the OnClick. Doing it this way would get rid of the need for the code in the OnCurrent event of the form. I will test that and see what I see. Simpler is better. Thanks for the feedback. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Saturday, July 14, 2007 1:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates You are entirely correct, John. You couldn't check/uncheck the checkbox in the usual way, as it is a calculated control. If you wanted to do this, using the "old-fashioned" method, one way would be code something like this on the Enter event of the checkbox control: If Me.NameOfCheckbox Then Me.YourDateField = Null Else Me.YourDateField = Date End If Me.SomeOtherControl.SetFocus Regards Steve << SNIPPED >> -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Sat Jul 14 18:09:10 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sun, 15 Jul 2007 11:09:10 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> References: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> Message-ID: <46995796.8090802@mvps.org> John, Using the idea that I first suggested, with an unbound checkbox's Control Source set to: =[YourDateField] Is Not Null ... will not work with the Click event. The Click event will not fire with a calculated checkbox control. It has to be the Enter event, I think. Setting the checkbox's Tab Stop property to No would prevent the type of problem you envisage. I think A.D. was suggesting the checkbox be bound to a *separate, additional* field, Yes/No data type, in the table. I don't think he meant tying to bind the checkbox to the date field itself. Regards Steve jwcolby wrote: > In fact you really need a click event. Otherwise if a user tabbed through > the control it would change just by getting the focus so to speak. The > check box cannot be bound because it is a binary value, not a date type. > From adtp at airtelbroadband.in Sun Jul 15 00:30:38 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sun, 15 Jul 2007 11:00:38 +0530 Subject: [AccessD] Checkbox dates References: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> <46995796.8090802@mvps.org> Message-ID: <007501c7c6a1$a4cd70f0$5857a27a@pcadt> As correctly presumed by Steve, SourceControl for the bound check box is meant to be an independent field in the table (Yes/No type). In this particular situation, it could be said that having one field for date stamp and another for Yes/No status need not necessarily be regarded as a case of storing redundant data. While Yes/No field acts as the primary one, the date stamp field (hidden from the user) is utilized to store complimentary mirror data in frozen state, with historical significance. Independently bound check box as suggested by me is dictated by user's requirement (as mentioned by John), as the primary means of recording completion of a process. If the form happens to be in continuous form or datasheet view, an unbound check box would be untenable, leading to absurd display. Taking the concept further, in order to prevent inadvertent interference, it might even be desirable to deny de-selection of check box, after it has been selected (to confirm completion of a process) and the record in question has been saved. (Any further interference with a check box in selected status could then be made conditional to authorization at higher level). Sample code in AfterUpdate & Enter events of the checkbox, as given below, should suffice, to cover the requirements outlined above. A.D.Tejpal --------------- Code in form's module (CkStaus and TxtDtStamp are names of controls for check box & hidden text box respectively) ============================= Private Sub CkStatus_AfterUpdate() ' Insert date stamp if check box is selected ' Otherwise clear the date stamp If Me.CkStatus = True Then Me.TxtDtStamp = Date Else Me.TxtDtStamp = Null End If End Sub ------------------------------------------------------ Private Sub CkStatus_Enter() ' Lock the check box if in selected state If Me.CkStatus = True Then Me.CkStatus.Locked = True Else Me.CkStatus.Locked = False End If End Sub ============================= ----- Original Message ----- From: Steve Schapel To: Access Developers discussion and problem solving Sent: Sunday, July 15, 2007 04:39 Subject: Re: [AccessD] Checkbox dates John, Using the idea that I first suggested, with an unbound checkbox's Control Source set to: =[YourDateField] Is Not Null ... will not work with the Click event. The Click event will not fire with a calculated checkbox control. It has to be the Enter event, I think. Setting the checkbox's Tab Stop property to No would prevent the type of problem you envisage. I think A.D. was suggesting the checkbox be bound to a *separate, additional* field, Yes/No data type, in the table. I don't think he meant tying to bind the checkbox to the date field itself. Regards Steve << SNIPPED >> From miscellany at mvps.org Sun Jul 15 01:19:05 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sun, 15 Jul 2007 18:19:05 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <007501c7c6a1$a4cd70f0$5857a27a@pcadt> References: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com> <46995796.8090802@mvps.org> <007501c7c6a1$a4cd70f0$5857a27a@pcadt> Message-ID: <4699BC59.9090102@mvps.org> A.D., Not wishing to imply that I disagree with you in any way, because I like what you are suggesting. However... A.D.TEJPAL wrote: > ... If the form happens to be in > continuous form or datasheet view, an unbound check box would be > untenable, leading to absurd display. Just to be clear that I was not suggesting a totally unbound checkbox on the form, but rather one whose Control Source is like this: =[TheDateField] Is Not Null This serves the purpose of displaying, even on a continuous view form, whether the date has been recorded for each record. And equally, the code I suggested earlier, on the Enter event of the checkbox, can be used to manage the date data. I am just relating to how I have done this type of process in the past. I am certainly not claiming that it is superior to yours or John's suggested approaches. But I do know that it has effectively and simply served the purpose for me in various scenarios. Next time I need this type of functionality, I will be considering the idea of an extra (redundant ;-) ) field in the table, as you have described. Regards Steve From jwcolby at colbyconsulting.com Sun Jul 15 06:50:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sun, 15 Jul 2007 07:50:23 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <4699BC59.9090102@mvps.org> Message-ID: <20070715115028.DD5A2BD74@smtp-auth.no-ip.com> As we have discovered there are several ways to do this. I have used the method I suggested for other objects in the past and am comfortable with that. In fact, this is the kind of behavior that is a natural to migrate to my framework. By placing this behavior inside of my existing dclsCtlChkBox I can "turn on" the behavior by passing in a text box to a property of the dclsCtlChkBox and "voila" it would start behaving as a control for a date display. My dclsFrm can and does call each control already in it's OnCurrent event because of previous behaviors where the control needs to know when the form's current has fired (requerying dependent objects). Thus I will likely leave things the way they are for my usage, and you can modify the concept to suit your own requirements. I am content to have demonstrated how to use a class to encapsulate the behaviors required to perform this trick and get everyone thinking about classes and Event handling in classes. I do like A.D.s suggestion for allowing locking of the display based on the state of the display to preserve the fact that it happened. I already have users and groups in my LightWeight Security System built in to the framework so it is trivial to set up security to only allow specific groups to modify the control after it is locked. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 15, 2007 2:19 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates A.D., Not wishing to imply that I disagree with you in any way, because I like what you are suggesting. However... A.D.TEJPAL wrote: > ... If the form happens to be in > continuous form or datasheet view, an unbound check box would be > untenable, leading to absurd display. Just to be clear that I was not suggesting a totally unbound checkbox on the form, but rather one whose Control Source is like this: =[TheDateField] Is Not Null This serves the purpose of displaying, even on a continuous view form, whether the date has been recorded for each record. And equally, the code I suggested earlier, on the Enter event of the checkbox, can be used to manage the date data. I am just relating to how I have done this type of process in the past. I am certainly not claiming that it is superior to yours or John's suggested approaches. But I do know that it has effectively and simply served the purpose for me in various scenarios. Next time I need this type of functionality, I will be considering the idea of an extra (redundant ;-) ) field in the table, as you have described. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From adtp at airtelbroadband.in Sun Jul 15 09:08:02 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Sun, 15 Jul 2007 19:38:02 +0530 Subject: [AccessD] Checkbox dates References: <20070714214836.CD3E4BD56@smtp-auth.no-ip.com><46995796.8090802@ mvps.org> <007501c7c6a1$a4cd70f0$5857a27a@pcadt> <4699BC59.9090102@mvps.org> Message-ID: <005201c7c6e9$a593b970$4657a27a@pcadt> Steve, LOL! - Unbound checkbox was envisaged in John's original post. My comments were in that context, and by way of further elaboration of the course of action favored by you. Apparently, the scenario as originally presented, related to single form view. John has perfected a fascinating approach to form related matters. As stated by him, there are so many ways to meet the objectives, making Access all the more interesting. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Steve Schapel To: Access Developers discussion and problem solving Sent: Sunday, July 15, 2007 11:49 Subject: Re: [AccessD] Checkbox dates A.D., Not wishing to imply that I disagree with you in any way, because I like what you are suggesting. However... A.D.TEJPAL wrote: > ... If the form happens to be in > continuous form or datasheet view, an unbound check box would be untenable, leading to absurd display. Just to be clear that I was not suggesting a totally unbound checkbox on the form, but rather one whose Control Source is like this: =[TheDateField] Is Not Null This serves the purpose of displaying, even on a continuous view form, whether the date has been recorded for each record. And equally, the code I suggested earlier, on the Enter event of the checkbox, can be used to manage the date data. I am just relating to how I have done this type of process in the past. I am certainly not claiming that it is superior to yours or John's suggested approaches. But I do know that it has effectively and simply served the purpose for me in various scenarios. Next time I need this type of functionality, I will be considering the idea of an extra (redundant ;-) ) field in the table, as you have described. Regards Steve From accessd at shaw.ca Sun Jul 15 12:32:50 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 15 Jul 2007 10:32:50 -0700 Subject: [AccessD] Compile errors In-Reply-To: Message-ID: <0JL80088RDV9J600@l-daemon> Hi Gustav: A late response but things have been too busy here for checking the list. The client did some patching as was suggested and the app started working correctly. It is funny coincidence that when code increases in complexity the possibility of the program not working when moved to a client's site seems to go up exponentially as well. The dummer the more stable? Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Tuesday, July 10, 2007 8:54 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Compile errors Hi Jim This sounds like one of our all time classics. Broken References in Runtime AXP and A97: http://databaseadvisors.com/mailman/htdig/accessd/2003-July/011034.html The issue is caused by the two installations being not fully identical even though it may appear so. /gustav >>> accessd at shaw.ca 10-07-2007 17:40 >>> Hi All: Has anyone had a similar error: "compile error: User defined type not defined" I can not duplicate the error on my system and the client can not resolve the error on their system. They have the complete application, to the letter, running on their site. What could be causing this error as it appears they have virtually the same MS Access version that I do? TIA Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sun Jul 15 12:33:46 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 15 Jul 2007 10:33:46 -0700 Subject: [AccessD] Compile errors In-Reply-To: Message-ID: <0JL800A4ADWTGRG0@l-daemon> Hi Bryan: Late response but thank you. Client patching worked. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bryan Carbonnell Sent: Tuesday, July 10, 2007 9:09 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Compile errors On 7/10/07, Jim Lawrence wrote: > Has anyone had a similar error: "compile error: User defined type not > defined" I can not duplicate the error on my system and the client can not > resolve the error on their system. They have the complete application, to > the letter, running on their site. > > What could be causing this error as it appears they have virtually the same > MS Access version that I do? Jet SP levels is what I have found causes these errors. I had this error once because I had Jet SP6 and the users workstations had Jet SP3. Once I upgraded the workstations to Jet SP6 the error went away. MS has a tool, MDAC Utility: Component Checker, to see what versions and SP level the install is at. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Sun Jul 15 12:41:05 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 15 Jul 2007 10:41:05 -0700 Subject: [AccessD] Talking between Applications. In-Reply-To: Message-ID: <0JL800E4HE8Z5PC0@l-daemon> Hi Drew: As always I am interested in a fine piece of code which expands into new territory. TIA Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Friday, July 13, 2007 4:29 PM To: Access Developers discussion and problem solving Subject: [AccessD] Talking between Applications. Ya learn something new every day, don't ya? I've been re-writing an application I built 7 years ago. The new version is already in production, but I'll be adding new features probably for years to come. It's a help desk application, and one issue I'm working on is that there are several things that are 'monitored' events. Some events are lightning fast, some are a bit slower. The slower ones slow down the interface a bit, because it's all running in the same .exe. To fix this I thought about multithreading, but decided on just creating another application to do the monitoring. So how do you have one application talk to another? Before, I have used winsocks to do this. But it involves making socket connections, etc. This time, I dug into Window Messaging. I've done a lot of things with windows (in Windows) before, but I had to share this little tidbit with the List. To bring everyone up to snuff, every window on your machine has an hWnd value. That's the ID of each window. Windows sends all sorts of messages to each window, for every single thing that you do. When you move the mouse over a window, windows is firing window messages to that window with the mouse position. Clicking, typing, resizing, redrawing and more are all sent to the windows through window messages. When you close an application, that too is a window message. The fun part is, we can use that same process for our own purposes. There's a simple API call, called SendMessage, that requires the hWnd of the window you want to send a message too, the message ID (every process has a static ID, but you can use RegisterWindowMessage to create your own messageid (Unique to that particular machine)) and then two parameters (both long integers). Hey, but wait, if all I can send between two applications is two integers, what's the point? Well, you can also create a window on the fly, with a single API, you can then set it's window text to anything you want, and your recipient applications can read that window text and destroy the window. I have this process in place (the communication part, now I'm on to actually doing something with the comms), and it works great. Virtually no overhead in the communication process, runs as smoothly as moving a window across your screen. If there's interest in something like this, I'll post some code for it. Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Sun Jul 15 12:55:15 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sun, 15 Jul 2007 13:55:15 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: <005201c7c6e9$a593b970$4657a27a@pcadt> Message-ID: <20070715175517.10513BE4F@smtp-auth.no-ip.com> A.D. It did indeed relate to single form view. This is a data entry screen of a fairly complex record where continuous view simply doesn't work well. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL Sent: Sunday, July 15, 2007 10:08 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Checkbox dates Steve, LOL! - Unbound checkbox was envisaged in John's original post. My comments were in that context, and by way of further elaboration of the course of action favored by you. Apparently, the scenario as originally presented, related to single form view. John has perfected a fascinating approach to form related matters. As stated by him, there are so many ways to meet the objectives, making Access all the more interesting. Best wishes, A.D.Tejpal --------------- ----- Original Message ----- From: Steve Schapel To: Access Developers discussion and problem solving Sent: Sunday, July 15, 2007 11:49 Subject: Re: [AccessD] Checkbox dates A.D., Not wishing to imply that I disagree with you in any way, because I like what you are suggesting. However... A.D.TEJPAL wrote: > ... If the form happens to be in > continuous form or datasheet view, an unbound check box would be untenable, leading to absurd display. Just to be clear that I was not suggesting a totally unbound checkbox on the form, but rather one whose Control Source is like this: =[TheDateField] Is Not Null This serves the purpose of displaying, even on a continuous view form, whether the date has been recorded for each record. And equally, the code I suggested earlier, on the Enter event of the checkbox, can be used to manage the date data. I am just relating to how I have done this type of process in the past. I am certainly not claiming that it is superior to yours or John's suggested approaches. But I do know that it has effectively and simply served the purpose for me in various scenarios. Next time I need this type of functionality, I will be considering the idea of an extra (redundant ;-) ) field in the table, as you have described. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Sun Jul 15 15:34:42 2007 From: dwaters at usinternet.com (Dan Waters) Date: Sun, 15 Jul 2007 15:34:42 -0500 Subject: [AccessD] 2007 System Table? Message-ID: <000001c7c71f$964fbc30$0200a8c0@danwaters> I just opened a customer's BE file remotely (written in Access 2003). It has four system tables I've never seen before - one of them is MSysNavPaneGroupCategories, and they all start with MSysNavPane. I'm guessing that someone has opened this using Access 2007. Is that correct? Dan Waters From martyconnelly at shaw.ca Sun Jul 15 15:56:12 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Sun, 15 Jul 2007 13:56:12 -0700 Subject: [AccessD] 2007 System Table? In-Reply-To: <000001c7c71f$964fbc30$0200a8c0@danwaters> References: <000001c7c71f$964fbc30$0200a8c0@danwaters> Message-ID: <469A89EC.60207@shaw.ca> Yup they should contain XML instructions for the 2007 Ribbon Bar Dan Waters wrote: >I just opened a customer's BE file remotely (written in Access 2003). It >has four system tables I've never seen before - one of them is >MSysNavPaneGroupCategories, and they all start with MSysNavPane. > >I'm guessing that someone has opened this using Access 2007. Is that >correct? > > >Dan Waters > > > -- Marty Connelly Victoria, B.C. Canada From miscellany at mvps.org Sun Jul 15 16:21:31 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 16 Jul 2007 09:21:31 +1200 Subject: [AccessD] Checkbox dates In-Reply-To: <20070715115028.DD5A2BD74@smtp-auth.no-ip.com> References: <20070715115028.DD5A2BD74@smtp-auth.no-ip.com> Message-ID: <469A8FDB.6080706@mvps.org> John, jwcolby wrote: > ... I am content to have > demonstrated how to use a class to encapsulate the behaviors required to > perform this trick and get everyone thinking about classes and Event > handling in classes. I recognise that this was your initial intention, and for this I thank you. Sorry if the discussion went too far off on a tangent. Regards Steve From darrend at nimble.com.au Sun Jul 15 18:48:25 2007 From: darrend at nimble.com.au (Darren D) Date: Mon, 16 Jul 2007 09:48:25 +1000 Subject: [AccessD] Talking between Applications. In-Reply-To: Message-ID: <200707152348.l6FNmlBI029468@databaseadvisors.com> Howdy Would love to see an example of this DD -----Original Message----- From: Drew Wutka [mailto:DWUTKA at marlow.com] Sent: Saturday, 14 July 2007 9:29 AM To: Access Developers discussion and problem solving Subject: [AccessD] Talking between Applications. Ya learn something new every day, don't ya? I've been re-writing an application I built 7 years ago. The new version is already in production, but I'll be adding new features probably for years to come. It's a help desk application, and one issue I'm working on is that there are several things that are 'monitored' events. Some events are lightning fast, some are a bit slower. The slower ones slow down the interface a bit, because it's all running in the same .exe. To fix this I thought about multithreading, but decided on just creating another application to do the monitoring. So how do you have one application talk to another? Before, I have used winsocks to do this. But it involves making socket connections, etc. This time, I dug into Window Messaging. I've done a lot of things with windows (in Windows) before, but I had to share this little tidbit with the List. To bring everyone up to snuff, every window on your machine has an hWnd value. That's the ID of each window. Windows sends all sorts of messages to each window, for every single thing that you do. When you move the mouse over a window, windows is firing window messages to that window with the mouse position. Clicking, typing, resizing, redrawing and more are all sent to the windows through window messages. When you close an application, that too is a window message. The fun part is, we can use that same process for our own purposes. There's a simple API call, called SendMessage, that requires the hWnd of the window you want to send a message too, the message ID (every process has a static ID, but you can use RegisterWindowMessage to create your own messageid (Unique to that particular machine)) and then two parameters (both long integers). Hey, but wait, if all I can send between two applications is two integers, what's the point? Well, you can also create a window on the fly, with a single API, you can then set it's window text to anything you want, and your recipient applications can read that window text and destroy the window. I have this process in place (the communication part, now I'm on to actually doing something with the comms), and it works great. Virtually no overhead in the communication process, runs as smoothly as moving a window across your screen. If there's interest in something like this, I'll post some code for it. Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From pcs at azizaz.com Sun Jul 15 21:06:23 2007 From: pcs at azizaz.com (pcs at azizaz.com) Date: Mon, 16 Jul 2007 12:06:23 +1000 (EST) Subject: [AccessD] Lock of Record - Memofields Message-ID: <20070716120623.CYC21380@dommail.onthenet.com.au> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... This is the setup: Access2003 .mdb with SQL Server2005 Backend. Access .mdb is set to 'no record locks' and so are all Forms. Around 60 Users sitting in the application all day using Terminal Server. All tables odbc linked. There's a main Summary Form with a number of pre-defined filters. The Summary Form is populated using ADO recordset. >From Summary Form User clicks on a record line to access the Detail Form. The Detail Form consists of of a subform control that dynamically loads one of four different subforms. The main form is unbound. Each of the Subforms uses the same record from the same table as source. On the main Form there are four different labels - the click event here loads a particular subform into the subform control. The subform is populated using an ADO recordset call. On the Main Form there are two command buttons: Enter Edit Mode (setting the allow edits property of the Form to Yes) Exit Edit Mode (setting the allow edits property of the Form to No) The subform is always opened in "View Mode", i.e. the allow edits property of the SubForm is set to No. I am using the following record locking scheme : When User is clicking on Enter Edit Mode, code checks the record in question - using ADO call - to see if two fields on the record: "LockedBy" and "LockedDateTime" are null. If they are null, the ADO code updates the two fields with UserName and Current Date Time, and calls the record in again from the table to display on the SubForm currently selected and sets the 'allow edits' to true on the SubForm. The Exit Edit Mode sets the two fields to null and saves the record doing a straight docmd.save. This Exit Edit Mode code is fired before User is leaving the record/form or executing other code than runs an update query on the same record. However, we are encountering the situation where User when exiting the Edit Mode gets the *Access* Lock Message, where User can either drop changes or save changes. User has been instructed to drop changes, which causes the record on the Form to be set back to View Mode with the LockedBy and LockedDateTime Fields still set, resulting in User now 'locking' himself out of the homemade locking scheme. I am pulling out my hair trying to figure out what is causing the built in *Access* Lock Message. I have been over the code in detail making sure that User is not able to create changes to the record while in Edit mode other than via the Form. Other Users can obviously not access the same record via the Form in Edit mode and there is no code in the user interface that runs an update query on the same record. So what is causing the *Access* Lock messages? I searched the AccessD Archives the other day and I suspect the cause might be Memo Fields. If I understand what I read in the AccessD archives correct: Access on records with MemoFields are stil applying page locks and not record locks? There are five memo fields on the record of the table in question. Thank you for reading this far! What's your take on this? Is it the memo fields that are causing this?? What can I do to remedy this situation? The memo fields are basically comments fields. Is this a way to go: Place each comments in separate table in a record with a 255 character field - one to many relationship with main table (and include a comments type field), and on retrieving the main record build up the comments from the associated records into one unbound text control?? Currently the Comments memofield is popuplated and looks like this: 2007-05-23 12:35 jcitizen: Comments Text (vbCrLf) 2007-05-22 15:40 bbrown: Another Comments Text (vbCrLf) in descending date order Regards borge From galeper at gmail.com Sun Jul 15 21:22:22 2007 From: galeper at gmail.com (Gale Perez) Date: Sun, 15 Jul 2007 19:22:22 -0700 Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected, But Not Displayed Message-ID: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> Hello, I'm normalizing a db to replace certain fields with lookup fields. I used the lookup wizard and am storing an autonumber from the lookup table. All updated just fine, except for one. The old field is a text field consisting of the numbers 0-7. I created a query to update the new field (in the example, 8 is the autonumber PK in the lookup table): UPDATE mytable SET mytable.newfield = 8 WHERE (((mytable.[oldfield])="7")); But when I opened the table to verify the new field's data matched that in the old field, I saw that the new field showed nothing but zeros. When I clicked in that field of a particular record, my dropdown box appeared, with the correct value selected - but it is not being displayed! What the heck is going on? Has anyone else had this happen? I tried re-creating both the query and the field, and got the same results. Thank you very much for any thoughts! Gale From tortise at paradise.net.nz Sun Jul 15 21:20:50 2007 From: tortise at paradise.net.nz (Tortise) Date: Mon, 16 Jul 2007 14:20:50 +1200 Subject: [AccessD] Lock of Record - Memofields References: <20070716120623.CYC21380@dommail.onthenet.com.au> Message-ID: <068501c7c74f$eda05500$1e00a8c0@cheqsoft.local> I'd love to know the answer to this one too! We have an Access 2003 database which does much the same it seems, no SQL backend, problem is intermittent and is almost certainly associated with one memo field which locks after a small number of saves are made in it. The other fields save fine. The kludge we used was to add a second memo onto the form and save subsequent edits to that, which works reliably!!! I posted a long time ago about this but no one came up with a solution that I could work. Kind regards David Hingston ----- Original Message ----- From: To: "Access Developers discussion and problem solving" Sent: Monday, July 16, 2007 2:06 PM Subject: [AccessD] Lock of Record - Memofields Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... This is the setup: Access2003 .mdb with SQL Server2005 Backend. Access .mdb is set to 'no record locks' and so are all Forms. Around 60 Users sitting in the application all day using Terminal Server. All tables odbc linked. There's a main Summary Form with a number of pre-defined filters. The Summary Form is populated using ADO recordset. >From Summary Form User clicks on a record line to access the Detail Form. The Detail Form consists of of a subform control that dynamically loads one of four different subforms. The main form is unbound. Each of the Subforms uses the same record from the same table as source. On the main Form there are four different labels - the click event here loads a particular subform into the subform control. The subform is populated using an ADO recordset call. On the Main Form there are two command buttons: Enter Edit Mode (setting the allow edits property of the Form to Yes) Exit Edit Mode (setting the allow edits property of the Form to No) The subform is always opened in "View Mode", i.e. the allow edits property of the SubForm is set to No. I am using the following record locking scheme : When User is clicking on Enter Edit Mode, code checks the record in question - using ADO call - to see if two fields on the record: "LockedBy" and "LockedDateTime" are null. If they are null, the ADO code updates the two fields with UserName and Current Date Time, and calls the record in again from the table to display on the SubForm currently selected and sets the 'allow edits' to true on the SubForm. The Exit Edit Mode sets the two fields to null and saves the record doing a straight docmd.save. This Exit Edit Mode code is fired before User is leaving the record/form or executing other code than runs an update query on the same record. However, we are encountering the situation where User when exiting the Edit Mode gets the *Access* Lock Message, where User can either drop changes or save changes. User has been instructed to drop changes, which causes the record on the Form to be set back to View Mode with the LockedBy and LockedDateTime Fields still set, resulting in User now 'locking' himself out of the homemade locking scheme. I am pulling out my hair trying to figure out what is causing the built in *Access* Lock Message. I have been over the code in detail making sure that User is not able to create changes to the record while in Edit mode other than via the Form. Other Users can obviously not access the same record via the Form in Edit mode and there is no code in the user interface that runs an update query on the same record. So what is causing the *Access* Lock messages? I searched the AccessD Archives the other day and I suspect the cause might be Memo Fields. If I understand what I read in the AccessD archives correct: Access on records with MemoFields are stil applying page locks and not record locks? There are five memo fields on the record of the table in question. Thank you for reading this far! What's your take on this? Is it the memo fields that are causing this?? What can I do to remedy this situation? The memo fields are basically comments fields. Is this a way to go: Place each comments in separate table in a record with a 255 character field - one to many relationship with main table (and include a comments type field), and on retrieving the main record build up the comments from the associated records into one unbound text control?? Currently the Comments memofield is popuplated and looks like this: 2007-05-23 12:35 jcitizen: Comments Text (vbCrLf) 2007-05-22 15:40 bbrown: Another Comments Text (vbCrLf) in descending date order Regards borge -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From kp at sdsonline.net Sun Jul 15 21:27:13 2007 From: kp at sdsonline.net (Kath Pelletti) Date: Mon, 16 Jul 2007 12:27:13 +1000 Subject: [AccessD] Performance tips anyone? Message-ID: <01fa01c7c750$d2848600$6401a8c0@office> Having been away for a couple of weeks I am late in posting on this topic - there were some great suggestions made. I just wanted to add that in addition to all those things, I speeded up an app of mine by removing record sources of all combos (as previously suggested) and then using code which only populates the combo after the user types in eg. 3 letters. That way, not all data is bound to the combo when it's not needed. ______________________________________ Kath Pelletti From phpons at gmail.com Mon Jul 16 01:29:37 2007 From: phpons at gmail.com (philippe pons) Date: Mon, 16 Jul 2007 08:29:37 +0200 Subject: [AccessD] Talking between Applications. In-Reply-To: <200707152348.l6FNmlBI029468@databaseadvisors.com> References: <200707152348.l6FNmlBI029468@databaseadvisors.com> Message-ID: <57144ced0707152329u6e8676f8iee0b7659562ab429@mail.gmail.com> Hi, I'm curious to have a look at that too ! Philippe 2007/7/16, Darren D : > > Howdy > > Would love to see an example of this > > DD > > -----Original Message----- > From: Drew Wutka [mailto:DWUTKA at marlow.com] > Sent: Saturday, 14 July 2007 9:29 AM > To: Access Developers discussion and problem solving > Subject: [AccessD] Talking between Applications. > > Ya learn something new every day, don't ya? I've been re-writing an > application I built 7 years ago. The new version is already in > production, but I'll be adding new features probably for years to come. > It's a help desk application, and one issue I'm working on is that there > are several things that are 'monitored' events. Some events are > lightning fast, some are a bit slower. The slower ones slow down the > interface a bit, because it's all running in the same .exe. To fix this > I thought about multithreading, but decided on just creating another > application to do the monitoring. So how do you have one application > talk to another? > > > > Before, I have used winsocks to do this. But it involves making socket > connections, etc. This time, I dug into Window Messaging. I've done a > lot of things with windows (in Windows) before, but I had to share this > little tidbit with the List. > > > > To bring everyone up to snuff, every window on your machine has an hWnd > value. That's the ID of each window. Windows sends all sorts of > messages to each window, for every single thing that you do. When you > move the mouse over a window, windows is firing window messages to that > window with the mouse position. Clicking, typing, resizing, redrawing > and more are all sent to the windows through window messages. When you > close an application, that too is a window message. > > > > The fun part is, we can use that same process for our own purposes. > There's a simple API call, called SendMessage, that requires the hWnd of > the window you want to send a message too, the message ID (every process > has a static ID, but you can use RegisterWindowMessage to create your > own messageid (Unique to that particular machine)) and then two > parameters (both long integers). Hey, but wait, if all I can send > between two applications is two integers, what's the point? Well, you > can also create a window on the fly, with a single API, you can then set > it's window text to anything you want, and your recipient applications > can read that window text and destroy the window. > > > > I have this process in place (the communication part, now I'm on to > actually doing something with the comms), and it works great. Virtually > no overhead in the communication process, runs as smoothly as moving a > window across your screen. > > > > If there's interest in something like this, I'll post some code for it. > > > > Drew > > > > > The information contained in this transmission is intended only for the > person > or entity to which it is addressed and may contain II-VI Proprietary > and/or > II-VI BusinessSensitve material. If you are not the intended recipient, > please > contact the sender immediately and destroy the material in its entirety, > whether > electronic or hard copy. You are notified that any review, retransmission, > copying, disclosure, dissemination, or other use of, or taking of any > action in > reliance upon this information by persons or entities other than the > intended > recipient is prohibited. > > > > -- > 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 Mon Jul 16 04:05:57 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 16 Jul 2007 11:05:57 +0200 Subject: [AccessD] Checkbox dates Message-ID: Hi John et al Sorry to disturb the romance, but you all seem to forget that a Checkbox can be set/reset by pressing +/- and toggled by pressing the spacebar. Also, pressing a hotkey combo (Alt + a letter of the associated label) will toggle the Checkbox. I once expanded these keypress options a bit with a subfunction you may call at the OnKeyPress event: Private Sub chkSomeCheckbox_KeyPress(KeyAscii As Integer) Call CheckboxKeyPress(Me!chkSomeCheckbox, KeyAscii) End Sub Sub CheckboxKeyPress(ByRef chk As CheckBox, ByVal bytKeyAscii As Byte) ' Add more key entries than the standard (+, -, and Space) ' to set/reset or toggle the checkbox. ' ' 1998-10-08. Cactus Data ApS Dim booCheck As Boolean Select Case UCase(Chr(bytKeyAscii)) ' List of key entries for set (True). Case "1", "Y", "T", "S", "J" booCheck = True ' List of key entries for reset (False). Case "0", "N", "F", "R" booCheck = False ' List of key entries for toggle. Case "*", "X", "C" booCheck = Not chk.value Case Else ' No change. booCheck = chk.value End Select ' Only change state if needed. If chk.value Xor booCheck Then chk.value = booCheck End If End Sub This - or at least the default OnKeyPress behaviour - could easily be incorporated in the class. /gustav >>> miscellany at mvps.org 15-07-2007 23:21 >>> John, jwcolby wrote: > ... I am content to have > demonstrated how to use a class to encapsulate the behaviors required to > perform this trick and get everyone thinking about classes and Event > handling in classes. I recognise that this was your initial intention, and for this I thank you. Sorry if the discussion went too far off on a tangent. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Mon Jul 16 04:41:01 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 16 Jul 2007 11:41:01 +0200 Subject: [AccessD] Lock of Record - Memofields Message-ID: Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... This is the setup: Access2003 .mdb with SQL Server2005 Backend. Access .mdb is set to 'no record locks' and so are all Forms. Around 60 Users sitting in the application all day using Terminal Server. All tables odbc linked. There's a main Summary Form with a number of pre-defined filters. The Summary Form is populated using ADO recordset. >From Summary Form User clicks on a record line to access the Detail Form. The Detail Form consists of of a subform control that dynamically loads one of four different subforms. The main form is unbound. Each of the Subforms uses the same record from the same table as source. On the main Form there are four different labels - the click event here loads a particular subform into the subform control. The subform is populated using an ADO recordset call. On the Main Form there are two command buttons: Enter Edit Mode (setting the allow edits property of the Form to Yes) Exit Edit Mode (setting the allow edits property of the Form to No) The subform is always opened in "View Mode", i.e. the allow edits property of the SubForm is set to No. I am using the following record locking scheme : When User is clicking on Enter Edit Mode, code checks the record in question - using ADO call - to see if two fields on the record: "LockedBy" and "LockedDateTime" are null. If they are null, the ADO code updates the two fields with UserName and Current Date Time, and calls the record in again from the table to display on the SubForm currently selected and sets the 'allow edits' to true on the SubForm. The Exit Edit Mode sets the two fields to null and saves the record doing a straight docmd.save. This Exit Edit Mode code is fired before User is leaving the record/form or executing other code than runs an update query on the same record. However, we are encountering the situation where User when exiting the Edit Mode gets the *Access* Lock Message, where User can either drop changes or save changes. User has been instructed to drop changes, which causes the record on the Form to be set back to View Mode with the LockedBy and LockedDateTime Fields still set, resulting in User now 'locking' himself out of the homemade locking scheme. I am pulling out my hair trying to figure out what is causing the built in *Access* Lock Message. I have been over the code in detail making sure that User is not able to create changes to the record while in Edit mode other than via the Form. Other Users can obviously not access the same record via the Form in Edit mode and there is no code in the user interface that runs an update query on the same record. So what is causing the *Access* Lock messages? I searched the AccessD Archives the other day and I suspect the cause might be Memo Fields. If I understand what I read in the AccessD archives correct: Access on records with MemoFields are stil applying page locks and not record locks? There are five memo fields on the record of the table in question. Thank you for reading this far! What's your take on this? Is it the memo fields that are causing this?? What can I do to remedy this situation? The memo fields are basically comments fields. Is this a way to go: Place each comments in separate table in a record with a 255 character field - one to many relationship with main table (and include a comments type field), and on retrieving the main record build up the comments from the associated records into one unbound text control?? Currently the Comments memofield is popuplated and looks like this: 2007-05-23 12:35 jcitizen: Comments Text (vbCrLf) 2007-05-22 15:40 bbrown: Another Comments Text (vbCrLf) in descending date order Regards borge From pcs at azizaz.com Mon Jul 16 08:35:00 2007 From: pcs at azizaz.com (Borge Hansen) Date: Mon, 16 Jul 2007 23:35:00 +1000 Subject: [AccessD] Lock of Record - Memofields References: Message-ID: <005a01c7c7ae$1c4a5960$fa10a8c0@Albatross> Hi Gustav, I don't get it .... please explain what the me.dirty = false can do in this context. ... also, I admit I didn't get David's method either... borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Monday, July 16, 2007 7:41 PM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... ...... From Gustav at cactus.dk Mon Jul 16 09:17:32 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 16 Jul 2007 16:17:32 +0200 Subject: [AccessD] Lock of Record - Memofields Message-ID: Hi Borge It tells the form to save the record using the method of the form for this purpose. More precisely, it should look: If Me.Dirty = True Then ' The record has been edited. ' Save the record. Me.Dirty = False End If I'm not saying this is the magic cure. However, DoCmd operations may not always work as expected under stress, and it may be a stress situation when you - at the same time - wish to save a record and move to the next. /gustav >>> pcs at azizaz.com 16-07-2007 15:35 >>> Hi Gustav, I don't get it .... please explain what the me.dirty = false can do in this context. ... also, I admit I didn't get David's method either... borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Monday, July 16, 2007 7:41 PM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... From jwcolby at colbyconsulting.com Mon Jul 16 09:58:51 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 16 Jul 2007 10:58:51 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: Message-ID: <20070716145854.97E81BD2D@smtp-auth.no-ip.com> These methods do not fire the click event? When I test the + and - keys the click event fires. Likewise when pressing the space bar. This is the behavior I expect to happen since these keys emulate a mouse click. So my code works for those three keyboard events. The toggle works as you expect, it toggles the control. MY code also toggles the control using the - and the + whereas yours (hopefully) clears for the - and sets for the +. Unfortunately, making matters worse, BOTH the keypress and the click events happen. The keypress happens first, then the click event happens. So if I "set" the date field in the keypress, then the click event comes along and sees the value set and clears it. If the keypress event clears the event, the click event comes along and sets it. This makes it APPEAR that the keystroke - plus or minus - is doing the OPPOSITE of what it is supposed to do, when in fact it is doing exactly what it is supposed to do. In order to get around this unfortunate "helping hand", I added a flag to track that a KeyPressed occurred (set in KeyPress) and if so do NOT execute the OnClick code (flag always cleared in OnClick). Thus the code morphs to: '********************************************** Option Compare Database Option Explicit ' 'This class uses a check box to set / void a date in a record 'The objective is to allow the form to set a date to date() if a check box is checked 'and set that date to void if the check box is cleared. ' 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID 'and should display a FALSE if the date is VOID ' 'The class functions by passing in an UNBOUND check box which is the visual indicator 'A BOUND text box is passed in which actually stores the state of the flag as a date data type ' 'Thus as the user clicks the check box, this class sets the underlying (and invisible) text box 'The text box VALUE property is set to DATE if the check box displays a TRUE (is checked) 'and the textbox VALUE property is set to NULL if the checkbox displays a FALSE (is not checked) ' Private WithEvents mchk As CheckBox Private mtxt As TextBox Private Const cstrEventProc As String = "[Event Procedure]" Private mblnKeyPressed As Boolean Private Sub Class_Terminate() Set mchk = Nothing Set mtxt = Nothing End Sub Function init(lchk As CheckBox, ltxt As TextBox) Set mchk = lchk mchk.OnClick = cstrEventProc mchk.OnKeyPress = cstrEventProc Set mtxt = ltxt SetChkState End Function ' 'This function causes the text box to track the visual state of the control 'If the user clicks the check box and the check box ends up TRUE then set the text box to Date() 'else set the text box to VOID ' Private Sub mchk_Click() On Error GoTo Err_mchk_Click ' 'KeyPressed occurs first (if it happens) so short circuit the click event handler if KeyPressed ' If Not mblnKeyPressed Then If IsNull(mtxt.Value) Then mtxt.Value = Date Else mtxt.Value = Null End If SetChkState End If mblnKeyPressed = False Exit_mchk_Click: Exit Sub Err_mchk_Click: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" Resume Exit_mchk_Click End Select Resume 0 '.FOR TROUBLESHOOTING End Sub ' 'This sub causes the visual state of the checkbox to track the text box 'If the text box is VOID (no date) then display a FALSE 'else display a TRUE ' Public Sub SetChkState() On Error GoTo Err_SetChkState If IsNull(mtxt.Value) Then mchk.Value = False Else mchk.Value = True End If Exit_SetChkState: Exit Sub Err_SetChkState: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" Resume Exit_SetChkState End Select Resume 0 '.FOR TROUBLESHOOTING End Sub Private Sub mchk_KeyPress(KeyAscii As Integer) Dim bytKeyAscii As Byte bytKeyAscii = CByte(KeyAscii) Select Case Chr(bytKeyAscii) Case "+" If IsNull(mtxt.Value) Then mtxt.Value = Date End If mblnKeyPressed = True Case "-" If Not IsNull(mtxt.Value) Then mtxt.Value = Null End If mblnKeyPressed = True Case Else End Select SetChkState End Sub '********************************************** Notice in particular the new blnKeyPressed flag in the header, the code to SET the flag in mchk_KeyPress ONLY in the case of the + or -, and the code in mchk_Click to not execute the normal click code if the blnKeyPressed flag is set, and always clearing the flag. By my testing this now correctly handles the keyboard issues raised by Gustav. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, July 16, 2007 5:06 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Checkbox dates Hi John et al Sorry to disturb the romance, but you all seem to forget that a Checkbox can be set/reset by pressing +/- and toggled by pressing the spacebar. Also, pressing a hotkey combo (Alt + a letter of the associated label) will toggle the Checkbox. I once expanded these keypress options a bit with a subfunction you may call at the OnKeyPress event: Private Sub chkSomeCheckbox_KeyPress(KeyAscii As Integer) Call CheckboxKeyPress(Me!chkSomeCheckbox, KeyAscii) End Sub Sub CheckboxKeyPress(ByRef chk As CheckBox, ByVal bytKeyAscii As Byte) ' Add more key entries than the standard (+, -, and Space) ' to set/reset or toggle the checkbox. ' ' 1998-10-08. Cactus Data ApS Dim booCheck As Boolean Select Case UCase(Chr(bytKeyAscii)) ' List of key entries for set (True). Case "1", "Y", "T", "S", "J" booCheck = True ' List of key entries for reset (False). Case "0", "N", "F", "R" booCheck = False ' List of key entries for toggle. Case "*", "X", "C" booCheck = Not chk.value Case Else ' No change. booCheck = chk.value End Select ' Only change state if needed. If chk.value Xor booCheck Then chk.value = booCheck End If End Sub This - or at least the default OnKeyPress behaviour - could easily be incorporated in the class. /gustav From cfoust at infostatsystems.com Mon Jul 16 10:06:01 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 16 Jul 2007 08:06:01 -0700 Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected, But Not Displayed In-Reply-To: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> References: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> Message-ID: Opening a data view of an action query may not display anything useful, if that's what you're describing. Or do you mean that you ran the query and got zeros instead of 8s? Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gale Perez Sent: Sunday, July 15, 2007 7:22 PM To: accessd at databaseadvisors.com Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected,But Not Displayed Hello, I'm normalizing a db to replace certain fields with lookup fields. I used the lookup wizard and am storing an autonumber from the lookup table. All updated just fine, except for one. The old field is a text field consisting of the numbers 0-7. I created a query to update the new field (in the example, 8 is the autonumber PK in the lookup table): UPDATE mytable SET mytable.newfield = 8 WHERE (((mytable.[oldfield])="7")); But when I opened the table to verify the new field's data matched that in the old field, I saw that the new field showed nothing but zeros. When I clicked in that field of a particular record, my dropdown box appeared, with the correct value selected - but it is not being displayed! What the heck is going on? Has anyone else had this happen? I tried re-creating both the query and the field, and got the same results. Thank you very much for any thoughts! Gale -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Mon Jul 16 10:29:55 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Mon, 16 Jul 2007 15:29:55 +0000 Subject: [AccessD] Spellcheck from Access to web??? In-Reply-To: Message-ID: Hello All, Wasn't sure what subject to use...I have a web based app(not mine...so any webpage where you type stuff)...I need to spell check the text in a field. There is not a feature in the app. Any ideas on getting RunCommand acCmdSpelling to look at a field on a web page? I know its a little "out there"... Thanks, Mark A. Matte _________________________________________________________________ http://liveearth.msn.com From Gustav at cactus.dk Mon Jul 16 10:41:59 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Mon, 16 Jul 2007 17:41:59 +0200 Subject: [AccessD] Checkbox dates Message-ID: Hi John Interesting. I should have tested more carefully, sorry. But since when has a keypress raised an OnClick event? I don't see the relation between these two events. It must be a special case for the checkbox control. But that being so, couldn't you just eat the keypress and skip all the flag stuff? Like: Private Sub mchk_KeyPress(KeyAscii As Integer) KeyAscii = 0 End Sub But no. This eats +/- and the hotkey but not the spacebar. Go figure. /gustav >>> jwcolby at colbyconsulting.com 16-07-2007 16:58 >>> These methods do not fire the click event? When I test the + and - keys the click event fires. Likewise when pressing the space bar. This is the behavior I expect to happen since these keys emulate a mouse click. So my code works for those three keyboard events. The toggle works as you expect, it toggles the control. MY code also toggles the control using the - and the + whereas yours (hopefully) clears for the - and sets for the +. Unfortunately, making matters worse, BOTH the keypress and the click events happen. The keypress happens first, then the click event happens. So if I "set" the date field in the keypress, then the click event comes along and sees the value set and clears it. If the keypress event clears the event, the click event comes along and sets it. This makes it APPEAR that the keystroke - plus or minus - is doing the OPPOSITE of what it is supposed to do, when in fact it is doing exactly what it is supposed to do. In order to get around this unfortunate "helping hand", I added a flag to track that a KeyPressed occurred (set in KeyPress) and if so do NOT execute the OnClick code (flag always cleared in OnClick). Thus the code morphs to: '********************************************** Option Compare Database Option Explicit ' 'This class uses a check box to set / void a date in a record 'The objective is to allow the form to set a date to date() if a check box is checked 'and set that date to void if the check box is cleared. ' 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID 'and should display a FALSE if the date is VOID ' 'The class functions by passing in an UNBOUND check box which is the visual indicator 'A BOUND text box is passed in which actually stores the state of the flag as a date data type ' 'Thus as the user clicks the check box, this class sets the underlying (and invisible) text box 'The text box VALUE property is set to DATE if the check box displays a TRUE (is checked) 'and the textbox VALUE property is set to NULL if the checkbox displays a FALSE (is not checked) ' Private WithEvents mchk As CheckBox Private mtxt As TextBox Private Const cstrEventProc As String = "[Event Procedure]" Private mblnKeyPressed As Boolean Private Sub Class_Terminate() Set mchk = Nothing Set mtxt = Nothing End Sub Function init(lchk As CheckBox, ltxt As TextBox) Set mchk = lchk mchk.OnClick = cstrEventProc mchk.OnKeyPress = cstrEventProc Set mtxt = ltxt SetChkState End Function ' 'This function causes the text box to track the visual state of the control 'If the user clicks the check box and the check box ends up TRUE then set the text box to Date() 'else set the text box to VOID ' Private Sub mchk_Click() On Error GoTo Err_mchk_Click ' 'KeyPressed occurs first (if it happens) so short circuit the click event handler if KeyPressed ' If Not mblnKeyPressed Then If IsNull(mtxt.Value) Then mtxt.Value = Date Else mtxt.Value = Null End If SetChkState End If mblnKeyPressed = False Exit_mchk_Click: Exit Sub Err_mchk_Click: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" Resume Exit_mchk_Click End Select Resume 0 '.FOR TROUBLESHOOTING End Sub ' 'This sub causes the visual state of the checkbox to track the text box 'If the text box is VOID (no date) then display a FALSE 'else display a TRUE ' Public Sub SetChkState() On Error GoTo Err_SetChkState If IsNull(mtxt.Value) Then mchk.Value = False Else mchk.Value = True End If Exit_SetChkState: Exit Sub Err_SetChkState: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" Resume Exit_SetChkState End Select Resume 0 '.FOR TROUBLESHOOTING End Sub Private Sub mchk_KeyPress(KeyAscii As Integer) Dim bytKeyAscii As Byte bytKeyAscii = CByte(KeyAscii) Select Case Chr(bytKeyAscii) Case "+" If IsNull(mtxt.Value) Then mtxt.Value = Date End If mblnKeyPressed = True Case "-" If Not IsNull(mtxt.Value) Then mtxt.Value = Null End If mblnKeyPressed = True Case Else End Select SetChkState End Sub '********************************************** Notice in particular the new blnKeyPressed flag in the header, the code to SET the flag in mchk_KeyPress ONLY in the case of the + or -, and the code in mchk_Click to not execute the normal click code if the blnKeyPressed flag is set, and always clearing the flag. By my testing this now correctly handles the keyboard issues raised by Gustav. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, July 16, 2007 5:06 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Checkbox dates Hi John et al Sorry to disturb the romance, but you all seem to forget that a Checkbox can be set/reset by pressing +/- and toggled by pressing the spacebar. Also, pressing a hotkey combo (Alt + a letter of the associated label) will toggle the Checkbox. I once expanded these keypress options a bit with a subfunction you may call at the OnKeyPress event: Private Sub chkSomeCheckbox_KeyPress(KeyAscii As Integer) Call CheckboxKeyPress(Me!chkSomeCheckbox, KeyAscii) End Sub Sub CheckboxKeyPress(ByRef chk As CheckBox, ByVal bytKeyAscii As Byte) ' Add more key entries than the standard (+, -, and Space) ' to set/reset or toggle the checkbox. ' ' 1998-10-08. Cactus Data ApS Dim booCheck As Boolean Select Case UCase(Chr(bytKeyAscii)) ' List of key entries for set (True). Case "1", "Y", "T", "S", "J" booCheck = True ' List of key entries for reset (False). Case "0", "N", "F", "R" booCheck = False ' List of key entries for toggle. Case "*", "X", "C" booCheck = Not chk.value Case Else ' No change. booCheck = chk.value End Select ' Only change state if needed. If chk.value Xor booCheck Then chk.value = booCheck End If End Sub This - or at least the default OnKeyPress behaviour - could easily be incorporated in the class. /gustav From jwcolby at colbyconsulting.com Mon Jul 16 11:04:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 16 Jul 2007 12:04:23 -0400 Subject: [AccessD] Checkbox dates In-Reply-To: Message-ID: <20070716160426.51A01BDF1@smtp-auth.no-ip.com> Gustav, >But since when has a keypress raised an OnClick event? I know, what a PITA. Furthermore the keypress event (but not the click event) is fired for ANY keypress while the checkbox has the focus including the tab that moves the focus into the checkbox. That is why I just decided to go the "simple route" and sense the + and - and bypass the click event for those two keys press events. Furthermore I couldn't just "eat" the key event because my click event code causes a TOGGLE of the checkbox. If I ate the key event for the + and - then those keys would still cause the click event and cause a toggle instead of the correct "clear for a -" and "set for a +". Anyway, AFAICT my code as last published functions correctly. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, July 16, 2007 11:42 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Checkbox dates Hi John Interesting. I should have tested more carefully, sorry. But since when has a keypress raised an OnClick event? I don't see the relation between these two events. It must be a special case for the checkbox control. But that being so, couldn't you just eat the keypress and skip all the flag stuff? Like: Private Sub mchk_KeyPress(KeyAscii As Integer) KeyAscii = 0 End Sub But no. This eats +/- and the hotkey but not the spacebar. Go figure. /gustav >>> jwcolby at colbyconsulting.com 16-07-2007 16:58 >>> These methods do not fire the click event? When I test the + and - keys the click event fires. Likewise when pressing the space bar. This is the behavior I expect to happen since these keys emulate a mouse click. So my code works for those three keyboard events. The toggle works as you expect, it toggles the control. MY code also toggles the control using the - and the + whereas yours (hopefully) clears for the - and sets for the +. Unfortunately, making matters worse, BOTH the keypress and the click events happen. The keypress happens first, then the click event happens. So if I "set" the date field in the keypress, then the click event comes along and sees the value set and clears it. If the keypress event clears the event, the click event comes along and sets it. This makes it APPEAR that the keystroke - plus or minus - is doing the OPPOSITE of what it is supposed to do, when in fact it is doing exactly what it is supposed to do. In order to get around this unfortunate "helping hand", I added a flag to track that a KeyPressed occurred (set in KeyPress) and if so do NOT execute the OnClick code (flag always cleared in OnClick). Thus the code morphs to: '********************************************** Option Compare Database Option Explicit ' 'This class uses a check box to set / void a date in a record 'The objective is to allow the form to set a date to date() if a check box is checked 'and set that date to void if the check box is cleared. ' 'Likewise the checkbox should DISPLAY a TRUE if the date is NOT VOID 'and should display a FALSE if the date is VOID ' 'The class functions by passing in an UNBOUND check box which is the visual indicator 'A BOUND text box is passed in which actually stores the state of the flag as a date data type ' 'Thus as the user clicks the check box, this class sets the underlying (and invisible) text box 'The text box VALUE property is set to DATE if the check box displays a TRUE (is checked) 'and the textbox VALUE property is set to NULL if the checkbox displays a FALSE (is not checked) ' Private WithEvents mchk As CheckBox Private mtxt As TextBox Private Const cstrEventProc As String = "[Event Procedure]" Private mblnKeyPressed As Boolean Private Sub Class_Terminate() Set mchk = Nothing Set mtxt = Nothing End Sub Function init(lchk As CheckBox, ltxt As TextBox) Set mchk = lchk mchk.OnClick = cstrEventProc mchk.OnKeyPress = cstrEventProc Set mtxt = ltxt SetChkState End Function ' 'This function causes the text box to track the visual state of the control 'If the user clicks the check box and the check box ends up TRUE then set the text box to Date() 'else set the text box to VOID ' Private Sub mchk_Click() On Error GoTo Err_mchk_Click ' 'KeyPressed occurs first (if it happens) so short circuit the click event handler if KeyPressed ' If Not mblnKeyPressed Then If IsNull(mtxt.Value) Then mtxt.Value = Date Else mtxt.Value = Null End If SetChkState End If mblnKeyPressed = False Exit_mchk_Click: Exit Sub Err_mchk_Click: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.mchk_Click" Resume Exit_mchk_Click End Select Resume 0 '.FOR TROUBLESHOOTING End Sub ' 'This sub causes the visual state of the checkbox to track the text box 'If the text box is VOID (no date) then display a FALSE 'else display a TRUE ' Public Sub SetChkState() On Error GoTo Err_SetChkState If IsNull(mtxt.Value) Then mchk.Value = False Else mchk.Value = True End If Exit_SetChkState: Exit Sub Err_SetChkState: Select Case Err Case 0 '.insert Errors you wish to ignore here Resume Next Case Else '.All other errors will trap Beep MsgBox Err.Description, , "Error in Sub clsctlChk2Date.SetChkState" Resume Exit_SetChkState End Select Resume 0 '.FOR TROUBLESHOOTING End Sub Private Sub mchk_KeyPress(KeyAscii As Integer) Dim bytKeyAscii As Byte bytKeyAscii = CByte(KeyAscii) Select Case Chr(bytKeyAscii) Case "+" If IsNull(mtxt.Value) Then mtxt.Value = Date End If mblnKeyPressed = True Case "-" If Not IsNull(mtxt.Value) Then mtxt.Value = Null End If mblnKeyPressed = True Case Else End Select SetChkState End Sub '********************************************** Notice in particular the new blnKeyPressed flag in the header, the code to SET the flag in mchk_KeyPress ONLY in the case of the + or -, and the code in mchk_Click to not execute the normal click code if the blnKeyPressed flag is set, and always clearing the flag. By my testing this now correctly handles the keyboard issues raised by Gustav. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, July 16, 2007 5:06 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Checkbox dates Hi John et al Sorry to disturb the romance, but you all seem to forget that a Checkbox can be set/reset by pressing +/- and toggled by pressing the spacebar. Also, pressing a hotkey combo (Alt + a letter of the associated label) will toggle the Checkbox. I once expanded these keypress options a bit with a subfunction you may call at the OnKeyPress event: Private Sub chkSomeCheckbox_KeyPress(KeyAscii As Integer) Call CheckboxKeyPress(Me!chkSomeCheckbox, KeyAscii) End Sub Sub CheckboxKeyPress(ByRef chk As CheckBox, ByVal bytKeyAscii As Byte) ' Add more key entries than the standard (+, -, and Space) ' to set/reset or toggle the checkbox. ' ' 1998-10-08. Cactus Data ApS Dim booCheck As Boolean Select Case UCase(Chr(bytKeyAscii)) ' List of key entries for set (True). Case "1", "Y", "T", "S", "J" booCheck = True ' List of key entries for reset (False). Case "0", "N", "F", "R" booCheck = False ' List of key entries for toggle. Case "*", "X", "C" booCheck = Not chk.value Case Else ' No change. booCheck = chk.value End Select ' Only change state if needed. If chk.value Xor booCheck Then chk.value = booCheck End If End Sub This - or at least the default OnKeyPress behaviour - could easily be incorporated in the class. /gustav -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Mon Jul 16 11:41:45 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Mon, 16 Jul 2007 16:41:45 +0000 Subject: [AccessD] Access 2007: Lookup Field Shows Correct ValueSelected, But Not Displayed In-Reply-To: Message-ID: In the table properties...how many columns are in the rowsource of your lookup...and what are your column widths? Thanks, Mark A. Matte >From: "Charlotte Foust" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] Access 2007: Lookup Field Shows Correct >ValueSelected, But Not Displayed >Date: Mon, 16 Jul 2007 08:06:01 -0700 > >Opening a data view of an action query may not display anything useful, >if that's what you're describing. Or do you mean that you ran the query >and got zeros instead of 8s? > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gale Perez >Sent: Sunday, July 15, 2007 7:22 PM >To: accessd at databaseadvisors.com >Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value >Selected,But Not Displayed > >Hello, > >I'm normalizing a db to replace certain fields with lookup fields. I >used the lookup wizard and am storing an autonumber from the lookup >table. All updated just fine, except for one. The old field is a text >field consisting of the numbers 0-7. I created a query to update the >new field (in the example, 8 is the autonumber PK in the lookup table): > >UPDATE mytable SET mytable.newfield = 8 >WHERE (((mytable.[oldfield])="7")); > >But when I opened the table to verify the new field's data matched that >in the old field, I saw that the new field showed nothing but zeros. >When I clicked in that field of a particular record, my dropdown box >appeared, with >the correct value selected - but it is not being displayed! What the >heck >is going on? Has anyone else had this happen? > >I tried re-creating both the query and the field, and got the same >results. > >Thank you very much for any thoughts! >Gale >-- >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 _________________________________________________________________ Need a brain boost? Recharge with a stimulating game. Play now!? http://club.live.com/home.aspx?icid=club_hotmailtextlink1 From miscellany at mvps.org Mon Jul 16 12:20:04 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 17 Jul 2007 05:20:04 +1200 Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected, But Not Displayed In-Reply-To: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> References: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> Message-ID: <469BA8C4.9070708@mvps.org> Gale, You may be interested in this article: http://www.mvps.org/access/lookupfields.htm Regards Steve Gale Perez wrote: > Hello, > > I'm normalizing a db to replace certain fields with lookup fields. I used > the lookup wizard and am storing an autonumber from the lookup table. All > updated just fine, except for one. The old field is a text field consisting > of the numbers 0-7. I created a query to update the new field (in the > example, 8 is the autonumber PK in the lookup table): > > UPDATE mytable SET mytable.newfield = 8 > WHERE (((mytable.[oldfield])="7")); > > But when I opened the table to verify the new field's data matched that in > the old field, I saw that the new field showed nothing but zeros. When I > clicked in that field of a particular record, my dropdown box appeared, with > the correct value selected - but it is not being displayed! What the heck > is going on? Has anyone else had this happen? > > I tried re-creating both the query and the field, and got the same results. > > Thank you very much for any thoughts! > Gale From galeper at gmail.com Mon Jul 16 12:36:36 2007 From: galeper at gmail.com (Gale Perez) Date: Mon, 16 Jul 2007 10:36:36 -0700 Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value Selected, But Not Displayed In-Reply-To: References: <5b2621db0707151922ga11bde0s58f4c8b7f03c298c@mail.gmail.com> Message-ID: <5b2621db0707161036oad3c521l1a090e38f15ef918@mail.gmail.com> Hi Charlotte, I ran the query, and when I opened the table (not the query results), it showed all zeros. Yet when I clicked in the field, the dropdown box showed that the correct value was selected (highlighted), it just isn't being displayed. Thank you, Gale On 7/16/07, Charlotte Foust wrote: > > Opening a data view of an action query may not display anything useful, > if that's what you're describing. Or do you mean that you ran the query > and got zeros instead of 8s? > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gale Perez > Sent: Sunday, July 15, 2007 7:22 PM > To: accessd at databaseadvisors.com > Subject: [AccessD] Access 2007: Lookup Field Shows Correct Value > Selected,But Not Displayed > > Hello, > > I'm normalizing a db to replace certain fields with lookup fields. I > used the lookup wizard and am storing an autonumber from the lookup > table. All updated just fine, except for one. The old field is a text > field consisting of the numbers 0-7. I created a query to update the > new field (in the example, 8 is the autonumber PK in the lookup table): > > UPDATE mytable SET mytable.newfield = 8 > WHERE (((mytable.[oldfield])="7")); > > But when I opened the table to verify the new field's data matched that > in the old field, I saw that the new field showed nothing but zeros. > When I clicked in that field of a particular record, my dropdown box > appeared, with > the correct value selected - but it is not being displayed! What the > heck > is going on? Has anyone else had this happen? > > I tried re-creating both the query and the field, and got the same > results. > > Thank you very much for any thoughts! > Gale > -- > 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 DWUTKA at Marlow.com Mon Jul 16 16:52:08 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:52:08 -0500 Subject: [AccessD] Sample Of Talking between applications WAS(Talking between Applications.) In-Reply-To: <29f585dd0707131641k49abbb2dud087ac3c605a81a2@mail.gmail.com> Message-ID: Ok, I have gotten to a point with the code where I can give you a sample. After this, my code is going to be very specific for the application I'm working on. I broke the system down to 3 class modules, one basic module, and a form. Here's what the components do: (the system I'm working on is the ISFE (Information Services Front End, so that's why I have things prefixed,etc with ISFE). Class: ISFEMessage: This is a class used to manage the data sent between applications. It has a message type, data collection, etc. Messaging through windows only allows two Long Integer parameters. This class creates a 'temp' window to allow for the transfer of more information (text). So it has code to create, read and destroy that temp window, and it breaks the data into a collection to be used. In my sample, the first parameter is used as the message type, the second can be used as a single datapoint, for instance, one of the things the ISFE Monitor (application I am building to support the ISFE) is going to do, is monitor for new requests. When it finds a new request, it can message the ISFE with just the Ticket Number (which is a long integer), so it doesn't need the 'temp' window process. Class: ISFEMessaging: This class is the core messaging class. It creates a window to subclass and monitor for windows messages. The first line in it's initialization code registers a unique windows message "ISFEMessage". That string can be anything. You could have 2 different systems that register their own unique message ID, and the same code will only pick up it's particular window messages. Class: ISFEMonitoring: This class does the work for messages coming through. The demo just has code for a 'pulse' which justs sends dummy messages back and for. Module: SubClassingHook: This module has a global variable for an instance of ISFEMessaging, and then has the callback procedure to hook the window used in ISFEMessaging. Form: Just sample code to show how to use the above four objects. I'll send an email with the source for each of these. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 13, 2007 6:42 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Talking between Applications. I've done something similar a few years back in PowerBuilder, but would love a look at your method. I don't have any immediate use for it, but this old dog does like to learn occasional new tricks. Arthur The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:55:23 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:55:23 -0500 Subject: [AccessD] ISFEMessage Class (talking between applications) Message-ID: Option Explicit Private Declare Function CreateWindowEx Lib "user32" Alias "CreateWindowExA" (ByVal dwExStyle As Long, ByVal lpClassName As String, ByVal lpWindowName As String, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As Long, ByVal hMenu As Long, ByVal hInstance As Long, lpParam As Any) As Long Private Declare Function DestroyWindow Lib "user32" (ByVal hwnd As Long) As Long Private Declare Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hwnd As Long, ByVal lpString As String, ByVal cch As Long) As Long Private Declare Function SetWindowText Lib "user32" Alias "SetWindowTextA" (ByVal hwnd As Long, ByVal lpString As String) As Long Private Const HWND_BROADCAST = &HFFFF& Dim strType As String Dim DataCollection As Collection Dim DataNames As Collection Public FirstParameter As Long Public SecondParameter As Long Property Get DataCount() As Long DataCount = DataNames.Count End Property Property Get DataInfo(strName As String) As String DataInfo = DataCollection(strName) End Property Public Function AddData(ByVal strDataName As String, ByVal strData As String) On Error Resume Next DataCollection.Remove strDataName DataNames.Remove strDataName DataCollection.Add strData, strDataName DataNames.Add strDataName End Function Private Function GetStringSegment(ByRef strData As String) As String Dim intLength As Long intLength = Asc(Left(strData, 1)) GetStringSegment = Mid(strData, 2, intLength) strData = Mid(strData, intLength + 2) End Function Private Function CreateStringSegment(ByVal strToCreate As String) As String If Len(strToCreate) > 255 Then strToCreate = Left(strToCreate, 255) CreateStringSegment = Chr(Len(strToCreate)) & strToCreate End Function Private Function SetDataToWindow() As Long Dim strDataToSend As String Dim inthWndOfWindow As Long Dim i As Long strDataToSend = CreateStringSegment(Me.MessageType) strDataToSend = strDataToSend & CreateStringSegment("" & SecondParameter) For i = 1 To DataCollection.Count strDataToSend = strDataToSend & CreateStringSegment(DataNames(i)) & CreateStringSegment(DataCollection(i)) Next i FirstParameter = -3 SecondParameter = CreateWindowEx(0, "STATIC", strDataToSend, 0, 0, 0, 0, 0, 0, 0, App.hInstance, ByVal 0&) imMessaging.SendISFEMessage imMessaging.ISFE2007hWnd, FirstParameter, SecondParameter End Function Private Sub Class_Initialize() Set DataCollection = New Collection Set DataNames = New Collection End Sub Private Sub Class_Terminate() Set DataCollection = Nothing Set DataNames = Nothing End Sub Property Get MessageType() As String MessageType = strType End Property Public Function ProcessIncomingData() Select Case FirstParameter Case -2 strType = "Handshake" Case -1 strType = "Pulse" Case 1 strType = "NewRequest" 'This is for the ISFE Case -3 Dim strText As String Dim strName As String Dim strData As String Dim intLen As Long intLen = 256 ^ 2 strText = Space(intLen) intLen = GetWindowText(SecondParameter, strText, intLen) If intLen > 0 Then strText = Left(strText, intLen) strType = GetStringSegment(strText) SecondParameter = CLng(GetStringSegment(strText)) Do Until strText = "" strName = GetStringSegment(strText) strData = GetStringSegment(strText) DataCollection.Add strData, strName DataNames.Add strName Loop End If DestroyWindow SecondParameter End Select End Function Property Let MessageType(strEnter As String) strType = strEnter Select Case strType Case "Handshake" FirstParameter = -2 Case "Pulse" FirstParameter = -1 Case "NewRequest" FirstParameter = 1 End Select End Property Public Function SendData() If DataCollection.Count = 0 Then imMessaging.SendISFEMessage imMessaging.ISFE2007hWnd, FirstParameter, SecondParameter Else SetDataToWindow End If End Function Public Function BroadcastData() imMessaging.SendISFEMessage HWND_BROADCAST, FirstParameter, SecondParameter End Function The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:55:54 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:55:54 -0500 Subject: [AccessD] ISFEMessaging Class (talking between applications) Message-ID: Option Explicit Private Declare Function CreateWindowEx Lib "user32" Alias "CreateWindowExA" (ByVal dwExStyle As Long, ByVal lpClassName As String, ByVal lpWindowName As String, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As Long, ByVal hMenu As Long, ByVal hInstance As Long, lpParam As Any) As Long Private Declare Function DestroyWindow Lib "user32" (ByVal hwnd As Long) As Long Private Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long Private Declare Function RegisterWindowMessage Lib "user32" Alias "RegisterWindowMessageA" (ByVal lpString As String) As Long Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long Const GWL_WNDPROC = -4 Public PreviousHwnd As Long Public ISFE2007hWnd As Long Dim intMessageHookHwnd As Long Dim intISFEMessageID As Long Event ISFEMessage(im As ISFEMessage) Event HandshakeCompleted(intRemoteHwnd As Long) Private Sub Class_Initialize() intISFEMessageID = RegisterWindowMessage("ISFEMessage") intMessageHookHwnd = CreateWindowEx(0, "STATIC", "", 0, 0, 0, 0, 0, 0, 0, App.hInstance, ByVal 0&) PreviousHwnd = SetWindowLong(intMessageHookHwnd, GWL_WNDPROC, AddressOf WindowProc) End Sub Public Function IncomingWindowMessage(intMessage As Long, intWParameter As Long, intLParameter As Long) Select Case intMessage Case intISFEMessageID Dim im As ISFEMessage Set im = New ISFEMessage im.FirstParameter = intWParameter im.SecondParameter = intLParameter im.ProcessIncomingData If Not ProcessMessage(im) Then RaiseEvent ISFEMessage(im) Set im = Nothing End Select End Function Private Sub Class_Terminate() Dim dwReturn As Long dwReturn = SetWindowLong(intMessageHookHwnd, GWL_WNDPROC, PreviousHwnd) DestroyWindow intMessageHookHwnd End Sub Public Function SendISFEMessage(ByVal inthWnd As Long, ByVal intParameter1 As Long, ByVal intParameter2 As Long) SendMessage inthWnd, intISFEMessageID, intParameter1, intParameter2 End Function Public Function Handshake() Dim im As ISFEMessage Set im = New ISFEMessage im.MessageType = "Handshake" im.SecondParameter = intMessageHookHwnd im.BroadcastData Set im = Nothing End Function Private Function ProcessMessage(im As ISFEMessage) As Boolean ProcessMessage = True Select Case im.MessageType Case "Handshake" If im.SecondParameter <> intMessageHookHwnd Then If Me.ISFE2007hWnd = 0 Then Me.ISFE2007hWnd = im.SecondParameter im.SecondParameter = intMessageHookHwnd im.SendData RaiseEvent HandshakeCompleted(Me.ISFE2007hWnd) End If End If Case Else ProcessMessage = False End Select End Function The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:56:36 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:56:36 -0500 Subject: [AccessD] ISFEMonitoring Class (talking between applications) Message-ID: Option Explicit Dim WithEvents tmrMessages As Timer Dim Messages As Collection Dim WithEvents Messaging As ISFEMessaging Event MonitoringEvent(strTextToDisplay As String) Private Sub Class_Initialize() Set Messages = New Collection Set tmrMessages = frmMain.tmrMessages Set Messaging = imMessaging End Sub Private Sub Class_Terminate() Set Messages = Nothing Set tmrMessages = Nothing Set Messaging = Nothing End Sub Private Sub Messaging_HandshakeCompleted(intRemoteHwnd As Long) RaiseEvent MonitoringEvent("Handshake Complete with hWnd: " & intRemoteHwnd) End Sub Private Sub Messaging_ISFEMessage(im As ISFEMessage) Messages.Add im tmrMessages.Enabled = True End Sub Private Sub tmrMessages_Timer() Dim im As ISFEMessage Do Until Messages.Count = 0 Set im = Messages(1) ProcessMessage im Messages.Remove (1) Loop tmrMessages.Enabled = False End Sub Private Function ProcessMessage(im As ISFEMessage) Select Case im.MessageType Case "Pulse" RaiseEvent MonitoringEvent("Pulse: " & im.SecondParameter & " - " & im.DataInfo("CurrentTime")) If im.SecondParameter > 0 Then im.SecondParameter = im.SecondParameter - 1 im.AddData "CurrentTime", "Time: " & Format(Time, "dd/mm/yyyy hh:mm:ss") im.SendData Set im = Nothing End If End Select End Function The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:57:25 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:57:25 -0500 Subject: [AccessD] modSubClassHooking Module (talking between applications) Message-ID: Option Explicit Private Declare Function CallWindowProc Lib "user32" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hwnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long Public imMessaging As ISFEMessaging Public Function WindowProc(ByVal hw As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long WindowProc = CallWindowProc(imMessaging.PreviousHwnd, hw, uMsg, wParam, lParam) imMessaging.IncomingWindowMessage uMsg, wParam, lParam End Function The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 16:58:24 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 16:58:24 -0500 Subject: [AccessD] frmMain Form (Talking between applications) Message-ID: Option Explicit Dim WithEvents ISFEMon As ISFEMonitoring Private Sub cmdHandshake_Click() imMessaging.Handshake End Sub Private Sub cmdPulse_Click() Dim im As ISFEMessage Set im = New ISFEMessage im.MessageType = "Pulse" im.SecondParameter = 1000 im.AddData "CurrentTime", "Time: " & Format(Time, "dd/mm/yyyy hh:mm:ss") im.SendData Set im = Nothing End Sub Private Sub Form_Load() Me.Caption = Me.hwnd Set imMessaging = New ISFEMessaging Set ISFEMon = New ISFEMonitoring End Sub Private Sub Form_Unload(Cancel As Integer) Set ISFEMon = Nothing Set imMessaging = Nothing End Sub Private Sub ISFEMon_MonitoringEvent(strTextToDisplay As String) Me.lstData.AddItem strTextToDisplay, 0 End Sub The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Mon Jul 16 17:09:32 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 16 Jul 2007 17:09:32 -0500 Subject: [AccessD] Talking between Applications (final notes) Message-ID: Just an FYI, the code I have posted is in use in VB 6. It should work fine with Access VBA, but I know there will be two quirks. First, the ISFEMonitoring class uses frmMain's timer, the code will have to be changed for that, because Access forms have the timers as a native object, instead of a separate object. The timer is used to allow the windows messaging API's to completely finish before trying to do something with the message that came through. During testing, without this process in place, when I ran a 'pulse', it would run about 80 times before the code would just stop. No errors, it just stopped sending, because the code was firing messages back and forth without letting each progressive message finish on it's own. So instead of working the with message immediately, it's added to a collection, and the timer is used to kick start the process of working with the messages. The other quirk is that frmMain is adding messages to a listbox, in VB, you can just use an AddItem method, can't do that with an Access listbox. So another method should be used to display message results. There is also functionality that isn't used in the sample. The ISFEMessage has two ways it can be sent. SendMessage and BroadcastMessage. To use sendmessage, the ISFEMonitoring class must handshake, so it can find the hWnd of the window it's supposed to communicate with. It only needs to handshake once, then SendMessage will send messages back and forth between the same two applications. (which is what the pulse 'test' process does). BroadcastMessage (which I don't demo with the form) sends a message to EVERY window out there. Note, I only have it working for sending a long integer (through the SecondParameter) value of the ISFEMessage class. To broadcast other data, the receiving windows would have to NOT destroy the data window. I don't need this capability, so I didn't setup my code to do this. One ideas, if broadcasting text data is necessary, would be to just create a single 'data' window, and keep it open while the class is in use, then destroy it when the ISFEMessaging class terminates. Keep in mind, the window being used would be hidden from a user's desktop, but can be viewed with all sorts of utilities. (Which is why I destroy the window in the 1 to 1 process I have setup). Okey dokey, hope someone finds some use for this, I'm off to starting putting it into my actual application. Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From martyconnelly at shaw.ca Mon Jul 16 17:38:42 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Mon, 16 Jul 2007 15:38:42 -0700 Subject: [AccessD] Info: Microsoft to offer code protection, validation to software developers In-Reply-To: <005401cb255b$d1b7dad0$48619a89@DDICK> References: <40F80AD8.18919.6D50350@lexacorp.com.pg> <005401cb255b$d1b7dad0$48619a89@DDICK> Message-ID: <469BF372.8050609@shaw.ca> Microsoft to offer code protection, validation to other software developers The first release covers .Net then Win32 exe, Don't know if it will cover VBA http://blogs.zdnet.com/microsoft/?p=575&tag=nl.e539 http://www.microsoft.com/presspass/features/2007/jul07/07-10slpservices.mspx?rss_fdn=Top%20Stories The first is the Code Protector SDK. This is a software development toolkit with an intuitive user interface, application programming interfaces (APIs) and code samples, which will be available at no charge from the Microsoft Download Center. A version of it will also be included in the next version of Visual Studio, code-named ?Orcas.? This toolkit is specifically designed to help protect and fully transform managed code or .NET code. Full code transformation for Win32, or native code, is on our product roadmap and will be coming soon, but licensing and activation of native code applications will be available with the first release. The Code Protector SDK also allows developers to easily mark features as ?licensable entities? that can later be controlled through various kinds of digital licenses, as well as providing client-side protection of those licenses. Next a server product, the Software Licensing and Protection Server, in standard and enterprise editions. These allow the ISV to host their own servers, create licenses for their products and offer them in very flexible scenarios, either directly or through partners. SLP Services enables simple creation of machine-based licenses, time-based licenses for subscription models and trials, user-based licenses for roaming, as well as feature-based licenses ? supporting a wide range of business models. The third major feature is the SLP Online Service. This option allows partners to do all of their license management without hosting their own servers. We have three different levels of service available on a yearly subscription basis. Starting in October, all MSDN Premium subscription members will get a free subscription to the SLP Online Service Basic edition. -- Marty Connelly Victoria, B.C. Canada From accessd666 at yahoo.com Tue Jul 17 01:51:50 2007 From: accessd666 at yahoo.com (Sad Der) Date: Mon, 16 Jul 2007 23:51:50 -0700 (PDT) Subject: [AccessD] Conditional Compilation ADP 2002? Message-ID: <672443.1350.qm@web31615.mail.mud.yahoo.com> Hi, I want to use conditional compilation in a project. If i'm debugging the code some parts are not allowed to run. But it doesn't seem to work... I created a Mod with a public var: Public gbooConditionalCompilation As Boolean In my form I have the following code: #If gbooConditionalCompilation Then MsgBox "We are debugging this sht" #End If before I come to this point I set (in immediate window) the global boolean to true: gbooConditionalCompilation = True I think i'm making a massive error somewhere...any thoughts? Thnx ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From jwcolby at colbyconsulting.com Tue Jul 17 07:44:33 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 17 Jul 2007 08:44:33 -0400 Subject: [AccessD] Conditional Compilation ADP 2002? In-Reply-To: <672443.1350.qm@web31615.mail.mud.yahoo.com> Message-ID: <20070717124436.2D4A9BCEC@smtp-auth.no-ip.com> Global conditional compilation only works if the conditional constant is at the database level. Any conditional constants defined in a module are only valid for that module. To set a global constant: 1) Open any database 2) Open any module 3) Tools / MyDatabaseName Properties 4) Set the conditional compilation arguments text box there Conditional compilation arguments are NOT regular constants or variables. They have to be declared with a #const keyword: #const gbooConditionalCompilation = True Even then, this is only valid in the module in which it is declared. The only way to get a GLOBAL variable is the process discussed above. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der Sent: Tuesday, July 17, 2007 2:52 AM To: Acces User Group Subject: [AccessD] Conditional Compilation ADP 2002? Hi, I want to use conditional compilation in a project. If i'm debugging the code some parts are not allowed to run. But it doesn't seem to work... I created a Mod with a public var: Public gbooConditionalCompilation As Boolean In my form I have the following code: #If gbooConditionalCompilation Then MsgBox "We are debugging this sht" #End If before I come to this point I set (in immediate window) the global boolean to true: gbooConditionalCompilation = True I think i'm making a massive error somewhere...any thoughts? Thnx ____________________________________________________________________________ ________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bgoss711 at ameritech.net Tue Jul 17 08:23:49 2007 From: bgoss711 at ameritech.net (Bud Goss) Date: Tue, 17 Jul 2007 06:23:49 -0700 (PDT) Subject: [AccessD] Set Warnings Problem - Environment Access 2003 Message-ID: <715394.76976.qm@web81301.mail.mud.yahoo.com> Set Warnings problem - Environment Access 2003 A problem has recently developed on one of my PCs I can not get any warning messages to display when running delete, update, append or Make-table queries. I use docmd.setwarnings = true - Immediately followed by execution of the query The query runs and does the update etc., but there are no warning messages. The same problem (No Warning Message) occurs when I run the query by just double clicking on it This problem occurs on all Access 2003 databases run on this machine. If I use a different machine with the same query with the same database I get the warning messages. Access 2003 has been re-installed on this PC but the problem continues to occur. But the problem does not occur on Access97 databases. Is there some environment setting that I inadvertently changed? If so, what is it? Any advice would be appreciated. From ssharkins at setel.com Tue Jul 17 11:19:32 2007 From: ssharkins at setel.com (Susan Harkins) Date: Tue, 17 Jul 2007 12:19:32 -0400 Subject: [AccessD] Set Warnings Problem - Environment Access 2003 In-Reply-To: <715394.76976.qm@web81301.mail.mud.yahoo.com> References: <715394.76976.qm@web81301.mail.mud.yahoo.com> Message-ID: <002a01c7c88e$4a80ba50$61b82ad1@SusanOne> Check the Edit/Find tab in Options -- perhaps someone unchecked the manual settings. Susan H. Set Warnings problem - Environment Access 2003 A problem has recently developed on one of my PCs I can not get any warning messages to display when running delete, update, append or Make-table queries. I use docmd.setwarnings = true - Immediately followed by execution of the query The query runs and does the update etc., but there are no warning messages. The same problem (No Warning Message) occurs when I run the query by just double clicking on it This problem occurs on all Access 2003 databases run on this machine. If I use a different machine with the same query with the same database I get the warning messages. Access 2003 has been re-installed on this PC but the problem continues to occur. But the problem does not occur on Access97 databases. Is there some environment setting that I inadvertently changed? If so, what is it? Any advice would be appreciated. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 2007/07/15 02:21 PM From bgoss711 at ameritech.net Tue Jul 17 13:19:37 2007 From: bgoss711 at ameritech.net (Bud Goss) Date: Tue, 17 Jul 2007 11:19:37 -0700 (PDT) Subject: [AccessD] Set Warnings problem - Environment Access 2003 - Solved Thank you Message-ID: <660053.99904.qm@web81313.mail.mud.yahoo.com> Yes that was it - The Action Queries confirm box was unchecked Thank You, Thank You, Thank you Check the Edit/Find tab in Options -- perhaps someone unchecked the manual settings. Susan H. >>>Set Warnings problem - Environment Access 2003 A problem has recently developed on one of my PCs I can not get any warning messages to display when running delete, update, append or Make-table queries. I use docmd.setwarnings = true - Immediately followed by execution of the query The query runs and does the update etc., but there are no warning messages. The same problem (No Warning Message) occurs when I run the query by just double clicking on it This problem occurs on all Access 2003 databases run on this machine. If I use a different machine with the same query with the same database I get the warning messages. Access 2003 has been re-installed on this PC but the problem continues to occur. But the problem does not occur on Access97 databases. Is there some environment setting that I inadvertently changed? If so,what is it? Any advice would be appreciated. From markamatte at hotmail.com Tue Jul 17 14:48:40 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 17 Jul 2007 19:48:40 +0000 Subject: [AccessD] Require password for linked MDB tables In-Reply-To: <660053.99904.qm@web81313.mail.mud.yahoo.com> Message-ID: Hello All, Can I have an MDB linked to a seperate MDB(with password)...and have the user required to enter just a password to view the linked table each time? And is it different in different versions? Thanks, Mark A. Matte >From: Bud Goss >Reply-To: Access Developers discussion and problem >solving >To: accessd at databaseadvisors.com >Subject: [AccessD] Set Warnings problem - Environment Access 2003 - >SolvedThank you >Date: Tue, 17 Jul 2007 11:19:37 -0700 (PDT) > > > > > >Yes that was it - The Action Queries confirm box was unchecked > >Thank You, Thank You, Thank you > > >Check the Edit/Find tab in Options -- perhaps someone unchecked the manual >settings. > >Susan H. > > >>>Set Warnings problem - Environment Access 2003 > > A problem has recently developed on one of my PCs > > I can not get any warning messages to display when running delete, > > update, append or Make-table queries. > > I use docmd.setwarnings = true - Immediately followed by execution of > > the query > > The query runs and does the update etc., but there are no warning >messages. > > The same problem (No Warning Message) occurs when I run the query by >just > >double clicking on it > > This problem occurs on all Access 2003 databases run on this machine. > > If I use a different machine with the same query with the same database I > > get the warning messages. Access 2003 has been re-installed on this PC >but the > >problem continues to occur. > > But the problem does not occur on Access97 databases. > > Is there some environment setting that I inadvertently changed? If > > so,what is it? > > Any advice would be appreciated. > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 From pcs at azizaz.com Tue Jul 17 17:03:10 2007 From: pcs at azizaz.com (Borge Hansen) Date: Wed, 18 Jul 2007 08:03:10 +1000 Subject: [AccessD] Lock of Record - Memofields References: Message-ID: <025301c7c8be$446d1750$fa10a8c0@Albatross> Gustav, Never knew that doing a me.dirty = false actually saves the record on the Form I mentioned in my first email that I would save the record on the form with a docmd.save. What I meant was : docmd.runcommand accmdsaverecord Is a me.dirty = false preferable to a docmd.runcommand accmdsaverecord ? regards borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Tuesday, July 17, 2007 12:17 AM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge It tells the form to save the record using the method of the form for this purpose. More precisely, it should look: If Me.Dirty = True Then ' The record has been edited. ' Save the record. Me.Dirty = False End If I'm not saying this is the magic cure. However, DoCmd operations may not always work as expected under stress, and it may be a stress situation when you - at the same time - wish to save a record and move to the next. /gustav >>> pcs at azizaz.com 16-07-2007 15:35 >>> Hi Gustav, I don't get it .... please explain what the me.dirty = false can do in this context. ... also, I admit I didn't get David's method either... borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Monday, July 16, 2007 7:41 PM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.1/778 - Release Date: 4/27/2007 1:39 PM From Gustav at cactus.dk Wed Jul 18 03:16:52 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Wed, 18 Jul 2007 10:16:52 +0200 Subject: [AccessD] Lock of Record - Memofields Message-ID: Hi Borge Yes, setting Me.Dirty is preferable. It tells the form to save the current record, while DoCmd.RunCommand tells the application to tell the active form to save its current record. /gustav >>> pcs at azizaz.com 18-07-2007 00:03 >>> Gustav, Never knew that doing a me.dirty = false actually saves the record on the Form I mentioned in my first email that I would save the record on the form with a docmd.save. What I meant was : docmd.runcommand accmdsaverecord Is a me.dirty = false preferable to a docmd.runcommand accmdsaverecord ? regards borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Tuesday, July 17, 2007 12:17 AM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge It tells the form to save the record using the method of the form for this purpose. More precisely, it should look: If Me.Dirty = True Then ' The record has been edited. ' Save the record. Me.Dirty = False End If I'm not saying this is the magic cure. However, DoCmd operations may not always work as expected under stress, and it may be a stress situation when you - at the same time - wish to save a record and move to the next. /gustav >>> pcs at azizaz.com 16-07-2007 15:35 >>> Hi Gustav, I don't get it .... please explain what the me.dirty = false can do in this context. ... also, I admit I didn't get David's method either... borge ----- Original Message ----- From: "Gustav Brock" To: Sent: Monday, July 16, 2007 7:41 PM Subject: Re: [AccessD] Lock of Record - Memofields Hi Borge Perhaps you should avoid the indirect DoCmd.Save in favour of the method of the form itself: Me.Dirty = False Also, as David mentions, and as your memos seem so tightly formatted that they should be put in a subtable, you could either do this - or use the method of David. /gustav >>> pcs at azizaz.com 16-07-2007 04:06 >>> Hi, I have a problem with record locking and would like some comments on this. This might be a bit of a long winded explanation so bear with me.... From paul.hartland at fsmail.net Wed Jul 18 06:09:37 2007 From: paul.hartland at fsmail.net (paul.hartland at fsmail.net) Date: Wed, 18 Jul 2007 13:09:37 +0200 (CEST) Subject: [AccessD] Access/VB using Infragistics Ultragrid Message-ID: <11606970.1029431184756977786.JavaMail.www@wwinf3107> To all, Anyone used the Infragistics Ultragrid control using valuelists in Access or VB and how t limit to the list ? Thanks in advance for any help on this Paul Hartland paul.hartland at fsmail.net 07730 523179 From jwcolby at colbyconsulting.com Wed Jul 18 09:23:32 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 10:23:32 -0400 Subject: [AccessD] DSNs Message-ID: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com From ssharkins at setel.com Wed Jul 18 10:10:01 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 11:10:01 -0400 Subject: [AccessD] Access 2007 question about maximized forms Message-ID: <000d01c7c94d$b967a270$d432fad1@SusanOne> Maximized forms open behind the Navigation Pane -- that means part of the form is blocked. I think it would be neat to work with the pane open, without blocking the maximized form -- forcing Access to adjust the maximized "size" if the pane is open -- is that possible? Susan H. From jimdettman at verizon.net Wed Jul 18 11:41:49 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 18 Jul 2007 12:41:49 -0400 Subject: [AccessD] DSNs In-Reply-To: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> References: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> Message-ID: <003301c7c95a$8a935720$8abea8c0@XPS> John, 1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. 2. Redefine a single DSN. 3. Provide all the connection information in the .Connect property and go DSN less. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bhjohnson at verizon.net Wed Jul 18 11:47:35 2007 From: bhjohnson at verizon.net (Bruce H. Johnson) Date: Wed, 18 Jul 2007 09:47:35 -0700 Subject: [AccessD] DSNs In-Reply-To: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> References: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> Message-ID: <007501c7c95b$584df760$0201a8c0@HALSR> Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 7:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM From jwcolby at colbyconsulting.com Wed Jul 18 11:49:52 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 12:49:52 -0400 Subject: [AccessD] DSNs In-Reply-To: <003301c7c95a$8a935720$8abea8c0@XPS> Message-ID: <20070718164954.BDE89BD7D@smtp-auth.no-ip.com> >1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. I build a new database for each order, thus the reason for editing the DSN >2. Redefine a single DSN. In a text editor I assume? >3. Provide all the connection information in the .Connect property and go DSN less. I didn't state it, but these are for linking tables out of the SQL Server database. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 18, 2007 12:42 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs John, 1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. 2. Redefine a single DSN. 3. Provide all the connection information in the .Connect property and go DSN less. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.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 jwcolby at colbyconsulting.com Wed Jul 18 12:00:38 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 13:00:38 -0400 Subject: [AccessD] DSNs In-Reply-To: <007501c7c95b$584df760$0201a8c0@HALSR> Message-ID: <20070718170040.C599FBEA7@smtp-auth.no-ip.com> >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 7:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 18 12:06:38 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 18 Jul 2007 10:06:38 -0700 Subject: [AccessD] DSNs In-Reply-To: <20070718170040.C599FBEA7@smtp-auth.no-ip.com> References: <007501c7c95b$584df760$0201a8c0@HALSR> <20070718170040.C599FBEA7@smtp-auth.no-ip.com> Message-ID: The path on XP is >Control Panel > Administrative Tools > Data Sources (ODBC) Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 7:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM -- 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 jwcolby at colbyconsulting.com Wed Jul 18 12:14:45 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 13:14:45 -0400 Subject: [AccessD] DSNs In-Reply-To: Message-ID: <20070718171447.8CD17BDE7@smtp-auth.no-ip.com> That was it. And it comes with a little wizard for manually editing the file. Cool. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 18, 2007 1:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] DSNs The path on XP is >Control Panel > Administrative Tools > Data Sources (ODBC) Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH From Lambert.Heenan at AIG.com Wed Jul 18 12:22:20 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Wed, 18 Jul 2007 12:22:20 -0500 Subject: [AccessD] DSNs Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6C5E@xlivmbx35.aig.com> FYI. If your download and install the XP version of TweakUI you'll find a node for 'Control Panel'. There you can check a box and have Data Sources (ODBC) show up in the first control panel window instead of having to open the admin screen too. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 1:15 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs That was it. And it comes with a little wizard for manually editing the file. Cool. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 18, 2007 1:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] DSNs The path on XP is >Control Panel > Administrative Tools > Data Sources (ODBC) Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Wed Jul 18 12:27:13 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 18 Jul 2007 13:27:13 -0400 Subject: [AccessD] DSNs In-Reply-To: <20070718164954.BDE89BD7D@smtp-auth.no-ip.com> References: <003301c7c95a$8a935720$8abea8c0@XPS> <20070718164954.BDE89BD7D@smtp-auth.no-ip.com> Message-ID: <000d01c7c960$e2076f90$8abea8c0@XPS> <> Well scratch that one then. <> No, with code. I've pasted in the VB6 code I use below. Will work fine in Access. This code uses a table however to get the DSN specifics. You'd need to modify it a bit to pull in the database name. However, from what you've said, I would go DSN less. <> Basically a DSN is nothing more then a holding place for connection info. You can supply that info right in the .Connect property and skip the DSN. See this MSDN article: http://msdn2.microsoft.com/en-us/library/bb188204.aspx and look for "Setting Connection Properties" There are loads of examples of doing this on the web. A good site for getting connection strings is: http://www.connectionstrings.com/ Jim. ============================================================================ == Option Explicit ' Require variables to be declared before being used. Private Const ODBC_ADD_SYS_DSN = 4 'Add data source Private Const ODBC_CONFIG_SYS_DSN = 5 'Configure (edit) data source Private Const ODBC_REMOVE_SYS_DSN = 6 'Remove data source Private Const vbAPINull = 0& Private Declare Function SQLConfigDataSource Lib "ODBCCP32.DLL" (ByVal _ hwndParent As Long, ByVal fRequest As Long, ByVal _ lpszDriver As String, ByVal lpszAttributes As String) As Long Function CreateDSNs(strDatabaseName As String) As Integer ' Using tblDSNs, Create/refresh required DSN entires for a database. Dim ws As DAO.Workspace Dim db As DAO.Database Dim rs As DAO.Recordset Dim strDriver As String Dim strAttributes As String Dim strDatabase As String Dim strDSN As String Dim intEntryCount As Integer Dim intNumberofDSNs As Integer Dim varRet As Variant 'Dim pb As New Form_frm_ProgBar On Error goto CreateDSNs_Err Set ws = DBEngine.CreateWorkspace("", "Admin", "") Set db = ws.OpenDatabase("P:\xxx\SetClientEnv\SetClientEnv.MDB") Set rs = db.OpenRecordset("tblDSNs") intNumberofDSNs = rs.RecordCount intEntryCount = 0 'pb.SetMessage "Creating/refreshing DSN Entries" With rs While Not .EOF ' Check if this entry applies to this database. If UCase(rs("DatabaseName")) = UCase(strDatabaseName) Then ' Register method can't create system DSNs ' only user ones. 'DBEngine.RegisterDatabase rs("DSN"), _ ' "SQL Server", _ ' True, _ ' "Description= Traverse - " & strDatabase & _ ' Chr(13) & "Server=" & rs("Server") & _ ' Chr(13) & "Database=" & strDatabase & _ ' Chr(13) & "Network=DBMSSOCN" & _ ' Chr(13) & "Trusted_Connection=Yes" strDriver = "SQL Server" & Chr(0) strAttributes = "DSN=" & rs("DSN") & Chr(0) strAttributes = strAttributes & "Description= Traverse - " & rs("Database") & Chr(0) strAttributes = strAttributes & "Server=" & rs("Server") & Chr(0) strAttributes = strAttributes & "Database=" & rs("Database") & Chr(0) strAttributes = strAttributes & "Network=DBMSSOCN" & Chr(0) strAttributes = strAttributes & "Trusted_Connection=Yes" & Chr(0) varRet = SQLConfigDataSource(vbAPINull, ODBC_ADD_SYS_DSN, strDriver, strAttributes) If varRet <> 1 Then MsgBox "DSN Creation Failed" GoTo CreateDSNs_Err End If End If intEntryCount = intEntryCount + 1 'pb.SetBarPercent (intEntryCount / intNumberofDSNs) * 100 rs.MoveNext Wend End With CreateDSNs = True CreateDSNs_End: On Error Resume Next If Not rs Is Nothing Then rs.Close Set rs = Nothing End If If Not db Is Nothing Then db.Close Set db = Nothing End If If Not ws Is Nothing Then ws.Close Set ws = Nothing End If Exit Function CreateDSNs_Err: CreateDSNs = False GoTo CreateDSNs_End End Function -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 12:50 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. I build a new database for each order, thus the reason for editing the DSN >2. Redefine a single DSN. In a text editor I assume? >3. Provide all the connection information in the .Connect property and go DSN less. I didn't state it, but these are for linking tables out of the SQL Server database. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 18, 2007 12:42 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs John, 1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. 2. Redefine a single DSN. 3. Provide all the connection information in the .Connect property and go DSN less. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.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 adtp at hotmail.com Wed Jul 18 12:28:30 2007 From: adtp at hotmail.com (A.D.TEJPAL) Date: Wed, 18 Jul 2007 22:58:30 +0530 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) References: <001e01c7bb6b$88d195c0$6701a8c0@ACER2G> Message-ID: Joe, My sample db named NotesHierarchical has just been uploaded to Rogers Access Library (other developers library). Link - http://www.rogersaccesslibrary.com/OtherLibraries.asp#Tejpal,A.D. Apart from meeting the requirements outlined by you, it incorporates certain other desirable features. Brief description is given below. Best wishes, A.D.Tejpal --------------- NotesHierarchical (Sample Db) Brief Description ==================================== This sample db demonstrates handling of performance notes in an organization. Persons in administrative position are assigned various levels. For example the top boss has level 1. Managers next in command, each have level 2. Supervisors next in command, each have level 3. General employees do not have any level assigned to them. Though three level administrative set up is shown in the db, it can be adapted to any number of levels, simply by assigning levels 4, 5 & so on. In order to identify clear chain of command, the immediate boss for each employee is identified via BossID. For top boss, BossID field is blank. Performance notes for a given employee as selected, can be recorded at various levels by his superiors in direct chain of command. A person in senior position can not alter the notes recorded by those below him (but can view the same). The row source for combo box meant for selecting employee is set dynamically in such a manner that it is confined only to those in direct chain of command under the selected noter. This involves recursive reference to BossID field in employees table, implemented via user defined function. Any person in administrative position, wishing to record a note, has to log in using a password. On successful log in, the noter has full read/write access to his own notes for the selected employee. At the same time, all the notes for this employee, as recorded by other noters (only those in the chain of command below the current noter) get displayed, but in read-only state. The notes table, has a Yes/No field named Sent. When Sent is set to true, the note in question can no longer be edited, even by the person who recorded it originally. More-over, once set to True, it can no longer be re-set to False and no back dated note can be created. For example, if note dated 31-Dec-2006 for a given combination of employee and noter has been marked sent, and we are now in year 2007, any new note with date prior to 31-Dec-2006 can not be created this noter for the given employee. Version: Access 2000 File Format Reference: DAO 3.6 ==================================== ----- Original Message ----- From: Joe Hecht To: 'Access Developers discussion and problem solving' Sent: Sunday, July 01, 2007 04:38 Subject: [AccessD] Never Take a job for a friend (Three level designquestion) It is simple. Ya Right I am righting a poor mans HR program. There are four user levels. Dispatchers can not do notes, can not see notes. Field supervisor can write notes. Can not see manager or executive notes. Managers can write notes, can read Field supervisor notes, not edit them or see executive notes. Executives can write theirs, see but not edit all other notes. Notes are many notes to one employee. How do I do notes so people see them in chronological order? If I do three sub tables how would I get all notes to same point. One employee can have multiple incidents good and bad in their record. How would I get all three levels of notes to same incident? Ya all know where I am spending my sat night. Joe Hecht jmhecht at earthlink.net From jwcolby at colbyconsulting.com Wed Jul 18 12:35:56 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 13:35:56 -0400 Subject: [AccessD] DSNs In-Reply-To: <000d01c7c960$e2076f90$8abea8c0@XPS> Message-ID: <20070718173558.3FEDFBED7@smtp-auth.no-ip.com> Hmm... John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 18, 2007 1:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs <> Well scratch that one then. <> No, with code. I've pasted in the VB6 code I use below. Will work fine in Access. This code uses a table however to get the DSN specifics. You'd need to modify it a bit to pull in the database name. However, from what you've said, I would go DSN less. <> Basically a DSN is nothing more then a holding place for connection info. You can supply that info right in the .Connect property and skip the DSN. See this MSDN article: http://msdn2.microsoft.com/en-us/library/bb188204.aspx and look for "Setting Connection Properties" There are loads of examples of doing this on the web. A good site for getting connection strings is: http://www.connectionstrings.com/ Jim. ============================================================================ == Option Explicit ' Require variables to be declared before being used. Private Const ODBC_ADD_SYS_DSN = 4 'Add data source Private Const ODBC_CONFIG_SYS_DSN = 5 'Configure (edit) data source Private Const ODBC_REMOVE_SYS_DSN = 6 'Remove data source Private Const vbAPINull = 0& Private Declare Function SQLConfigDataSource Lib "ODBCCP32.DLL" (ByVal _ hwndParent As Long, ByVal fRequest As Long, ByVal _ lpszDriver As String, ByVal lpszAttributes As String) As Long Function CreateDSNs(strDatabaseName As String) As Integer ' Using tblDSNs, Create/refresh required DSN entires for a database. Dim ws As DAO.Workspace Dim db As DAO.Database Dim rs As DAO.Recordset Dim strDriver As String Dim strAttributes As String Dim strDatabase As String Dim strDSN As String Dim intEntryCount As Integer Dim intNumberofDSNs As Integer Dim varRet As Variant 'Dim pb As New Form_frm_ProgBar On Error goto CreateDSNs_Err Set ws = DBEngine.CreateWorkspace("", "Admin", "") Set db = ws.OpenDatabase("P:\xxx\SetClientEnv\SetClientEnv.MDB") Set rs = db.OpenRecordset("tblDSNs") intNumberofDSNs = rs.RecordCount intEntryCount = 0 'pb.SetMessage "Creating/refreshing DSN Entries" With rs While Not .EOF ' Check if this entry applies to this database. If UCase(rs("DatabaseName")) = UCase(strDatabaseName) Then ' Register method can't create system DSNs ' only user ones. 'DBEngine.RegisterDatabase rs("DSN"), _ ' "SQL Server", _ ' True, _ ' "Description= Traverse - " & strDatabase & _ ' Chr(13) & "Server=" & rs("Server") & _ ' Chr(13) & "Database=" & strDatabase & _ ' Chr(13) & "Network=DBMSSOCN" & _ ' Chr(13) & "Trusted_Connection=Yes" strDriver = "SQL Server" & Chr(0) strAttributes = "DSN=" & rs("DSN") & Chr(0) strAttributes = strAttributes & "Description= Traverse - " & rs("Database") & Chr(0) strAttributes = strAttributes & "Server=" & rs("Server") & Chr(0) strAttributes = strAttributes & "Database=" & rs("Database") & Chr(0) strAttributes = strAttributes & "Network=DBMSSOCN" & Chr(0) strAttributes = strAttributes & "Trusted_Connection=Yes" & Chr(0) varRet = SQLConfigDataSource(vbAPINull, ODBC_ADD_SYS_DSN, strDriver, strAttributes) If varRet <> 1 Then MsgBox "DSN Creation Failed" GoTo CreateDSNs_Err End If End If intEntryCount = intEntryCount + 1 'pb.SetBarPercent (intEntryCount / intNumberofDSNs) * 100 rs.MoveNext Wend End With CreateDSNs = True CreateDSNs_End: On Error Resume Next If Not rs Is Nothing Then rs.Close Set rs = Nothing End If If Not db Is Nothing Then db.Close Set db = Nothing End If If Not ws Is Nothing Then ws.Close Set ws = Nothing End If Exit Function CreateDSNs_Err: CreateDSNs = False GoTo CreateDSNs_End End Function -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 12:50 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >1. Have multiple DSN's defined and switch the .Connect property to >point to the correct one. I build a new database for each order, thus the reason for editing the DSN >2. Redefine a single DSN. In a text editor I assume? >3. Provide all the connection information in the .Connect property and >go DSN less. I didn't state it, but these are for linking tables out of the SQL Server database. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 18, 2007 12:42 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs John, 1. Have multiple DSN's defined and switch the .Connect property to point to the correct one. 2. Redefine a single DSN. 3. Provide all the connection information in the .Connect property and go DSN less. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:24 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] DSNs I am working with Access as the FE to processing orders where I need to export to a fixed width file because Access stores the format, which is convenient until I come up to speed on how to do something similar in SQL Server. The issue is that the DSN is specific to a database name. How can I edit that to point to a different database? John W. Colby Colby Consulting www.ColbyConsulting.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 kathryn at bassett.net Wed Jul 18 13:13:43 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Wed, 18 Jul 2007 11:13:43 -0700 Subject: [AccessD] Many to Many problem part 1 - the background Message-ID: <005c01c7c967$60fd3590$6401a8c0@Kathryn> I've been working on something on Webweavers (Dreamweaver group). But my design problem actualy has more to do with understanding how to imput something into MySql database. If I could understand it in Access, then I will be able to figure it out in MySql. With that in mind, an explanation of what will be in the database is needed. In Webweavers, one of the gals didn't understand the collections the database is based on. I'll start with Win's last question first: > You talked about a library of collections, but what I see here looks > like a genealogy of sorts. To me a library means collections of > literary works - is that not the case here? No, that's not the case. Have you ever heard of a libray that has "vertical files"? I'll give you an example. A number of years ago, I went to the library in Lake county Ohio. In the genealogy and history section of the library they had a file cabinet of uncataloged papers. In this particular case, there were file folders with surnames on it. A misc jumble of papers would end up in the file folders. In the case I'm thinking of, there was a folder named Harmon. In it were just two papers, one was a letter from someone inquiring about a Harmon family. The other was a copy of a genealogy society newsletter with an article on a man named Harmon. This is unindexed material, not in any catalogs. If I hadn't gone there in person and looked in the files, I would not have made the discovery that was important to me (if you are curious, http://bassett.net/secondsite/kathryn-p/p202.shtml#i10064 and scroll down til you see Story). Another, larger example is Gwen, the lady I work for. She has the equivalent of about 30 "bankers boxes" full of materials from her 30+ years of research. There are many "collections" like this - they are not published books or other literary works. People like Caroline Ackley, David Gardner, Walter Hilbig etc have turned over their un-indexed collections to my friend Arlene. She has been going through the collections and been making indexes of the names in the collections. In metaphoric terms, she has a notebook labeled Caroline Ackley, and as she was going through that collection and sorting it into a way she could find things in the future, she wrote down names she encountered. In some cases, she also made a note about the name - like my hypothetical memo for John Doe in the AckleyCaroline collection (see below). There are many genealogists that will be interested in knowing that "Win Day" is mentioned in an otherwise unindexed group of papers that Alene now has, and they are willing to pay to get copies of those papers - or they will plan to visit her library in person to look at them. Her library is not a normal library, it's an archive of research collections. Hopefully, this fuller description will help you all understand. > When I design a database, I don't start with the database, or thinking > about the web-based forms. I start by writing descriptions of the > information I want to display and how the bits relate to each other. After someone does a search by filling in last name and probably also the first name (though they may only search last name), then this is a sample of what I want to display. ========= Someone by the name of Win Day(1) can be found in the following collections: AckleyCaroline(2) - son of Fred, circa 1800; son of Thomas, circa 1600; and another married to Jane Smith(3) GardnerDavid(2) - married to Jane Smith(3) HilbigWalter(2) SmithJeremiah(2) For a flat fee of $n you can get a copy of 1-nn pages. If there are more than nn pages involved, you will be notified of the charge and your payment can either be applied or refunded if you choose not to purchase. ========= (1) pulled in from tblCScollections (2) pulled in from tblCSnames (3) pulled in from tblCSmemos So, that is the information I want to display. Part two will describe where I'm stuck. -- Kathryn Rhinehart Bassett (Pasadena CA) "Genealogy is my bag" "GH is my soap" kathryn at bassett.net http://bassett.net No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 17 Jul 07 6:30 pm From kathryn at bassett.net Wed Jul 18 13:13:53 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Wed, 18 Jul 2007 11:13:53 -0700 Subject: [AccessD] Many to Many problem part 2 - the tables and question Message-ID: <006001c7c967$6661ac00$6401a8c0@Kathryn> Read part 1 first so you understand what the database is about. I have these three tables. tblCScollections tblCScollectionID int(7) tblCScollectionName varchar(50) populated with the 11 collections we have at present. 1 AckleyCarolyn 2 DunnPhillip 3 GardnerDavid 4 HilbigWalter 5 HollingsworthHarry 6 PriceRichard 7 SmithJeremiah 8 MillsVirginia 9 MooreWilburta 10 MottAnita 11 SmithConley tblCSnames tblCSnamesID int(7) tblCSlastname varchar(50) tblCSfirstname varchar(50) populated with 1 Van Horn G. Armour 2 Bassett Kathryn 3 Day Win 4 Sullivan Stephanie 5 Gentry Doug 6 Lohmar Michael tblCSmemos tblCScollectionID tblCSnamesID tblCSmemo not populated at all at present Bottom line is that I now understand the two+middle table concept. The inputting of data into the database is where I'm having a problem. The flat way I *had* been thinking (using spreadsheet analogy) is that column A/B is lastname/firstname, column B is collectionID1, column C is the memo for collectionID1 and the rest of the columns are like columcs C/D for each collection. I put "true" in each collection ID column that the name in row 2 (or 3 or 4) appears in. Now if Win Day (nameID=3) was ONLY in one collection, then a dropdown box of the collection names would work. But since nameID=3 is in multiple collections and may or may not have a memo, I'm not clear on how to do the input. Help? -- Kathryn Rhinehart Bassett (Pasadena CA) "Genealogy is my bag" "GH is my soap" kathryn at bassett.net http://bassett.net No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 17 Jul 07 6:30 pm From ssharkins at setel.com Wed Jul 18 13:36:31 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 14:36:31 -0400 Subject: [AccessD] Function to grab decimal value? Message-ID: <000a01c7c96a$90721360$a2b82ad1@SusanOne> Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. From ssharkins at setel.com Wed Jul 18 13:48:52 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 14:48:52 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <000a01c7c96a$90721360$a2b82ad1@SusanOne> References: <000a01c7c96a$90721360$a2b82ad1@SusanOne> Message-ID: <000c01c7c96c$4a3a63a0$a2b82ad1@SusanOne> Oh for pete's sakes, duh... Nevermind... Susan H. Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? From jimdettman at verizon.net Wed Jul 18 13:49:05 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 18 Jul 2007 14:49:05 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <000a01c7c96a$90721360$a2b82ad1@SusanOne> References: <000a01c7c96a$90721360$a2b82ad1@SusanOne> Message-ID: <004301c7c96c$51a1d600$8abea8c0@XPS> Susan, MOD comes close but is not quite what you want. Instead, use: =-Int() Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 2:37 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Function to grab decimal value? Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Wed Jul 18 13:50:28 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Wed, 18 Jul 2007 20:50:28 +0200 Subject: [AccessD] Function to grab decimal value? Message-ID: Hi Susan No, you'll have to run your own: f = d - Fix(d) /gustav >>> ssharkins at setel.com 18-07-2007 20:36 >>> Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. From jwcolby at colbyconsulting.com Wed Jul 18 13:51:31 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 14:51:31 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <000a01c7c96a$90721360$a2b82ad1@SusanOne> Message-ID: <20070718185134.759F2BE94@smtp-auth.no-ip.com> First of all, Int will only work for a value up to 32 (or 64) K. Aside from that, something like NewVal = MyVal-int(MyVal). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 2:37 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Function to grab decimal value? Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Gustav at cactus.dk Wed Jul 18 14:01:12 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Wed, 18 Jul 2007 21:01:12 +0200 Subject: [AccessD] Function to grab decimal value? Message-ID: Hi John Don't you have CInt() in mind? Int() and Fix() accept very large numbers. Further, here Fix must be used in case of a negative decimal number. /gustav >>> jwcolby at colbyconsulting.com 18-07-2007 20:51 >>> First of all, Int will only work for a value up to 32 (or 64) K. Aside from that, something like NewVal = MyVal-int(MyVal). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 2:37 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Function to grab decimal value? Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. From jwcolby at colbyconsulting.com Wed Jul 18 14:06:29 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 15:06:29 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: Message-ID: <20070718190631.6E8BEBD3C@smtp-auth.no-ip.com> Yep, and I keep forgetting Fix() Just keep reminding me and SOMEDAY.... I might remember that one! ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Wednesday, July 18, 2007 3:01 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Function to grab decimal value? Hi John Don't you have CInt() in mind? Int() and Fix() accept very large numbers. Further, here Fix must be used in case of a negative decimal number. /gustav >>> jwcolby at colbyconsulting.com 18-07-2007 20:51 >>> First of all, Int will only work for a value up to 32 (or 64) K. Aside from that, something like NewVal = MyVal-int(MyVal). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 2:37 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Function to grab decimal value? Int returns just the integer portion of a value -- is there a counterpart that grabs jus the decimal value? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From martyconnelly at shaw.ca Wed Jul 18 14:15:37 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Wed, 18 Jul 2007 12:15:37 -0700 Subject: [AccessD] DSNs In-Reply-To: <20070718171447.8CD17BDE7@smtp-auth.no-ip.com> References: <20070718171447.8CD17BDE7@smtp-auth.no-ip.com> Message-ID: <469E66D9.6050408@shaw.ca> I believe you can bring up that wizard from VBA code but it has been 5 years since I last looked. Saw it done via VB6. jwcolby wrote: >That was it. And it comes with a little wizard for manually editing the >file. Cool. > > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust >Sent: Wednesday, July 18, 2007 1:07 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] DSNs > >The path on XP is >Control Panel > Administrative Tools > Data Sources >(ODBC) > >Charlotte > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby >Sent: Wednesday, July 18, 2007 10:01 AM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] DSNs > > > >>Hopefully I'm not being condescending. >> >> > >Not at all. I don't know this stuff > > > >>Control Panel > Data Sources (ODBC) >> >> > >I don't have that. Windows XP Profession SP2 > > > >>HKLM\Software\ODBC\ODBC.INI >> >> > >I don't understand this one. Is this a directory path? A registry key? > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. >Johnson >Sent: Wednesday, July 18, 2007 12:48 PM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] DSNs > >Hopefully I'm not being condescending. > >If this is for your machine only: > >Control Panel > Data Sources (ODBC) > >If you need it programmable: >HKLM\Software\ODBC\ODBC.INI > >HTH > > > -- Marty Connelly Victoria, B.C. Canada From ssharkins at setel.com Wed Jul 18 14:45:01 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 15:45:01 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: References: Message-ID: <001301c7c974$223e5c50$a2b82ad1@SusanOne> No negative values, but thanks guys -- as soon as it hit me, I felt like a true moron. Susan H. Hi John Don't you have CInt() in mind? Int() and Fix() accept very large numbers. Further, here Fix must be used in case of a negative decimal number. From jwcolby at colbyconsulting.com Wed Jul 18 14:52:09 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 15:52:09 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <001301c7c974$223e5c50$a2b82ad1@SusanOne> Message-ID: <20070718195211.E5757BEDF@smtp-auth.no-ip.com> LOL. That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 3:45 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? No negative values, but thanks guys -- as soon as it hit me, I felt like a true moron. Susan H. Hi John Don't you have CInt() in mind? Int() and Fix() accept very large numbers. Further, here Fix must be used in case of a negative decimal number. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Jim.Hale at FleetPride.com Wed Jul 18 15:35:26 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Wed, 18 Jul 2007 15:35:26 -0500 Subject: [AccessD] DSNs In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6C5E@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6C5E@xlivmbx35.aig.com> Message-ID: Here is a discussion I've found useful in the past for creating dsn-less connections http://www-1.ibm.com/support/docview.wss?rs=0&q1=dsn-less&uid=nas1c52dfe 451b37518086256931005499ff&loc=en_US&cs=utf-8&cc=us&lang=en Here is one I've found that helps with propgramming DSNs: How To Create and Remove a DSN in Visual Basic http://support.microsoft.com/kb/q171146/ Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Wednesday, July 18, 2007 12:22 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs FYI. If your download and install the XP version of TweakUI you'll find a node for 'Control Panel'. There you can check a box and have Data Sources (ODBC) show up in the first control panel window instead of having to open the admin screen too. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 1:15 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs That was it. And it comes with a little wizard for manually editing the file. Cool. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 18, 2007 1:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] DSNs The path on XP is >Control Panel > Administrative Tools > Data Sources (ODBC) Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 10:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs >Hopefully I'm not being condescending. Not at all. I don't know this stuff >Control Panel > Data Sources (ODBC) I don't have that. Windows XP Profession SP2 >HKLM\Software\ODBC\ODBC.INI I don't understand this one. Is this a directory path? A registry key? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce H. Johnson Sent: Wednesday, July 18, 2007 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] DSNs Hopefully I'm not being condescending. If this is for your machine only: Control Panel > Data Sources (ODBC) If you need it programmable: HKLM\Software\ODBC\ODBC.INI HTH -- 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From jwelz at hotmail.com Wed Jul 18 16:17:46 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Wed, 18 Jul 2007 15:17:46 -0600 Subject: [AccessD] DSNs In-Reply-To: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> Message-ID: In my environment security renders me unable to create, modify or delete DSNs. Access connects to data in a series of files in a couple of folders in order to read or update information stored by something called a 'Pervasive Database Engine'. I tried relinking to different files at one time when I had rights for the purpose of testing and the time taken to relink was over a minute. What I do now instead is swap the files in the linked location and rename them to the required name. The file system can move the files in a second or two and I can simply use the linked tables with the existing DSN. My DSN points to a series of files in a specific folder and I have a prelinked file with a name based on the logged in UserID so it is useable in a multiuser envrionment. I created the initial link and took the time hit at that point. When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart Expansion - Delta.pee' in one of my lists, that file and some 60 files below it in a subfolder named PVData get copied to the DSN folder overwriting the file 6.pee and all the files below PVData (also renamed). Since the linked tables already exist in the Access applicaiton, the code immediately opens a recordset and reads, processes and reports on or updates the file. For reporting, I just leave the file in place and overwrite it. For updating, the code copies the file back to its source location so it can be opened in its source application. When we create new takeoff files, we use Access data to prefill in the names of the Architects, Engineers, Suppliers, Owners, Contractors, Estimator, our company information, bid closing time, closing date, location, contacts and a ton of other information that we track in Access. This saves our users a ton of time and helps ensure that the information has been validated in Access rather than entered via an application that does not permit validation. This approach was faster and painless in that it was easier to circumvent security restrictions that it would have been to try to change them. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "jwcolby" > >I am working with Access as the FE to processing orders where I need to >export to a fixed width file because Access stores the format, which is >convenient until I come up to speed on how to do something similar in SQL >Server. The issue is that the DSN is specific to a database name. How can >I edit that to point to a different database? > >John W. Colby >Colby Consulting >www.ColbyConsulting.com > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ New Windows Live Hotmail is here. Upgrade for free and get a better look. www.newhotmail.ca?icid=WLHMENCA150 From Jim.Hale at FleetPride.com Wed Jul 18 16:51:19 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Wed, 18 Jul 2007 16:51:19 -0500 Subject: [AccessD] DSNs In-Reply-To: References: <20070718142334.27D00BE1A@smtp-auth.no-ip.com> Message-ID: Isn't this process asynchronous, so there is a danger the user or code will move to other activities before the files have finished copying? I have had issues where dos copies or deletes haven't finished before the Access code tries to use the file. Solutions posted here from time to time (other than a primitive timer loop) to get Access to pause have not worked for me. Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 18, 2007 4:18 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] DSNs In my environment security renders me unable to create, modify or delete DSNs. Access connects to data in a series of files in a couple of folders in order to read or update information stored by something called a 'Pervasive Database Engine'. I tried relinking to different files at one time when I had rights for the purpose of testing and the time taken to relink was over a minute. What I do now instead is swap the files in the linked location and rename them to the required name. The file system can move the files in a second or two and I can simply use the linked tables with the existing DSN. My DSN points to a series of files in a specific folder and I have a prelinked file with a name based on the logged in UserID so it is useable in a multiuser envrionment. I created the initial link and took the time hit at that point. When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart Expansion - Delta.pee' in one of my lists, that file and some 60 files below it in a subfolder named PVData get copied to the DSN folder overwriting the file 6.pee and all the files below PVData (also renamed). Since the linked tables already exist in the Access applicaiton, the code immediately opens a recordset and reads, processes and reports on or updates the file. For reporting, I just leave the file in place and overwrite it. For updating, the code copies the file back to its source location so it can be opened in its source application. When we create new takeoff files, we use Access data to prefill in the names of the Architects, Engineers, Suppliers, Owners, Contractors, Estimator, our company information, bid closing time, closing date, location, contacts and a ton of other information that we track in Access. This saves our users a ton of time and helps ensure that the information has been validated in Access rather than entered via an application that does not permit validation. This approach was faster and painless in that it was easier to circumvent security restrictions that it would have been to try to change them. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From ssharkins at setel.com Wed Jul 18 16:55:50 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 18 Jul 2007 17:55:50 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <20070718195211.E5757BEDF@smtp-auth.no-ip.com> References: <001301c7c974$223e5c50$a2b82ad1@SusanOne> <20070718195211.E5757BEDF@smtp-auth.no-ip.com> Message-ID: <000101c7c986$6ab2c590$c0b62ad1@SusanOne> That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. =====Familiar to you, is it???? :) Susan H. From bheid at sc.rr.com Wed Jul 18 17:14:10 2007 From: bheid at sc.rr.com (Bobby Heid) Date: Wed, 18 Jul 2007 18:14:10 -0400 Subject: [AccessD] Require password for linked MDB tables In-Reply-To: References: <660053.99904.qm@web81313.mail.mud.yahoo.com> Message-ID: <006801c7c988$f7c3fba0$e74bf2e0$@rr.com> I guess if you asked the user for the password before linking the table, then it might work. You would have it unlink it after using it. Bobby -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Tuesday, July 17, 2007 3:49 PM To: accessd at databaseadvisors.com Subject: [AccessD] Require password for linked MDB tables Hello All, Can I have an MDB linked to a seperate MDB(with password)...and have the user required to enter just a password to view the linked table each time? And is it different in different versions? Thanks, Mark A. Matte From jwelz at hotmail.com Wed Jul 18 20:26:03 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Wed, 18 Jul 2007 19:26:03 -0600 Subject: [AccessD] DSNs In-Reply-To: Message-ID: I call the CopyFileA API from Lib "kernel32" that gives me an overwrite parameter and that proceeds synchronously. Alternatively I could call a ShellWait procedure as follows: Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) Dim proc As PROCESS_INFORMATION Dim start As STARTUPINFO Dim ret As Long With start .cb = Len(start) If Not IsMissing(WindowStyle) Then .dwFlags = STARTF_USESHOWWINDOW .wShowWindow = WindowStyle End If End With ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, 0&, 0&, start, proc) ret& = WaitForSingleObject(proc.hProcess, INFINITE) CloseHandle proc.hProcess End Sub but this has not been necessary as my copyfile wrapper waits until the copy completes before returning success or fail. No need for a timer kludge. This is the method I've used since Access97 was brand spanking new with 5 or 6 users and it works just as well with over 40. I've never known this approach to fail. In fact, every estimate we've done with Timberline in the past 9 years has used this method and there are 10s of thousands of these files. The links for reporting that have been created must be in the 100s of thousands. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Hale, Jim" > >Isn't this process asynchronous, so there is a danger the user or code will >move to other activities before the files have finished copying? I have >had issues where dos copies or deletes haven't finished before the Access >code tries to use the file. Solutions posted here from time to time (other >than a primitive timer loop) to get Access to pause have not worked for me. > >Jim Hale > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 4:18 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >In my environment security renders me unable to create, modify or delete >DSNs. Access connects to data in a series of files in a couple of folders >in order to read or update information stored by something called a >'Pervasive Database Engine'. > >I tried relinking to different files at one time when I had rights for the >purpose of testing and the time taken to relink was over a minute. What I >do now instead is swap the files in the linked location and rename them to >the required name. The file system can move the files in a second or two >and I can simply use the linked tables with the existing DSN. My DSN >points >to a series of files in a specific folder and I have a prelinked file with >a >name based on the logged in UserID so it is useable in a multiuser >envrionment. I created the initial link and took the time hit at that >point. > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart >Expansion - Delta.pee' in one of my lists, that file and some 60 files >below >it in a subfolder named PVData get copied to the DSN folder overwriting the >file 6.pee and all the files below PVData (also renamed). Since the linked >tables already exist in the Access applicaiton, the code immediately opens >a >recordset and reads, processes and reports on or updates the file. For >reporting, I just leave the file in place and overwrite it. For updating, >the code copies the file back to its source location so it can be opened in >its source application. When we create new takeoff files, we use Access >data to prefill in the names of the Architects, Engineers, Suppliers, >Owners, Contractors, Estimator, our company information, bid closing time, >closing date, location, contacts and a ton of other information that we >track in Access. This saves our users a ton of time and helps ensure that >the information has been validated in Access rather than entered via an >application that does not permit validation. > >This approach was faster and painless in that it was easier to circumvent >security restrictions that it would have been to try to change them. > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > >*********************************************************************** >The information transmitted is intended solely for the individual or >entity to which it is addressed and may contain confidential and/or >privileged material. Any review, retransmission, dissemination or >other use of or taking action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. >If you have received this email in error please contact the sender and >delete the material from any computer. As a recipient of this email, >you are responsible for screening its contents and the contents of any >attachments for the presence of viruses. No liability is accepted for >any damages caused by any virus transmitted by this email. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com . _________________________________________________________________ Windows Live Hotmail. Even hotter than before. Get a better look now. www.newhotmail.ca?icid=WLHMENCA148 From jwcolby at colbyconsulting.com Wed Jul 18 20:53:40 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 18 Jul 2007 21:53:40 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <000101c7c986$6ab2c590$c0b62ad1@SusanOne> Message-ID: <20070719015342.9BBFFBD0E@smtp-auth.no-ip.com> Oh yea. My life is made up of a series of OhNoSeconds. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 5:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. =====Familiar to you, is it???? :) Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Thu Jul 19 07:11:44 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 07:11:44 -0500 Subject: [AccessD] CopyFile (was DSNs) In-Reply-To: References: Message-ID: <000501c7c9fd$f9422900$0200a8c0@danwaters> Jurgen, Could you post your CopyFile wrapper procedure? Thanks, Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 18, 2007 8:26 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] DSNs I call the CopyFileA API from Lib "kernel32" that gives me an overwrite parameter and that proceeds synchronously. Alternatively I could call a ShellWait procedure as follows: Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) Dim proc As PROCESS_INFORMATION Dim start As STARTUPINFO Dim ret As Long With start .cb = Len(start) If Not IsMissing(WindowStyle) Then .dwFlags = STARTF_USESHOWWINDOW .wShowWindow = WindowStyle End If End With ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, 0&, 0&, start, proc) ret& = WaitForSingleObject(proc.hProcess, INFINITE) CloseHandle proc.hProcess End Sub but this has not been necessary as my copyfile wrapper waits until the copy completes before returning success or fail. No need for a timer kludge. This is the method I've used since Access97 was brand spanking new with 5 or 6 users and it works just as well with over 40. I've never known this approach to fail. In fact, every estimate we've done with Timberline in the past 9 years has used this method and there are 10s of thousands of these files. The links for reporting that have been created must be in the 100s of thousands. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Hale, Jim" > >Isn't this process asynchronous, so there is a danger the user or code will >move to other activities before the files have finished copying? I have >had issues where dos copies or deletes haven't finished before the Access >code tries to use the file. Solutions posted here from time to time (other >than a primitive timer loop) to get Access to pause have not worked for me. > >Jim Hale > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 4:18 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >In my environment security renders me unable to create, modify or delete >DSNs. Access connects to data in a series of files in a couple of folders >in order to read or update information stored by something called a >'Pervasive Database Engine'. > >I tried relinking to different files at one time when I had rights for the >purpose of testing and the time taken to relink was over a minute. What I >do now instead is swap the files in the linked location and rename them to >the required name. The file system can move the files in a second or two >and I can simply use the linked tables with the existing DSN. My DSN >points >to a series of files in a specific folder and I have a prelinked file with >a >name based on the logged in UserID so it is useable in a multiuser >envrionment. I created the initial link and took the time hit at that >point. > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart >Expansion - Delta.pee' in one of my lists, that file and some 60 files >below >it in a subfolder named PVData get copied to the DSN folder overwriting the >file 6.pee and all the files below PVData (also renamed). Since the linked >tables already exist in the Access applicaiton, the code immediately opens >a >recordset and reads, processes and reports on or updates the file. For >reporting, I just leave the file in place and overwrite it. For updating, >the code copies the file back to its source location so it can be opened in >its source application. When we create new takeoff files, we use Access >data to prefill in the names of the Architects, Engineers, Suppliers, >Owners, Contractors, Estimator, our company information, bid closing time, >closing date, location, contacts and a ton of other information that we >track in Access. This saves our users a ton of time and helps ensure that >the information has been validated in Access rather than entered via an >application that does not permit validation. > >This approach was faster and painless in that it was easier to circumvent >security restrictions that it would have been to try to change them. > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > >*********************************************************************** >The information transmitted is intended solely for the individual or >entity to which it is addressed and may contain confidential and/or >privileged material. Any review, retransmission, dissemination or >other use of or taking action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. >If you have received this email in error please contact the sender and >delete the material from any computer. As a recipient of this email, >you are responsible for screening its contents and the contents of any >attachments for the presence of viruses. No liability is accepted for >any damages caused by any virus transmitted by this email. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.c From jwelz at hotmail.com Thu Jul 19 07:58:09 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 19 Jul 2007 06:58:09 -0600 Subject: [AccessD] CopyFile (was DSNs) In-Reply-To: <000501c7c9fd$f9422900$0200a8c0@danwaters> Message-ID: Private Declare Function CopyFileA Lib "kernel32" (ByVal ExistingFileName As String, _ ByVal NewFileName As String, ByVal FailIfExists As Long) As Long Public Function Copy(FileSrc As String, FileDst As String, Optional NoOverWrite As Boolean = True) _ As Boolean On Error GoTo ErrorHandler Copy = CopyFileA(FileSrc, FileDst, NoOverWrite) = 1 ExitRoutine: On Error Resume Next Exit Function ErrorHandler: With Err Select Case .Number Case Else MsgBox .Number & vbCrLf & .Description, vbInformation, "Error - Copy" End Select End With 'Resume 0 Resume ExitRoutine End Function Parameters are: FileSrc : Full path and file name. Accepts UNC or Mapped. The caller verifies the existence of the source file with Len(Dir(FileSrc)) prior to calling Copy. FileDst: Full path and file name. As above except the caller creates the target path if it doesn't exist by calling a function called fnCreateBasePath (below). NoOverWrite is an optional boolean parameter that if left out will not allow the function to overwrite an existing file. You must pass a false if you wish it to overwrite a preexisting target file. To ensure the creation of the target path, I use a couple of functions. I check available drives and once the target drive is verified, the caller of the Copy procedure also calls: Public Function fnCreateBasePath(strCreatePath As String) As Boolean On Error GoTo ErrorHandler Dim strPath As String Dim lngPos As Long strCreatePath = Trim$(strCreatePath) If Right$(strCreatePath, 1) <> "\" Then strCreatePath = strCreatePath & "\" lngPos = 7 Do Until lngPos = 1 lngPos = InStr(lngPos + 1, strCreatePath, "\") If lngPos Then strPath = Left$(strCreatePath, lngPos - 1) If Not Len(Dir(strPath, vbDirectory)) > 0 Then MkDir strPath End If End If lngPos = lngPos + 1 Loop fnCreateBasePath = True ExitRoutine: On Error Resume Next Exit Function ErrorHandler: With Err Select Case .Number Case Else MsgBox .Number & vbCrLf & .Description & vbCrLf & vbCrLf & _ " Error in creating Folder: '" & strCreatePath & "'", _ vbInformation, "Error - fnCreateBasePath" End Select End With 'Resume 0 Resume ExitRoutine End Function In my environment I am guaranteed that the lower base path inicluding the drive letter willl exceed 7 characters once the drive has been verified which is why lngPos starts at an initial value of 7. If any part of the procedure fails, it reports failure to the caller and the caller aborts with an error message to the user. Because it is synchronous, there is no misreporting on old data that failed to be overwritten. For certain kinds of files, I verify that no one has the source file open by calling a file Open (help file says Open pathname For mode [Access access] [lock] As [#]filenumber [Len=reclength]) and attempting to open exclusive. Alternatively, if you've set up your file structure like mine where files related to a record are in or below a single folder, you can check whether anyone is working in any files related to the record by attempting to rename the folder first. I'm certain the filesystemobject will let you do these things as well but it requires a reference to some scripting library that is not enabled in my users' environment. In any event, the built in VBA file and folder methods are fast and totally reliable and don't require loading external libraries so without a need to use the FSO, I'll leave things as they are. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Dan Waters" > >Jurgen, > >Could you post your CopyFile wrapper procedure? > >Thanks, >Dan Waters > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 8:26 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >I call the CopyFileA API from Lib "kernel32" that gives me an overwrite >parameter and that proceeds synchronously. Alternatively I could call a >ShellWait procedure as follows: > >Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) > Dim proc As PROCESS_INFORMATION > Dim start As STARTUPINFO > Dim ret As Long > > With start > .cb = Len(start) > If Not IsMissing(WindowStyle) Then > .dwFlags = STARTF_USESHOWWINDOW > .wShowWindow = WindowStyle > End If > End With > ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, >0&, 0&, start, proc) > ret& = WaitForSingleObject(proc.hProcess, INFINITE) > CloseHandle proc.hProcess >End Sub > >but this has not been necessary as my copyfile wrapper waits until the copy >completes before returning success or fail. No need for a timer kludge. > >This is the method I've used since Access97 was brand spanking new with 5 >or > >6 users and it works just as well with over 40. I've never known this >approach to fail. In fact, every estimate we've done with Timberline in >the > >past 9 years has used this method and there are 10s of thousands of these >files. The links for reporting that have been created must be in the 100s >of thousands. > > > > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > > > > > >From: "Hale, Jim" > > > >Isn't this process asynchronous, so there is a danger the user or code >will > > >move to other activities before the files have finished copying? I have > >had issues where dos copies or deletes haven't finished before the Access > >code tries to use the file. Solutions posted here from time to time >(other > >than a primitive timer loop) to get Access to pause have not worked for >me. > > > >Jim Hale > > > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz > >Sent: Wednesday, July 18, 2007 4:18 PM > >To: accessd at databaseadvisors.com > >Subject: Re: [AccessD] DSNs > > > >In my environment security renders me unable to create, modify or delete > >DSNs. Access connects to data in a series of files in a couple of >folders > >in order to read or update information stored by something called a > >'Pervasive Database Engine'. > > > >I tried relinking to different files at one time when I had rights for >the > >purpose of testing and the time taken to relink was over a minute. What >I > >do now instead is swap the files in the linked location and rename them >to > >the required name. The file system can move the files in a second or two > >and I can simply use the linked tables with the existing DSN. My DSN > >points > >to a series of files in a specific folder and I have a prelinked file >with > >a > >name based on the logged in UserID so it is useable in a multiuser > >envrionment. I created the initial link and took the time hit at that > >point. > > > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart > >Expansion - Delta.pee' in one of my lists, that file and some 60 files > >below > >it in a subfolder named PVData get copied to the DSN folder overwriting >the > >file 6.pee and all the files below PVData (also renamed). Since the >linked > >tables already exist in the Access applicaiton, the code immediately >opens > >a > >recordset and reads, processes and reports on or updates the file. For > >reporting, I just leave the file in place and overwrite it. For >updating, > >the code copies the file back to its source location so it can be opened >in > >its source application. When we create new takeoff files, we use Access > >data to prefill in the names of the Architects, Engineers, Suppliers, > >Owners, Contractors, Estimator, our company information, bid closing >time, > >closing date, location, contacts and a ton of other information that we > >track in Access. This saves our users a ton of time and helps ensure >that > >the information has been validated in Access rather than entered via an > >application that does not permit validation. > > > >This approach was faster and painless in that it was easier to circumvent > >security restrictions that it would have been to try to change them. > > > >Ciao > >J?rgen Welz > >Edmonton, Alberta > >jwelz at hotmail.com > > > >*********************************************************************** > >The information transmitted is intended solely for the individual or > >entity to which it is addressed and may contain confidential and/or > >privileged material. Any review, retransmission, dissemination or > >other use of or taking action in reliance upon this information by > >persons or entities other than the intended recipient is prohibited. > >If you have received this email in error please contact the sender and > >delete the material from any computer. As a recipient of this email, > >you are responsible for screening its contents and the contents of any > >attachments for the presence of viruses. No liability is accepted for > >any damages caused by any virus transmitted by this email. > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.c > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Windows Live Hotmail with drag and drop, you can easily move and organize your mail in one simple step. Get it today! www.newhotmail.ca?icid=WLHMENCA153 From dwaters at usinternet.com Thu Jul 19 08:12:54 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 08:12:54 -0500 Subject: [AccessD] CopyFile (was DSNs) In-Reply-To: References: <000501c7c9fd$f9422900$0200a8c0@danwaters> Message-ID: <001001c7ca06$857a5570$0200a8c0@danwaters> Excellent! Thanks Jurgen! Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Thursday, July 19, 2007 7:58 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] CopyFile (was DSNs) Private Declare Function CopyFileA Lib "kernel32" (ByVal ExistingFileName As String, _ ByVal NewFileName As String, ByVal FailIfExists As Long) As Long Public Function Copy(FileSrc As String, FileDst As String, Optional NoOverWrite As Boolean = True) _ As Boolean On Error GoTo ErrorHandler Copy = CopyFileA(FileSrc, FileDst, NoOverWrite) = 1 ExitRoutine: On Error Resume Next Exit Function ErrorHandler: With Err Select Case .Number Case Else MsgBox .Number & vbCrLf & .Description, vbInformation, "Error - Copy" End Select End With 'Resume 0 Resume ExitRoutine End Function Parameters are: FileSrc : Full path and file name. Accepts UNC or Mapped. The caller verifies the existence of the source file with Len(Dir(FileSrc)) prior to calling Copy. FileDst: Full path and file name. As above except the caller creates the target path if it doesn't exist by calling a function called fnCreateBasePath (below). NoOverWrite is an optional boolean parameter that if left out will not allow the function to overwrite an existing file. You must pass a false if you wish it to overwrite a preexisting target file. To ensure the creation of the target path, I use a couple of functions. I check available drives and once the target drive is verified, the caller of the Copy procedure also calls: Public Function fnCreateBasePath(strCreatePath As String) As Boolean On Error GoTo ErrorHandler Dim strPath As String Dim lngPos As Long strCreatePath = Trim$(strCreatePath) If Right$(strCreatePath, 1) <> "\" Then strCreatePath = strCreatePath & "\" lngPos = 7 Do Until lngPos = 1 lngPos = InStr(lngPos + 1, strCreatePath, "\") If lngPos Then strPath = Left$(strCreatePath, lngPos - 1) If Not Len(Dir(strPath, vbDirectory)) > 0 Then MkDir strPath End If End If lngPos = lngPos + 1 Loop fnCreateBasePath = True ExitRoutine: On Error Resume Next Exit Function ErrorHandler: With Err Select Case .Number Case Else MsgBox .Number & vbCrLf & .Description & vbCrLf & vbCrLf & _ " Error in creating Folder: '" & strCreatePath & "'", _ vbInformation, "Error - fnCreateBasePath" End Select End With 'Resume 0 Resume ExitRoutine End Function In my environment I am guaranteed that the lower base path inicluding the drive letter willl exceed 7 characters once the drive has been verified which is why lngPos starts at an initial value of 7. If any part of the procedure fails, it reports failure to the caller and the caller aborts with an error message to the user. Because it is synchronous, there is no misreporting on old data that failed to be overwritten. For certain kinds of files, I verify that no one has the source file open by calling a file Open (help file says Open pathname For mode [Access access] [lock] As [#]filenumber [Len=reclength]) and attempting to open exclusive. Alternatively, if you've set up your file structure like mine where files related to a record are in or below a single folder, you can check whether anyone is working in any files related to the record by attempting to rename the folder first. I'm certain the filesystemobject will let you do these things as well but it requires a reference to some scripting library that is not enabled in my users' environment. In any event, the built in VBA file and folder methods are fast and totally reliable and don't require loading external libraries so without a need to use the FSO, I'll leave things as they are. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Dan Waters" > >Jurgen, > >Could you post your CopyFile wrapper procedure? > >Thanks, >Dan Waters > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 8:26 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >I call the CopyFileA API from Lib "kernel32" that gives me an overwrite >parameter and that proceeds synchronously. Alternatively I could call a >ShellWait procedure as follows: > >Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) > Dim proc As PROCESS_INFORMATION > Dim start As STARTUPINFO > Dim ret As Long > > With start > .cb = Len(start) > If Not IsMissing(WindowStyle) Then > .dwFlags = STARTF_USESHOWWINDOW > .wShowWindow = WindowStyle > End If > End With > ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, >0&, 0&, start, proc) > ret& = WaitForSingleObject(proc.hProcess, INFINITE) > CloseHandle proc.hProcess >End Sub > >but this has not been necessary as my copyfile wrapper waits until the copy >completes before returning success or fail. No need for a timer kludge. > >This is the method I've used since Access97 was brand spanking new with 5 >or > >6 users and it works just as well with over 40. I've never known this >approach to fail. In fact, every estimate we've done with Timberline in >the > >past 9 years has used this method and there are 10s of thousands of these >files. The links for reporting that have been created must be in the 100s >of thousands. > > > > >Ciao >J|rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > > > > > >From: "Hale, Jim" > > > >Isn't this process asynchronous, so there is a danger the user or code >will > > >move to other activities before the files have finished copying? I have > >had issues where dos copies or deletes haven't finished before the Access > >code tries to use the file. Solutions posted here from time to time >(other > >than a primitive timer loop) to get Access to pause have not worked for >me. > > > >Jim Hale > > > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz > >Sent: Wednesday, July 18, 2007 4:18 PM > >To: accessd at databaseadvisors.com > >Subject: Re: [AccessD] DSNs > > > >In my environment security renders me unable to create, modify or delete > >DSNs. Access connects to data in a series of files in a couple of >folders > >in order to read or update information stored by something called a > >'Pervasive Database Engine'. > > > >I tried relinking to different files at one time when I had rights for >the > >purpose of testing and the time taken to relink was over a minute. What >I > >do now instead is swap the files in the linked location and rename them >to > >the required name. The file system can move the files in a second or two > >and I can simply use the linked tables with the existing DSN. My DSN > >points > >to a series of files in a specific folder and I have a prelinked file >with > >a > >name based on the logged in UserID so it is useable in a multiuser > >envrionment. I created the initial link and took the time hit at that > >point. > > > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart > >Expansion - Delta.pee' in one of my lists, that file and some 60 files > >below > >it in a subfolder named PVData get copied to the DSN folder overwriting >the > >file 6.pee and all the files below PVData (also renamed). Since the >linked > >tables already exist in the Access applicaiton, the code immediately >opens > >a > >recordset and reads, processes and reports on or updates the file. For > >reporting, I just leave the file in place and overwrite it. For >updating, > >the code copies the file back to its source location so it can be opened >in > >its source application. When we create new takeoff files, we use Access > >data to prefill in the names of the Architects, Engineers, Suppliers, > >Owners, Contractors, Estimator, our company information, bid closing >time, > >closing date, location, contacts and a ton of other information that we > >track in Access. This saves our users a ton of time and helps ensure >that > >the information has been validated in Access rather than entered via an > >application that does not permit validation. > > > >This approach was faster and painless in that it was easier to circumvent > >security restrictions that it would have been to try to change them. > > > >Ciao > >J|rgen Welz > >Edmonton, Alberta > >jwelz at hotmail.com > > > >*********************************************************************** > >The information transmitted is intended solely for the individual or > >entity to which it is addressed and may contain confidential and/or > >privileged material. Any review, retransmission, dissemination or > >other use of or taking action in reliance upon this information by > >persons or entities other than the intended recipient is prohibited. > >If you have received this email in error please contact the sender and > >delete the material from any computer. As a recipient of this email, > >you are responsible for screening its contents and the contents of any > >attachments for the presence of viruses. No liability is accepted for > >any damages caused by any virus transmitted by this email. > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.c > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Windows Live Hotmail with drag and drop, you can easily move and organize your mail in one simple step. Get it today! www.newhotmail.ca?icid=WLHMENCA153 From Jim.Hale at FleetPride.com Thu Jul 19 08:16:02 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 19 Jul 2007 08:16:02 -0500 Subject: [AccessD] DSNs In-Reply-To: References: Message-ID: Very nice, I'll give it a try, thanks Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 18, 2007 8:26 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] DSNs I call the CopyFileA API from Lib "kernel32" that gives me an overwrite parameter and that proceeds synchronously. Alternatively I could call a ShellWait procedure as follows: Public Sub ShellWait(pathname As String, Optional WindowStyle As Long) Dim proc As PROCESS_INFORMATION Dim start As STARTUPINFO Dim ret As Long With start .cb = Len(start) If Not IsMissing(WindowStyle) Then .dwFlags = STARTF_USESHOWWINDOW .wShowWindow = WindowStyle End If End With ret& = CreateProcessA(0&, pathname, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, 0&, 0&, start, proc) ret& = WaitForSingleObject(proc.hProcess, INFINITE) CloseHandle proc.hProcess End Sub but this has not been necessary as my copyfile wrapper waits until the copy completes before returning success or fail. No need for a timer kludge. This is the method I've used since Access97 was brand spanking new with 5 or 6 users and it works just as well with over 40. I've never known this approach to fail. In fact, every estimate we've done with Timberline in the past 9 years has used this method and there are 10s of thousands of these files. The links for reporting that have been created must be in the 100s of thousands. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Hale, Jim" > >Isn't this process asynchronous, so there is a danger the user or code will >move to other activities before the files have finished copying? I have >had issues where dos copies or deletes haven't finished before the Access >code tries to use the file. Solutions posted here from time to time (other >than a primitive timer loop) to get Access to pause have not worked for me. > >Jim Hale > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz >Sent: Wednesday, July 18, 2007 4:18 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] DSNs > >In my environment security renders me unable to create, modify or delete >DSNs. Access connects to data in a series of files in a couple of folders >in order to read or update information stored by something called a >'Pervasive Database Engine'. > >I tried relinking to different files at one time when I had rights for the >purpose of testing and the time taken to relink was over a minute. What I >do now instead is swap the files in the linked location and rename them to >the required name. The file system can move the files in a second or two >and I can simply use the linked tables with the existing DSN. My DSN >points >to a series of files in a specific folder and I have a prelinked file with >a >name based on the logged in UserID so it is useable in a multiuser >envrionment. I created the initial link and took the time hit at that >point. > >When a user, whose ID is 6, doubleclicks a file named '\...\...\PetSmart >Expansion - Delta.pee' in one of my lists, that file and some 60 files >below >it in a subfolder named PVData get copied to the DSN folder overwriting the >file 6.pee and all the files below PVData (also renamed). Since the linked >tables already exist in the Access applicaiton, the code immediately opens >a >recordset and reads, processes and reports on or updates the file. For >reporting, I just leave the file in place and overwrite it. For updating, >the code copies the file back to its source location so it can be opened in >its source application. When we create new takeoff files, we use Access >data to prefill in the names of the Architects, Engineers, Suppliers, >Owners, Contractors, Estimator, our company information, bid closing time, >closing date, location, contacts and a ton of other information that we >track in Access. This saves our users a ton of time and helps ensure that >the information has been validated in Access rather than entered via an >application that does not permit validation. > >This approach was faster and painless in that it was easier to circumvent >security restrictions that it would have been to try to change them. > >Ciao >J?rgen Welz >Edmonton, Alberta >jwelz at hotmail.com > >*********************************************************************** >The information transmitted is intended solely for the individual or >entity to which it is addressed and may contain confidential and/or >privileged material. Any review, retransmission, dissemination or >other use of or taking action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. >If you have received this email in error please contact the sender and >delete the material from any computer. As a recipient of this email, >you are responsible for screening its contents and the contents of any >attachments for the presence of viruses. No liability is accepted for >any damages caused by any virus transmitted by this email. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com . _________________________________________________________________ Windows Live Hotmail. Even hotter than before. Get a better look now. www.newhotmail.ca?icid=WLHMENCA148 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From jwelz at hotmail.com Thu Jul 19 08:42:36 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 19 Jul 2007 07:42:36 -0600 Subject: [AccessD] CopyFile (was DSNs) In-Reply-To: <000501c7c9fd$f9422900$0200a8c0@danwaters> Message-ID: An anomoly I've recently run into has been an inconsistency in mapping of several of our drives in a Remote Desktop environment where the server environment is Win2K3 Server. When a user of mine clicks a record's explore button on a form, the application checks for the existence of the record's target folder and creates it if it doesn't exist. The target path is passed to shellexecute and a windows explorer window opens to the target path. If the mapping is good, the path is correct and any existing files or folders are displayed. If the mapping doesn't exist, the procedure that creates the path creates a path alright. It is on the correct drive, but it is an 8.3 path. The explorer window will display the full mapped path at the top of the window. Users will drag files into this folder to related them to the record. For example, we may get some pdf specs and some dwg blueprints, or email correspondence. The users navigate to the record, pop the explorer window and drag or paste files into the record's folder. But if the mapping is bad and there are spaces in the file name or parts of the path or file name exceed 8 characters, there is a problem. If the file name doesn't comply with the 8.3 or has a space, Explorer will present a user with an error message and offer to fix the file name. When the file is pasted, it goes into a locaton with a truncated path and never appears in the explorer window the user has open into which files are pasted. Bizzare. If the application creates a file, like an estimate, Word or Excel file, it will save it in a truncated path. No error is ever returned by the file system. If my procedure calls MkDir in a loop to create("S:\GOM\Vancouver\2003\..."), the code will in fact create S:\GOM\Vancouve\2003\..." truncating Vancouver and never giving an error. In such a case, the file will be saved in the truncated path and the name will be truncated, if necessary, but no error message at all is returned anywhere. This problem started happening in April 2007. I am told by IT that it has to do with terminals that allow upload by providing access to local resources (local usb connected ports). However, this had never been a problem in the past. The older versions of the server Windows would report an error in a situation like this and the 2003 version had been reliable for the 2.5 years preceeding this April even though we've had access to local resources the entire time. There must be some service pack to the server windows that messed up the system. With the older versions of Windows, I could occasionally enumerate mapped drives and the system would list drives that were actually disconnected. The only reliable means of verifying a mapped drive was to run a directory against the mapped drive and see if a '.' was returned. For this reason I mentioned in the previous post that I verify existence of mapped drives. The bizzare thing is that the base path I create is on the mapped drive and thats where it is created, even if the mapped drive doesn't exist. The solution was to use the UNC paths, but that was complicated on the July 1 long weekend when we switched from 2 servers to 5. While most of the files remain on a single server, all Estimate files need to reside on a root (C or D) drive of the former 2nd server. Fortunately, copying to the UNC will place them on an appropriate root drive. As the servers are broken down on a regional basis, I've had to update my code to work with the correct server in the situation. Given that all servers are mapped identically, it would have been easier to stay with the drive mappings, but reliability concerns have prompted me to consider moving strictly to UNC paths. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com _________________________________________________________________ Fight Allergies With Live Search http://search.live.com/results.aspx?q=Remedies+For+Spring+Allergies&mkt=en-ca&FORM=SERNEP From markamatte at hotmail.com Thu Jul 19 08:53:01 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 19 Jul 2007 13:53:01 +0000 Subject: [AccessD] Require password for linked MDB tables In-Reply-To: <006801c7c988$f7c3fba0$e74bf2e0$@rr.com> Message-ID: But if I use the following to try to link...I get the error (invalid Password): Set tdf = dbs.CreateTableDef("Test") tdf.Connect = ";Database=C:\temp\test.mdb" tdf.SourceTableName = "tblPass" dbs.TableDefs.Append tdf >From: "Bobby Heid" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Require password for linked MDB tables >Date: Wed, 18 Jul 2007 18:14:10 -0400 > >I guess if you asked the user for the password before linking the table, >then it might work. You would have it unlink it after using it. > >Bobby > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Tuesday, July 17, 2007 3:49 PM >To: accessd at databaseadvisors.com >Subject: [AccessD] Require password for linked MDB tables > >Hello All, > >Can I have an MDB linked to a seperate MDB(with password)...and have the >user required to enter just a password to view the linked table each time? > >And is it different in different versions? > >Thanks, > >Mark A. Matte > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://im.live.com/messenger/im/home/?source=hmtextlinkjuly07 From jwcolby at colbyconsulting.com Thu Jul 19 09:27:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 10:27:23 -0400 Subject: [AccessD] OT: Excel - Get sheet out of workbook Message-ID: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> I have a workbook with 4 sheets. I need to get those four sheets out into separate workbooks (one sheet per workbook). Other than copying the file four times and deleting the sheets not wanted, is there a way to save a specific sheet as a new workbook? John W. Colby Colby Consulting www.ColbyConsulting.com From jwcolby at colbyconsulting.com Thu Jul 19 09:31:31 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 10:31:31 -0400 Subject: [AccessD] OT: Excel - Merge several cells Message-ID: <20070719143134.436C0BD57@smtp-auth.no-ip.com> I need to "merge" several cells to create one big cell. I have seen this in spreadsheets but have no idea how to do it myself. Any clue? For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and all the cells below them remain as they were. I need to put text in a "header cell". TIA John W. Colby Colby Consulting www.ColbyConsulting.com From Chris.Foote at uk.thalesgroup.com Thu Jul 19 09:46:20 2007 From: Chris.Foote at uk.thalesgroup.com (Foote, Chris) Date: Thu, 19 Jul 2007 15:46:20 +0100 Subject: [AccessD] OT: Excel - Merge several cells Message-ID: <7303A459C921B5499AF732CCEEAD2B7F064D1103@craws161660.int.rdel.co.uk> Hi John! Select all the cells you need to "merge". Right mouse click. Select "Format Cells". Select "Alignment" tab. Select "Merge cells" check box. Click "OK" button. Viola! Regards Chris Foote > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 3:32 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Merge several cells > > > I need to "merge" several cells to create one big cell. I > have seen this in > spreadsheets but have no idea how to do it myself. > > Any clue? > > For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and > all the cells > below them remain as they were. I need to put text in a > "header cell". > > TIA > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From jwcolby at colbyconsulting.com Thu Jul 19 09:52:42 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 10:52:42 -0400 Subject: [AccessD] OT: Excel - Merge several cells In-Reply-To: <7303A459C921B5499AF732CCEEAD2B7F064D1103@craws161660.int.rdel.co.uk> Message-ID: <20070719145242.E51E3BCB0@smtp-auth.no-ip.com> Voila indeed! Today, you da man! Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Foote, Chris Sent: Thursday, July 19, 2007 10:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Merge several cells Hi John! Select all the cells you need to "merge". Right mouse click. Select "Format Cells". Select "Alignment" tab. Select "Merge cells" check box. Click "OK" button. Viola! Regards Chris Foote > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 3:32 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Merge several cells > > > I need to "merge" several cells to create one big cell. I have seen > this in spreadsheets but have no idea how to do it myself. > > Any clue? > > For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and all the > cells below them remain as they were. I need to put text in a "header > cell". > > TIA > > John W. Colby > Colby Consulting > www.ColbyConsulting.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 dwaters at usinternet.com Thu Jul 19 09:53:39 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 09:53:39 -0500 Subject: [AccessD] OT: Excel - Get sheet out of workbook In-Reply-To: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> References: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> Message-ID: <001a01c7ca14$98637500$0200a8c0@danwaters> Yes - 1) Go to Sheet X of Y. 2) Select the entire sheet by clicking the gray box at the intersection of columns and rows. 3) Copy 4) Open new workbook by clicking the New button. 5) Select the same gray box as in 2). 6) Paste 7) Repeat as needed. This will preserve the text formatting and column and row sizes. HTH! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 9:27 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Excel - Get sheet out of workbook I have a workbook with 4 sheets. I need to get those four sheets out into separate workbooks (one sheet per workbook). Other than copying the file four times and deleting the sheets not wanted, is there a way to save a specific sheet as a new workbook? John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Thu Jul 19 09:56:07 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 09:56:07 -0500 Subject: [AccessD] OT: Excel - Merge several cells In-Reply-To: <20070719143134.436C0BD57@smtp-auth.no-ip.com> References: <20070719143134.436C0BD57@smtp-auth.no-ip.com> Message-ID: <001b01c7ca14$efda5b50$0200a8c0@danwaters> There is a button immediately to the right of the right-hand justify button. It's called Merge and Center. 1) Select the cells you want to merge. (you might lose text) 2) Push the button. That's it! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 9:32 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Excel - Merge several cells I need to "merge" several cells to create one big cell. I have seen this in spreadsheets but have no idea how to do it myself. Any clue? For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and all the cells below them remain as they were. I need to put text in a "header cell". TIA John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Thu Jul 19 09:57:22 2007 From: dwaters at usinternet.com (Dan Waters) Date: Thu, 19 Jul 2007 09:57:22 -0500 Subject: [AccessD] OT: Excel - Merge several cells In-Reply-To: <7303A459C921B5499AF732CCEEAD2B7F064D1103@craws161660.int.rdel.co.uk> References: <7303A459C921B5499AF732CCEEAD2B7F064D1103@craws161660.int.rdel.co.uk> Message-ID: <001c01c7ca15$1cd789c0$0200a8c0@danwaters> You can also use this method to 'unmerge' cells by unchecking the 'Merge cells' checkbox. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Foote, Chris Sent: Thursday, July 19, 2007 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Merge several cells Hi John! Select all the cells you need to "merge". Right mouse click. Select "Format Cells". Select "Alignment" tab. Select "Merge cells" check box. Click "OK" button. Viola! Regards Chris Foote > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 3:32 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Merge several cells > > > I need to "merge" several cells to create one big cell. I > have seen this in > spreadsheets but have no idea how to do it myself. > > Any clue? > > For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and > all the cells > below them remain as they were. I need to put text in a > "header cell". > > TIA > > John W. Colby > Colby Consulting > www.ColbyConsulting.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 jwcolby at colbyconsulting.com Thu Jul 19 10:02:21 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 11:02:21 -0400 Subject: [AccessD] OT: Excel - Get sheet out of workbook In-Reply-To: <001a01c7ca14$98637500$0200a8c0@danwaters> Message-ID: <20070719150222.85F73BF4B@smtp-auth.no-ip.com> Bueno. Silly me, I expect something like "select the sheet tab, right click, save as..." Makes too much sense I guess. Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Thursday, July 19, 2007 10:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Get sheet out of workbook Yes - 1) Go to Sheet X of Y. 2) Select the entire sheet by clicking the gray box at the intersection of columns and rows. 3) Copy 4) Open new workbook by clicking the New button. 5) Select the same gray box as in 2). 6) Paste 7) Repeat as needed. This will preserve the text formatting and column and row sizes. HTH! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 9:27 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Excel - Get sheet out of workbook I have a workbook with 4 sheets. I need to get those four sheets out into separate workbooks (one sheet per workbook). Other than copying the file four times and deleting the sheets not wanted, is there a way to save a specific sheet as a new workbook? John W. Colby Colby Consulting www.ColbyConsulting.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 markamatte at hotmail.com Thu Jul 19 10:10:33 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 19 Jul 2007 15:10:33 +0000 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: Hello All, This is just a 'mild' form of encryption...but I need to use math(+-*/) with numbers up to 16 digits(9,999,999,999,999,999)... Is there any way to do this without losing accuracy in VBA? Thanks, Mark A. Matte _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary!? http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 From cfoust at infostatsystems.com Thu Jul 19 10:10:17 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 19 Jul 2007 08:10:17 -0700 Subject: [AccessD] Function to grab decimal value? In-Reply-To: <20070719015342.9BBFFBD0E@smtp-auth.no-ip.com> References: <000101c7c986$6ab2c590$c0b62ad1@SusanOne> <20070719015342.9BBFFBD0E@smtp-auth.no-ip.com> Message-ID: Try having an OhNoDecade ...:{ Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 6:54 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? Oh yea. My life is made up of a series of OhNoSeconds. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 5:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. =====Familiar to you, is it???? :) 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 jwcolby at colbyconsulting.com Thu Jul 19 10:20:44 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 11:20:44 -0400 Subject: [AccessD] Function to grab decimal value? In-Reply-To: Message-ID: <20070719152045.9DE34BD58@smtp-auth.no-ip.com> ROTFL. I am rapidly reaching that age where... John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 19, 2007 11:10 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Function to grab decimal value? Try having an OhNoDecade ...:{ Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 18, 2007 6:54 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? Oh yea. My life is made up of a series of OhNoSeconds. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 18, 2007 5:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Function to grab decimal value? That OhNoSecond... The period of time between pressing the send key and regretting pressing the send key. =====Familiar to you, is it???? :) Susan H. From reuben at gfconsultants.com Thu Jul 19 10:24:22 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Thu, 19 Jul 2007 11:24:22 -0400 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: Currency data types would be perfect if you are concerned about the accuracy of the decimals. However, it only handles 15 digits to the left of the decimal point (and four to the left). Single can be used well, but you will have to be careful how you handle rounding. I have to use single in several cases and then test, test, test to determine in what order, when, and where I should perform any rounding. Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte > Sent: Thursday, July 19, 2007 11:11 AM > To: accessd at databaseadvisors.com > Subject: [AccessD] Math in VBA > > > Hello All, > > This is just a 'mild' form of encryption...but I need to use > math(+-*/) with > numbers up to 16 digits(9,999,999,999,999,999)... > > Is there any way to do this without losing accuracy in VBA? > > Thanks, > > Mark A. Matte > > _________________________________________________________________ > Don't get caught with egg on your face. Play Chicktionary! > http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 > > From reuben at gfconsultants.com Thu Jul 19 10:34:31 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Thu, 19 Jul 2007 11:34:31 -0400 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: > decimal point (and four to the left). Should be four to the right Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Reuben > Cummings > Sent: Thursday, July 19, 2007 11:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Math in VBA > > > Currency data types would be perfect if you are concerned about > the accuracy > of the decimals. However, it only handles 15 digits to the left of the > decimal point (and four to the left). > > Single can be used well, but you will have to be careful how you handle > rounding. I have to use single in several cases and then test, test, test > to determine in what order, when, and where I should perform any rounding. > > Reuben Cummings > GFC, LLC > 812.523.1017 > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte > > Sent: Thursday, July 19, 2007 11:11 AM > > To: accessd at databaseadvisors.com > > Subject: [AccessD] Math in VBA > > > > > > Hello All, > > > > This is just a 'mild' form of encryption...but I need to use > > math(+-*/) with > > numbers up to 16 digits(9,999,999,999,999,999)... > > > > Is there any way to do this without losing accuracy in VBA? > > > > Thanks, > > > > Mark A. Matte > > > > _________________________________________________________________ > > Don't get caught with egg on your face. Play Chicktionary! > > http://club.live.com/chicktionary.aspx?icid=chick_hotmailtextlink2 > > > > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From Lambert.Heenan at AIG.com Thu Jul 19 10:35:13 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Thu, 19 Jul 2007 11:35:13 -0400 Subject: [AccessD] OT: Excel - Get sheet out of workbook Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6C7D@xlivmbx35.aig.com> Even easier: Right Click the tab and select "Move Or Copy". In the Move or Copy dialog select "(new book)" in "To Book" combo and check the "Create a Copy" box at the bottom. That gives you an exact copy of the sheet in a new book. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 11:02 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Get sheet out of workbook Bueno. Silly me, I expect something like "select the sheet tab, right click, save as..." Makes too much sense I guess. Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Thursday, July 19, 2007 10:54 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] OT: Excel - Get sheet out of workbook Yes - 1) Go to Sheet X of Y. 2) Select the entire sheet by clicking the gray box at the intersection of columns and rows. 3) Copy 4) Open new workbook by clicking the New button. 5) Select the same gray box as in 2). 6) Paste 7) Repeat as needed. This will preserve the text formatting and column and row sizes. HTH! Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 19, 2007 9:27 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Excel - Get sheet out of workbook I have a workbook with 4 sheets. I need to get those four sheets out into separate workbooks (one sheet per workbook). Other than copying the file four times and deleting the sheets not wanted, is there a way to save a specific sheet as a new workbook? John W. Colby Colby Consulting www.ColbyConsulting.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 Thu Jul 19 11:56:38 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 19 Jul 2007 18:56:38 +0200 Subject: [AccessD] Math in VBA Message-ID: Hi Mark That range is beyond the capacity of Currency, so your only chance without losing accuracy is probably to use a Variant with the subtype Decimal which can hold +/-79.228.162.514.264.337.593.543.950.335 with no decimals. Dim decNum As Variant decNum = CDec("9999999999999999") /gustav >>> markamatte at hotmail.com 19-07-2007 17:10 >>> Hello All, This is just a 'mild' form of encryption...but I need to use math(+-*/) with numbers up to 16 digits(9,999,999,999,999,999)... Is there any way to do this without losing accuracy in VBA? Thanks, Mark A. Matte From jwelz at hotmail.com Thu Jul 19 12:07:45 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 19 Jul 2007 11:07:45 -0600 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: You can perform math on the string just like you do it with pen and paper. For multiplication, start with the last digit of the 2nd number, multiply each digit of the first number, add the carries as you go and prepend the numbers to your string. Then take the 2nd last number, multiply each from the last digit, add the carries and then add the existing product to your current product, again as strings and add the carries, just like you would do it on a piece of paper. Keep going until you've gotten through all the digits. Division is a bit tougher because you need to truncate and then test with the multiplication whether you are above or below the number you're dividing into and the truncation can require you to try a lower digit if the additional digits put you over. All you really need to do is write an algorithm that works exactly the way you do it with pencil and paper. When we do multiplication, division, additon or subraction, we generally work with 2 'characters' at a time and that is fairly easy to mimic in VBA. There is no reason you couldn't do 10,000 digit numbers with complete precision. I've never seen such an algorithm but I'm sure they exist. If I needed it, I imagine I could write my own and get all four operators running in an hour or so. I'd start with an addition function; subraction is just adding a negative number and then multiplication and division would call the addition (and -) function with the intermediate solutions. I don't imagine it would be terribly fast, but 16 digits should be a piece of cake for a computer. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Mark A Matte" > >Hello All, > >This is just a 'mild' form of encryption...but I need to use math(+-*/) >with numbers up to 16 digits(9,999,999,999,999,999)... > >Is there any way to do this without losing accuracy in VBA? > >Thanks, > >Mark A. Matte _________________________________________________________________ New Windows Live Hotmail is here. Upgrade for free and get a better look. www.newhotmail.ca?icid=WLHMENCA150 From markamatte at hotmail.com Thu Jul 19 13:13:04 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 19 Jul 2007 18:13:04 +0000 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: Any ideas why ttt gives me an "OVERFLOW" error...but tt works just fine? Thanks, Mark Dim tt As Variant Dim ttt As Variant tt = CDec(36 ^ 10) ttt = CDec(36 * 36 * 36) >From: "Gustav Brock" >Reply-To: Access Developers discussion and problem >solving >To: >Subject: Re: [AccessD] Math in VBA >Date: Thu, 19 Jul 2007 18:56:38 +0200 > >Hi Mark > >That range is beyond the capacity of Currency, so your only chance without >losing accuracy is probably to use a Variant with the subtype Decimal which >can hold +/-79.228.162.514.264.337.593.543.950.335 with no decimals. > > Dim decNum As Variant > decNum = CDec("9999999999999999") > >/gustav > > >>> markamatte at hotmail.com 19-07-2007 17:10 >>> >Hello All, > >This is just a 'mild' form of encryption...but I need to use math(+-*/) >with >numbers up to 16 digits(9,999,999,999,999,999)... > >Is there any way to do this without losing accuracy in VBA? > >Thanks, > >Mark A. Matte > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://liveearth.msn.com From Gustav at cactus.dk Thu Jul 19 13:35:02 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 19 Jul 2007 20:35:02 +0200 Subject: [AccessD] Math in VBA Message-ID: Hi Mark Numbers may be handled as Integer if unknown. Specify as Long either: ttt = CDec(36& * 36& * 36&) or: Dim tt As Variant Dim ttt As Variant Dim d As Long d = 36 tt = CDec(d ^ 10) ttt = CDec(d * d * d) /gustav >>> markamatte at hotmail.com 19-07-2007 20:13 >>> Any ideas why ttt gives me an "OVERFLOW" error...but tt works just fine? Thanks, Mark Dim tt As Variant Dim ttt As Variant tt = CDec(36 ^ 10) ttt = CDec(36 * 36 * 36) >From: "Gustav Brock" >Reply-To: Access Developers discussion and problem >solving >To: >Subject: Re: [AccessD] Math in VBA >Date: Thu, 19 Jul 2007 18:56:38 +0200 > >Hi Mark > >That range is beyond the capacity of Currency, so your only chance without >losing accuracy is probably to use a Variant with the subtype Decimal which >can hold +/-79.228.162.514.264.337.593.543.950.335 with no decimals. > > Dim decNum As Variant > decNum = CDec("9999999999999999") > >/gustav > > >>> markamatte at hotmail.com 19-07-2007 17:10 >>> >Hello All, > >This is just a 'mild' form of encryption...but I need to use math(+-*/) with >numbers up to 16 digits(9,999,999,999,999,999)... > >Is there any way to do this without losing accuracy in VBA? > >Thanks, > >Mark A. Matte From cjeris at fas.harvard.edu Thu Jul 19 13:37:24 2007 From: cjeris at fas.harvard.edu (Christopher Jeris) Date: Thu, 19 Jul 2007 14:37:24 -0400 Subject: [AccessD] Math in VBA In-Reply-To: References: Message-ID: <469FAF64.60704@fas.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark A Matte wrote: > ttt = CDec(36 * 36 * 36) 6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up and kick someone in the head for leaving a 16-bit signed integer type in a program written after 1995. Try ttt = CDec(36) * CDec(36) * CDec(36) Also, be careful! > tt = CDec(36 ^ 10) That ^ is the _floating_point_ exponentiation operator! The result is not the integer 6^20; if you look at tt, you will see that it ends in a 0, which no power of 6 does. What you get there is the decimal conversion of the floating-point exponentiation. peace, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn69k5ICCNV0oGWARAjPHAJ9dz3+coNp2KVcjqwRK0FtFVFj9bACfW+oY JR0dThbFLOYR8UefedT5X48= =KxwX -----END PGP SIGNATURE----- From Patricia.O'Connor at otda.state.ny.us Thu Jul 19 13:39:58 2007 From: Patricia.O'Connor at otda.state.ny.us (O'Connor, Patricia (OTDA)) Date: Thu, 19 Jul 2007 14:39:58 -0400 Subject: [AccessD] OT: Excel - Get sheet out of workbook In-Reply-To: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> References: <20070719142726.B838FBF2B@smtp-auth.no-ip.com> Message-ID: <01DBAB52E30A9A4AB3D94EF8029EDBE8021BAF0D@EXCNYSM0A1AI.nysemail.nyenet> IN EXCEL 2K3 RIGHT click on the TAB --> select MOVE or COPY ----> TO BOOK --- > drop down select (NEW book) ---> check mark CREATE A COPY this will save original and make a new copy bingo new workbook with one sheet ************************************************** * Patricia O'Connor * Associate Computer Programmer Analyst * OTDA - BDMA * (W) mailto:Patricia.O'Connor at otda.state.ny.us * (w) mailto:aa1160 at nysemail.state.ny.us ************************************************** > -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 10:27 AM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Get sheet out of workbook > > I have a workbook with 4 sheets. I need to get those four > sheets out into separate workbooks (one sheet per workbook). > Other than copying the file four times and deleting the > sheets not wanted, is there a way to save a specific sheet as > a new workbook? > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > From Patricia.O'Connor at otda.state.ny.us Thu Jul 19 13:47:03 2007 From: Patricia.O'Connor at otda.state.ny.us (O'Connor, Patricia (OTDA)) Date: Thu, 19 Jul 2007 14:47:03 -0400 Subject: [AccessD] OT: Excel - Merge several cells In-Reply-To: <001b01c7ca14$efda5b50$0200a8c0@danwaters> References: <20070719143134.436C0BD57@smtp-auth.no-ip.com> <001b01c7ca14$efda5b50$0200a8c0@danwaters> Message-ID: <01DBAB52E30A9A4AB3D94EF8029EDBE8021BAF0E@EXCNYSM0A1AI.nysemail.nyenet> FYI Unless there is a way to change things If there is text or even formulas in the other cells those will be lost. Only what is in the 1st (leftmost) cell will remain. Example cell1: Hello 1, Cell2: Iam2, Cell3: =A+B. Only "Hello 1" will remain if you merge all 3 cells Patti ************************************************** * Patricia O'Connor * Associate Computer Programmer Analyst * OTDA - BDMA * (W) mailto:Patricia.O'Connor at otda.state.ny.us * (w) mailto:aa1160 at nysemail.state.ny.us ************************************************** > -------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Thursday, July 19, 2007 10:56 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] OT: Excel - Merge several cells > > There is a button immediately to the right of the right-hand > justify button. > It's called Merge and Center. > > 1) Select the cells you want to merge. (you might lose text) > 2) Push the button. > > That's it! > > Dan Waters > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, July 19, 2007 9:32 AM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] OT: Excel - Merge several cells > > I need to "merge" several cells to create one big cell. I > have seen this in spreadsheets but have no idea how to do it myself. > > Any clue? > > For example, a1,b1,c1 becomes one big cell, but a2,b2,c3 and > all the cells below them remain as they were. I need to put > text in a "header cell". > > TIA > > John W. Colby > Colby Consulting > www.ColbyConsulting.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 Thu Jul 19 14:25:42 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Thu, 19 Jul 2007 21:25:42 +0200 Subject: [AccessD] Math in VBA Message-ID: Hi Mark Chris is right. You have to keep the _numeric_ expressions within that of a Long if you wish to maintain accuracy. Thus: ? CDec(36 ^10) 3656158440062980 ? CDec(36 ^ 5) * CDec(36 ^ 5) 3656158440062976 because CDec(36 ^ 5) = 60466176. /gustav >>> cjeris at fas.harvard.edu 19-07-2007 20:37 >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark A Matte wrote: > ttt = CDec(36 * 36 * 36) 6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up and kick someone in the head for leaving a 16-bit signed integer type in a program written after 1995. Try ttt = CDec(36) * CDec(36) * CDec(36) Also, be careful! > tt = CDec(36 ^ 10) That ^ is the _floating_point_ exponentiation operator! The result is not the integer 6^20; if you look at tt, you will see that it ends in a 0, which no power of 6 does. What you get there is the decimal conversion of the floating-point exponentiation. peace, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn69k5ICCNV0oGWARAjPHAJ9dz3+coNp2KVcjqwRK0FtFVFj9bACfW+oY JR0dThbFLOYR8UefedT5X48= =KxwX -----END PGP SIGNATURE----- From robert at webedb.com Thu Jul 19 15:16:25 2007 From: robert at webedb.com (Robert L. Stewart) Date: Thu, 19 Jul 2007 15:16:25 -0500 Subject: [AccessD] Many to Many problem In-Reply-To: References: Message-ID: <200707192018.l6JKI5Sn018369@databaseadvisors.com> Kathryn, You can do it a couple of ways. You can have a subform with the collection that allows you to pick names that are associated with it and then enter the memo about it. (I would also have a date column there for when the memo was entered.) Or, you can have a subform on the names for so you can associate them with a collection and enter the memo there. Robert At 04:50 PM 7/18/2007, you wrote: >Date: Wed, 18 Jul 2007 11:13:53 -0700 >From: "Kathryn Bassett" >Subject: [AccessD] Many to Many problem part 2 - the tables and > question >To: "'Access Developers discussion and problem solving'" > >Message-ID: <006001c7c967$6661ac00$6401a8c0 at Kathryn> >Content-Type: text/plain; charset="windows-1250" > >Read part 1 first so you understand what the database is about. > >I have these three tables. > >tblCScollections > tblCScollectionID int(7) > tblCScollectionName varchar(50) >populated with the 11 collections we have at present. > >1 AckleyCarolyn >2 DunnPhillip >3 GardnerDavid >4 HilbigWalter >5 HollingsworthHarry >6 PriceRichard >7 SmithJeremiah >8 MillsVirginia >9 MooreWilburta >10 MottAnita >11 SmithConley > >tblCSnames > tblCSnamesID int(7) > tblCSlastname varchar(50) > tblCSfirstname varchar(50) >populated with > >1 Van Horn G. Armour >2 Bassett Kathryn >3 Day Win >4 Sullivan Stephanie >5 Gentry Doug >6 Lohmar Michael > >tblCSmemos > tblCScollectionID > tblCSnamesID > tblCSmemo >not populated at all at present > >Bottom line is that I now understand the two+middle table concept. >The inputting of data into the database is where I'm having a problem. > >The flat way I *had* been thinking (using spreadsheet analogy) is >that column A/B is lastname/firstname, column B is collectionID1, >column C is the memo for collectionID1 and the rest of the columns >are like columcs C/D for each collection. I put "true" in each >collection ID column that the name in row 2 (or 3 or 4) appears in. > >Now if Win Day (nameID=3) was ONLY in one collection, then a >dropdown box of the collection names would work. But since nameID=3 >is in multiple collections and may or may not have a memo, I'm not >clear on how to do the input. > >Help? From BarbaraRyan at cox.net Thu Jul 19 18:50:35 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Thu, 19 Jul 2007 19:50:35 -0400 Subject: [AccessD] One-to-One relationships Message-ID: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? Thanks, Barb Ryan From cfoust at infostatsystems.com Thu Jul 19 19:01:05 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 19 Jul 2007 17:01:05 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: Definitely, IMO, especially in databases where you may have different kinds of customers. For example, a business and a non-profit and an individual and a family group could all be customers, but would have differing kinds of information. Using one-to-one relationships, you could have a single Customer table that had the minimum information that would be collected on all customers, regardless of type. Then you could have a separate table for Organization and one for Persons. The PK in each of those tables would be inherited from the Customer table. This would also allow you to have other tables with common information hanging off the customer table instead of the Organization or Persons table. You might want to hang the Address table off Customers, for example, since addresses are fairly consistent. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan Sent: Thursday, July 19, 2007 4:51 PM To: Access List Subject: [AccessD] One-to-One relationships Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? Thanks, Barb Ryan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Thu Jul 19 19:09:15 2007 From: miscellany at mvps.org (Steve Schapel) Date: Fri, 20 Jul 2007 12:09:15 +1200 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: <469FFD2B.5050201@mvps.org> Barb, Not in the example you gave, no. Given that you will be recording sex, address, phone for all, or almost all, of the customers. The main use for one-to-one relationships is in a sub-typing scenario. This is where you have data where there are some data in common for all/most records, but there are also fields required specific to certain categories of the main data. Regards Steve Barbara Ryan wrote: > Is there any purpose/advantage in creating a one-to-one relationship > in a database (e.g., CustomerId and CustomerName in one table and all > the other customer data (e.g., sex, address, phone, etc) in another > table? From martyconnelly at shaw.ca Thu Jul 19 19:31:00 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 19 Jul 2007 17:31:00 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: <46A00244.6080609@shaw.ca> This quick article might explain http://www.allenbrowne.com/AppHuman.html Barbara Ryan wrote: >Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? > >Thanks, >Barb Ryan > > -- Marty Connelly Victoria, B.C. Canada From jwcolby at colbyconsulting.com Thu Jul 19 20:41:48 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 19 Jul 2007 21:41:48 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: <20070720014150.891B8BC7A@smtp-auth.no-ip.com> In your example, maybe, maybe not. I have a database where there is a claim table and three different "extension" tables which are 1 to 1 with the claim table. TblClaimSTD is for short term disability claims, and stores information specific to short term claims. There is also a (you guessed it) tblClaimLTD for long term disability and stores all the claim information specific to long term claims. There is a third table tblWP or waiver of premium where claim waiver of premium information is stored. In all these cases there is a rather large table with information that is in every claim, and then one of those three "extension" tables with information about one of those three specific types of claims. 1-1 tables require special handling in entering data as well as displaying / reporting the data. Whether it is worth doing is a question that bears asking in any specific case. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan Sent: Thursday, July 19, 2007 7:51 PM To: Access List Subject: [AccessD] One-to-One relationships Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? Thanks, Barb Ryan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From clh at christopherhawkins.com Fri Jul 20 01:45:30 2007 From: clh at christopherhawkins.com (Christopher Hawkins) Date: Fri, 20 Jul 2007 00:45:30 -0600 Subject: [AccessD] ASP, anyone? Message-ID: <0efb6bb432b54680bdb48a3db0aa1772@mail1.gearhost.com> I know we have a vb.net mailing list...is there an asp or asp.net mailing list as well? Or am I the only one who spends a significant amount of time working with asp here? -Christopher Hawkins- From ssharkins at setel.com Fri Jul 20 07:45:34 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 08:45:34 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> Message-ID: <006501c7cacb$f129aa80$94b82ad1@SusanOne> Yes, if it has a purpose. A one-to-one relationship almost always flows from need rather from the data itself. If you need to force a one-to-one, I'd say do it. However, if there's no business rule saying, "there can be only one..." it might be unnecessary, even if the data is presenting that picture right now. Listen to the data. Susan H. Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? From jwcolby at colbyconsulting.com Fri Jul 20 08:14:07 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 09:14:07 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <006501c7cacb$f129aa80$94b82ad1@SusanOne> Message-ID: <20070720131410.771FDBEC3@smtp-auth.no-ip.com> >Listen to the data. And may the force be with you... ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 20, 2007 8:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Yes, if it has a purpose. A one-to-one relationship almost always flows from need rather from the data itself. If you need to force a one-to-one, I'd say do it. However, if there's no business rule saying, "there can be only one..." it might be unnecessary, even if the data is presenting that picture right now. Listen to the data. Susan H. Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? -- 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 Jul 20 08:24:08 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 09:24:08 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <006501c7cacb$f129aa80$94b82ad1@SusanOne> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> <006501c7cacb$f129aa80$94b82ad1@SusanOne> Message-ID: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> I would respectfully suggest that you're overlooking something in your analysis, Susan, but to observe it you need millions of rows in the given table. But suppose that you have a table called Customers, which as previously suggested in this thread might include both corporations and persons. The first rule of database development is performance, above all other considerations. Therefore one ought to identify the columns of immediate interest (CustomerID, CustomerName, etc.) and store those in a single table, pushing all the other attributes to one or more related tables with a 1:1 relationship. This way, I can search a small table with multiple indexes very quickly, and not bother with fetching the rest of the data until you explicitly request it, at which point it would be a lightning-quick sproc that receives a CustomerID and sends back the rest of the data. If you really want to push the performance button, then you won't return a rowset either. Instead you'll declare as many parameters as you have columns of interest, and declare them all Output parameters. When you want exactly one record, that's the quickest method. I hope I didn't obscure the point here. The point is what I call the Sally Rand principle. (You might have to be older than even I to understand the reference -- she was a famous stripper, back when stripping meant that you still retained most of your clothes.) Her point was, show them as little as possible to still maintain their interest. That's my motto in terms of database design. Never open an entire table. Show them only enough to pique their curiosity, as it were. On 7/20/07, Susan Harkins wrote: > > Yes, if it has a purpose. A one-to-one relationship almost always flows > from > need rather from the data itself. If you need to force a one-to-one, I'd > say > do it. However, if there's no business rule saying, "there can be only > one..." it might be unnecessary, even if the data is presenting that > picture > right now. Listen to the data. > > Susan H. > > Is there any purpose/advantage in creating a one-to-one relationship in a > database (e.g., CustomerId and CustomerName in one table and all the other > customer data (e.g., sex, address, phone, etc) in another table? > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From markamatte at hotmail.com Fri Jul 20 08:32:07 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 20 Jul 2007 13:32:07 +0000 Subject: [AccessD] Math in VBA In-Reply-To: Message-ID: Thanks Everyone, I ended up using a loop to get my powers...before I was the power by 1 for each record...now I added a new loop to get the actual number if you calculated out to the nth power. I was in the quadrillions when I finished. Thanks Again, Mark Power = Power - 1 PowerNum = CDec(36) For PNLoop = 1 To Power - 1 PowerNum = CDec(PowerNum * CDec(36)) Next >From: "Gustav Brock" >Reply-To: Access Developers discussion and problem >solving >To: >Subject: Re: [AccessD] Math in VBA >Date: Thu, 19 Jul 2007 21:25:42 +0200 > >Hi Mark > >Chris is right. You have to keep the _numeric_ expressions within that of a >Long if you wish to maintain accuracy. > >Thus: >? CDec(36 ^10) > 3656158440062980 >? CDec(36 ^ 5) * CDec(36 ^ 5) > 3656158440062976 > >because CDec(36 ^ 5) = 60466176. > >/gustav > > >>> cjeris at fas.harvard.edu 19-07-2007 20:37 >>> >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Mark A Matte wrote: > > ttt = CDec(36 * 36 * 36) > >6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up >and kick someone in the head for leaving a 16-bit signed integer type in >a program written after 1995. > >Try >ttt = CDec(36) * CDec(36) * CDec(36) > >Also, be careful! > > tt = CDec(36 ^ 10) > >That ^ is the _floating_point_ exponentiation operator! The result is >not the integer 6^20; if you look at tt, you will see that it ends in a >0, which no power of 6 does. What you get there is the decimal >conversion of the floating-point exponentiation. > >peace, Chris Jeris > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.6 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFGn69k5ICCNV0oGWARAjPHAJ9dz3+coNp2KVcjqwRK0FtFVFj9bACfW+oY >JR0dThbFLOYR8UefedT5X48= >=KxwX >-----END PGP SIGNATURE----- > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From Jim.Hale at FleetPride.com Fri Jul 20 08:37:49 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Fri, 20 Jul 2007 08:37:49 -0500 Subject: [AccessD] One-to-One relationships In-Reply-To: <006501c7cacb$f129aa80$94b82ad1@SusanOne> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> <006501c7cacb$f129aa80$94b82ad1@SusanOne> Message-ID: Or hire a Data Whisperer to do it for you :-) Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 20, 2007 7:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Yes, if it has a purpose. A one-to-one relationship almost always flows from need rather from the data itself. If you need to force a one-to-one, I'd say do it. However, if there's no business rule saying, "there can be only one..." it might be unnecessary, even if the data is presenting that picture right now. Listen to the data. Susan H. Is there any purpose/advantage in creating a one-to-one relationship in a database (e.g., CustomerId and CustomerName in one table and all the other customer data (e.g., sex, address, phone, etc) in another table? -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From jwcolby at colbyconsulting.com Fri Jul 20 08:45:06 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 09:45:06 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> Message-ID: <20070720134509.05E67BC79@smtp-auth.no-ip.com> Arthur, You've been on about strippers as long as I've known you. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 9:24 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships I would respectfully suggest that you're overlooking something in your analysis, Susan, but to observe it you need millions of rows in the given table. But suppose that you have a table called Customers, which as previously suggested in this thread might include both corporations and persons. The first rule of database development is performance, above all other considerations. Therefore one ought to identify the columns of immediate interest (CustomerID, CustomerName, etc.) and store those in a single table, pushing all the other attributes to one or more related tables with a 1:1 relationship. This way, I can search a small table with multiple indexes very quickly, and not bother with fetching the rest of the data until you explicitly request it, at which point it would be a lightning-quick sproc that receives a CustomerID and sends back the rest of the data. If you really want to push the performance button, then you won't return a rowset either. Instead you'll declare as many parameters as you have columns of interest, and declare them all Output parameters. When you want exactly one record, that's the quickest method. I hope I didn't obscure the point here. The point is what I call the Sally Rand principle. (You might have to be older than even I to understand the reference -- she was a famous stripper, back when stripping meant that you still retained most of your clothes.) Her point was, show them as little as possible to still maintain their interest. That's my motto in terms of database design. Never open an entire table. Show them only enough to pique their curiosity, as it were. From fuller.artful at gmail.com Fri Jul 20 08:50:16 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 09:50:16 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720134509.05E67BC79@smtp-auth.no-ip.com> References: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> <20070720134509.05E67BC79@smtp-auth.no-ip.com> Message-ID: <29f585dd0707200650p694efc6cxb3ff56e7b7606954@mail.gmail.com> LOL. On 7/20/07, jwcolby wrote: > > Arthur, > > You've been on about strippers as long as I've known you. > > ;-) > From john at winhaven.net Fri Jul 20 10:00:10 2007 From: john at winhaven.net (John Bartow) Date: Fri, 20 Jul 2007 10:00:10 -0500 Subject: [AccessD] ASP, anyone? In-Reply-To: <0efb6bb432b54680bdb48a3db0aa1772@mail1.gearhost.com> References: <0efb6bb432b54680bdb48a3db0aa1772@mail1.gearhost.com> Message-ID: <00f701c7cade$ac568410$6402a8c0@ScuzzPaq> Hi Christopher, Awhile back we asked the list population to email if they would like an ASP specific list to be setup. The response was low. However, if we have more people interested in this now we certainly could set up an ASP specific list. If any of you are interested in having a DBA-ASP list setup o discuss ASP related issues please let me know. John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher Hawkins Sent: Friday, July 20, 2007 1:46 AM To: accessd at databaseadvisors.com Subject: [AccessD] ASP, anyone? I know we have a vb.net mailing list...is there an asp or asp.net mailing list as well? Or am I the only one who spends a significant amount of time working with asp here? -Christopher Hawkins- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Fri Jul 20 10:09:25 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 08:09:25 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35><006501c7cacb$f129aa80$94b82ad1@SusanOne> <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> Message-ID: Actually, she was a fan dancer, which is different from a stripper, since they start out without much on and wave the fans around to expose bits at a time. She was quite famous in her time. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 6:24 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships I would respectfully suggest that you're overlooking something in your analysis, Susan, but to observe it you need millions of rows in the given table. But suppose that you have a table called Customers, which as previously suggested in this thread might include both corporations and persons. The first rule of database development is performance, above all other considerations. Therefore one ought to identify the columns of immediate interest (CustomerID, CustomerName, etc.) and store those in a single table, pushing all the other attributes to one or more related tables with a 1:1 relationship. This way, I can search a small table with multiple indexes very quickly, and not bother with fetching the rest of the data until you explicitly request it, at which point it would be a lightning-quick sproc that receives a CustomerID and sends back the rest of the data. If you really want to push the performance button, then you won't return a rowset either. Instead you'll declare as many parameters as you have columns of interest, and declare them all Output parameters. When you want exactly one record, that's the quickest method. I hope I didn't obscure the point here. The point is what I call the Sally Rand principle. (You might have to be older than even I to understand the reference -- she was a famous stripper, back when stripping meant that you still retained most of your clothes.) Her point was, show them as little as possible to still maintain their interest. That's my motto in terms of database design. Never open an entire table. Show them only enough to pique their curiosity, as it were. On 7/20/07, Susan Harkins wrote: > > Yes, if it has a purpose. A one-to-one relationship almost always > flows from need rather from the data itself. If you need to force a > one-to-one, I'd say do it. However, if there's no business rule > saying, "there can be only one..." it might be unnecessary, even if > the data is presenting that picture right now. Listen to the data. > > Susan H. > > Is there any purpose/advantage in creating a one-to-one relationship > in a database (e.g., CustomerId and CustomerName in one table and all > the other customer data (e.g., sex, address, phone, etc) in another table? > > > -- > 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 ebarro at verizon.net Fri Jul 20 10:18:27 2007 From: ebarro at verizon.net (Eric Barro) Date: Fri, 20 Jul 2007 08:18:27 -0700 Subject: [AccessD] ASP, anyone? In-Reply-To: <00f701c7cade$ac568410$6402a8c0@ScuzzPaq> Message-ID: <0JLH00L83H672T58@vms042.mailsrvcs.net> I develop exclusively in ASP/ASP.NET and I would be interested in an ASP specific list as well. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Friday, July 20, 2007 8:00 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] ASP, anyone? Hi Christopher, Awhile back we asked the list population to email if they would like an ASP specific list to be setup. The response was low. However, if we have more people interested in this now we certainly could set up an ASP specific list. If any of you are interested in having a DBA-ASP list setup o discuss ASP related issues please let me know. John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher Hawkins Sent: Friday, July 20, 2007 1:46 AM To: accessd at databaseadvisors.com Subject: [AccessD] ASP, anyone? I know we have a vb.net mailing list...is there an asp or asp.net mailing list as well? Or am I the only one who spends a significant amount of time working with asp here? -Christopher Hawkins- From fuller.artful at gmail.com Fri Jul 20 10:21:31 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 11:21:31 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> <006501c7cacb$f129aa80$94b82ad1@SusanOne> <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> Message-ID: <29f585dd0707200821i10dd90a2jdc33207d09a1c232@mail.gmail.com> Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to expose > bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and store > those in a single table, pushing all the other attributes to one or more > related tables with a 1:1 relationship. This way, I can search a small > table with multiple indexes very quickly, and not bother with fetching > the rest of the data until you explicitly request it, at which point it > would be a lightning-quick sproc that receives a CustomerID and sends > back the rest of the data. If you really want to push the performance > button, then you won't return a rowset either. Instead you'll declare as > many parameters as you have columns of interest, and declare them all > Output parameters. When you want exactly one record, that's the quickest > method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her point > was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and all > > the other customer data (e.g., sex, address, phone, etc) in another > table? > > > > > > -- > > 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 cfoust at infostatsystems.com Fri Jul 20 10:24:50 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 08:24:50 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707200821i10dd90a2jdc33207d09a1c232@mail.gmail.com> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35><006501c7cacb$f129aa80$94b82ad1@SusanOne><29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> <29f585dd0707200821i10dd90a2jdc33207d09a1c232@mail.gmail.com> Message-ID: What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 jwcolby at colbyconsulting.com Fri Jul 20 10:39:24 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 11:39:24 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: Message-ID: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 Jim.Hale at FleetPride.com Fri Jul 20 10:47:14 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Fri, 20 Jul 2007 10:47:14 -0500 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: Because developers are used to exposing different objects one at a time? JH -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 10:39 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From john at winhaven.net Fri Jul 20 10:01:37 2007 From: john at winhaven.net (John Bartow) Date: Fri, 20 Jul 2007 10:01:37 -0500 Subject: [AccessD] Request for new DBA List to discuss specific subjects Message-ID: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> If anyone has a request for a new DBA list to discuss a specific subject please email me directly. Also, please leave this subject line in tact so I can sort these messages into a new email folder. Thanks, John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Fri Jul 20 10:48:29 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 20 Jul 2007 08:48:29 -0700 Subject: [AccessD] OT: Deal of the Day Message-ID: <004801c7cae5$6b62d830$0301a8c0@HAL9005> Today at Fry's: GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... $149.00. How do they make any money on this? Rocky From max at sherman.org.uk Fri Jul 20 10:54:54 2007 From: max at sherman.org.uk (Max Sherman) Date: Fri, 20 Jul 2007 16:54:54 +0100 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: <014c01c7cae6$54a421c0$8119fea9@LTVM> Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 4:39 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 cfoust at infostatsystems.com Fri Jul 20 10:51:20 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 08:51:20 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: I've always been interested in theater and stage productions. Sally Rand performed in some of Billy Rose's productions. I think she even danced at a World's Fair. In any event I saw a publicity photo of her once, with a thin strip of Sally showing between two enormouse ostrich feather fans. I assume she wasn't ticklish! LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 8:39 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 cfoust at infostatsystems.com Fri Jul 20 10:51:53 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 08:51:53 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: ROTFLMAO Right!! Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim Sent: Friday, July 20, 2007 8:47 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Because developers are used to exposing different objects one at a time? JH -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 10:39 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. -- 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 Jul 20 10:58:15 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 11:58:15 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> Message-ID: <29f585dd0707200858w71a2f30evf7d4a2f2af5e38d9@mail.gmail.com> This is becoming way too sick even for my admittedly deviant interests. But hats off to Charlotte for The Mrs. Henderson's phrase, and I don't think I'll bother finding a rhyme for Charlotte. I guess it must be Friday! On 7/20/07, Hale, Jim wrote: > > > Because developers are used to exposing different objects one at a time? > JH > From cfoust at infostatsystems.com Fri Jul 20 11:00:33 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 09:00:33 -0700 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <014c01c7cae6$54a421c0$8119fea9@LTVM> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> <014c01c7cae6$54a421c0$8119fea9@LTVM> Message-ID: Traditionally, Fridays are very relaxed days with lots of nonsense. Developers can only be serious for a limited period of time before going totally insane, so we need at least one day a week to blow off some steam. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 4:39 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 fuller.artful at gmail.com Fri Jul 20 11:27:01 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 12:27:01 -0400 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com> <014c01c7cae6$54a421c0$8119fea9@LTVM> Message-ID: <29f585dd0707200927j4311173ch9c7c2669e2f77325@mail.gmail.com> Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before going > totally insane, so we need at least one day a week to blow off some > steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Friday, July 20, 2007 4:39 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Charlotte, and how do you know all this? I can understand Arthur having > this prurient interest, but you? > > Inquiring minds want to know. ;-) > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte > Foust > Sent: Friday, July 20, 2007 11:25 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > What, "Mrs Henderson Presents" wasn't international enough for you? LOL > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Friday, July 20, 2007 8:22 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > Wow! I used the term "stripper" because I deferred to the international > character of this list, but you're entirely correct! Applause to you > from here, Charlotte. You are sooo correct. > > On 7/20/07, Charlotte Foust wrote: > > > > Actually, she was a fan dancer, which is different from a stripper, > > since they start out without much on and wave the fans around to > > expose bits at a time. She was quite famous in her time. > > > > Charlotte Foust > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > > Fuller > > Sent: Friday, July 20, 2007 6:24 AM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] One-to-One relationships > > > > I would respectfully suggest that you're overlooking something in your > > > analysis, Susan, but to observe it you need millions of rows in the > > given table. But suppose that you have a table called Customers, which > > > as previously suggested in this thread might include both corporations > > > and persons. The first rule of database development is performance, > > above all other considerations. Therefore one ought to identify the > > columns of immediate interest (CustomerID, CustomerName, etc.) and > > store those in a single table, pushing all the other attributes to one > > > or more related tables with a 1:1 relationship. This way, I can search > > > a small table with multiple indexes very quickly, and not bother with > > fetching the rest of the data until you explicitly request it, at > > which point it would be a lightning-quick sproc that receives a > > CustomerID and sends back the rest of the data. If you really want to > > push the performance button, then you won't return a rowset either. > > Instead you'll declare as many parameters as you have columns of > > interest, and declare them all Output parameters. When you want > > exactly one record, that's the quickest method. > > > > I hope I didn't obscure the point here. The point is what I call the > > Sally Rand principle. (You might have to be older than even I to > > understand the reference -- she was a famous stripper, back when > > stripping meant that you still retained most of your clothes.) Her > > point was, show them as little as possible to still maintain their > interest. > > That's my motto in terms of database design. Never open an entire > table. > > Show them only enough to pique their curiosity, as it were. > > > > On 7/20/07, Susan Harkins wrote: > > > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > > flows from need rather from the data itself. If you need to force a > > > one-to-one, I'd say do it. However, if there's no business rule > > > saying, "there can be only one..." it might be unnecessary, even if > > > the data is presenting that picture right now. Listen to the data. > > > > > > Susan H. > > > > > > Is there any purpose/advantage in creating a one-to-one relationship > > > > in a database (e.g., CustomerId and CustomerName in one table and > > > all the other customer data (e.g., sex, address, phone, etc) in > > > another > > table? > > > > > > > > > -- > > > 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 jmhecht at earthlink.net Fri Jul 20 11:45:06 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Fri, 20 Jul 2007 09:45:06 -0700 (GMT-07:00) Subject: [AccessD] OT: Deal of the Day Message-ID: <21470712.1184949906343.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> cause CompUSA aint around no more ? Joe Ex compUSA employee -----Original Message----- >From: Rocky Smolin at Beach Access Software >Sent: Jul 20, 2007 8:48 AM >To: dba-ot at databaseadvisors.com, 'Access Developers discussion and problem solving' >Subject: [AccessD] OT: Deal of the Day > >Today at Fry's: > >GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB >RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... > > >$149.00. > > >How do they make any money on this? > > >Rocky > > > > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From JHewson at karta.com Fri Jul 20 11:53:30 2007 From: JHewson at karta.com (Jim Hewson) Date: Fri, 20 Jul 2007 11:53:30 -0500 Subject: [AccessD] OT: Deal of the Day In-Reply-To: <21470712.1184949906343.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> References: <21470712.1184949906343.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Message-ID: We have CompUSA but NO Fry's. Jim jhewson at karta.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe Hecht Sent: Friday, July 20, 2007 11:45 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] OT: Deal of the Day cause CompUSA aint around no more ? Joe Ex compUSA employee -----Original Message----- >From: Rocky Smolin at Beach Access Software >Sent: Jul 20, 2007 8:48 AM >To: dba-ot at databaseadvisors.com, 'Access Developers discussion and problem solving' >Subject: [AccessD] OT: Deal of the Day > >Today at Fry's: > >GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB >RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... > > >$149.00. > > >How do they make any money on this? > > >Rocky > > > > > > >-- >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 max at sherman.org.uk Fri Jul 20 12:00:35 2007 From: max at sherman.org.uk (Max Sherman) Date: Fri, 20 Jul 2007 18:00:35 +0100 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <29f585dd0707200927j4311173ch9c7c2669e2f77325@mail.gmail.com> References: <20070720153927.ADD3BBE5E@smtp-auth.no-ip.com><014c01c7cae6$54a421c0$8119fea9@LTVM> <29f585dd0707200927j4311173ch9c7c2669e2f77325@mail.gmail.com> Message-ID: <015901c7caef$810bb0d0$8119fea9@LTVM> Thank you, I would appreciate that. I also appreciate the many useful contributions thay you all put in. Max Ps. I have been subscribing to Peach List for some 9 maybe more years now, so I do understand how it works. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 5:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before > going totally insane, so we need at least one day a week to blow off > some steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Friday, July 20, 2007 4:39 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Charlotte, and how do you know all this? I can understand Arthur > having this prurient interest, but you? > > Inquiring minds want to know. ;-) > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte > Foust > Sent: Friday, July 20, 2007 11:25 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > What, "Mrs Henderson Presents" wasn't international enough for you? > LOL > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 8:22 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > Wow! I used the term "stripper" because I deferred to the > international character of this list, but you're entirely correct! > Applause to you from here, Charlotte. You are sooo correct. > > On 7/20/07, Charlotte Foust wrote: > > > > Actually, she was a fan dancer, which is different from a stripper, > > since they start out without much on and wave the fans around to > > expose bits at a time. She was quite famous in her time. > > > > Charlotte Foust > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > > Fuller > > Sent: Friday, July 20, 2007 6:24 AM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] One-to-One relationships > > > > I would respectfully suggest that you're overlooking something in > > your > > > analysis, Susan, but to observe it you need millions of rows in the > > given table. But suppose that you have a table called Customers, > > which > > > as previously suggested in this thread might include both > > corporations > > > and persons. The first rule of database development is performance, > > above all other considerations. Therefore one ought to identify the > > columns of immediate interest (CustomerID, CustomerName, etc.) and > > store those in a single table, pushing all the other attributes to > > one > > > or more related tables with a 1:1 relationship. This way, I can > > search > > > a small table with multiple indexes very quickly, and not bother > > with fetching the rest of the data until you explicitly request it, > > at which point it would be a lightning-quick sproc that receives a > > CustomerID and sends back the rest of the data. If you really want > > to push the performance button, then you won't return a rowset either. > > Instead you'll declare as many parameters as you have columns of > > interest, and declare them all Output parameters. When you want > > exactly one record, that's the quickest method. > > > > I hope I didn't obscure the point here. The point is what I call the > > Sally Rand principle. (You might have to be older than even I to > > understand the reference -- she was a famous stripper, back when > > stripping meant that you still retained most of your clothes.) Her > > point was, show them as little as possible to still maintain their > interest. > > That's my motto in terms of database design. Never open an entire > table. > > Show them only enough to pique their curiosity, as it were. > > > > On 7/20/07, Susan Harkins wrote: > > > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > > flows from need rather from the data itself. If you need to force > > > a one-to-one, I'd say do it. However, if there's no business rule > > > saying, "there can be only one..." it might be unnecessary, even > > > if the data is presenting that picture right now. Listen to the data. > > > > > > Susan H. > > > > > > Is there any purpose/advantage in creating a one-to-one > > > relationship > > > > in a database (e.g., CustomerId and CustomerName in one table and > > > all the other customer data (e.g., sex, address, phone, etc) in > > > another > > table? > > > > > > > > > -- > > > 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 rockysmolin at bchacc.com Fri Jul 20 12:01:52 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 20 Jul 2007 10:01:52 -0700 Subject: [AccessD] One-to-One relationships In-Reply-To: <014c01c7cae6$54a421c0$8119fea9@LTVM> Message-ID: <005601c7caef$abd0f0a0$0301a8c0@HAL9005> It's OT Friday. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 4:39 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Charlotte, and how do you know all this? I can understand Arthur having this prurient interest, but you? Inquiring minds want to know. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:25 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships What, "Mrs Henderson Presents" wasn't international enough for you? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 8:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships Wow! I used the term "stripper" because I deferred to the international character of this list, but you're entirely correct! Applause to you from here, Charlotte. You are sooo correct. On 7/20/07, Charlotte Foust wrote: > > Actually, she was a fan dancer, which is different from a stripper, > since they start out without much on and wave the fans around to > expose bits at a time. She was quite famous in her time. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur > Fuller > Sent: Friday, July 20, 2007 6:24 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] One-to-One relationships > > I would respectfully suggest that you're overlooking something in your > analysis, Susan, but to observe it you need millions of rows in the > given table. But suppose that you have a table called Customers, which > as previously suggested in this thread might include both corporations > and persons. The first rule of database development is performance, > above all other considerations. Therefore one ought to identify the > columns of immediate interest (CustomerID, CustomerName, etc.) and > store those in a single table, pushing all the other attributes to one > or more related tables with a 1:1 relationship. This way, I can search > a small table with multiple indexes very quickly, and not bother with > fetching the rest of the data until you explicitly request it, at > which point it would be a lightning-quick sproc that receives a > CustomerID and sends back the rest of the data. If you really want to > push the performance button, then you won't return a rowset either. > Instead you'll declare as many parameters as you have columns of > interest, and declare them all Output parameters. When you want > exactly one record, that's the quickest method. > > I hope I didn't obscure the point here. The point is what I call the > Sally Rand principle. (You might have to be older than even I to > understand the reference -- she was a famous stripper, back when > stripping meant that you still retained most of your clothes.) Her > point was, show them as little as possible to still maintain their interest. > That's my motto in terms of database design. Never open an entire table. > Show them only enough to pique their curiosity, as it were. > > On 7/20/07, Susan Harkins wrote: > > > > Yes, if it has a purpose. A one-to-one relationship almost always > > flows from need rather from the data itself. If you need to force a > > one-to-one, I'd say do it. However, if there's no business rule > > saying, "there can be only one..." it might be unnecessary, even if > > the data is presenting that picture right now. Listen to the data. > > > > Susan H. > > > > Is there any purpose/advantage in creating a one-to-one relationship > > in a database (e.g., CustomerId and CustomerName in one table and > > all the other customer data (e.g., sex, address, phone, etc) in > > another > table? > > > > > > -- > > 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 7/19/2007 6:10 PM From DWUTKA at Marlow.com Fri Jul 20 12:09:46 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Fri, 20 Jul 2007 12:09:46 -0500 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: Message-ID: I wish I would have known this earlier...... is there hope of recovery if you've gone totally insane? ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:01 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Traditionally, Fridays are very relaxed days with lots of nonsense. Developers can only be serious for a limited period of time before going totally insane, so we need at least one day a week to blow off some steam. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwcolby at colbyconsulting.com Fri Jul 20 12:31:13 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 13:31:13 -0400 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <015901c7caef$810bb0d0$8119fea9@LTVM> Message-ID: <20070720173116.542ABBDDD@smtp-auth.no-ip.com> BTW Max, this is an Access list. I am not yanking your chain or anything, I just noticed that you mentioned "sticking to VBA". We do have a VB list as well which (other than OT Friday) pretty much sticks to VBA and VB.Net. I am going to make an assumption that you are new to our list and welcome you aboard. I'll also take this opportunity to explain that we are a community as well as a "list". There are a TON of developers who have been on this list for 10 years or more. As such we do tend to get a little more personal than some other lists. We are friends as well as developers. We have people assigned to police the list should things get too out of hand and we mostly leave it up to them to do the policing. But we do not run as tight a ship as you might be accustomed to on other lists and we like it that way. You are of course welcomed to the list, welcomed to contribute and hang out, but if you expect this list to be "just the facts ma'am", I can tell you up front you are in the wrong place. So welcome to the list and I hope you enjoy the community as much as you enjoy the immense knowledge base that our members bring to the list. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 1:01 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT Thank you, I would appreciate that. I also appreciate the many useful contributions thay you all put in. Max Ps. I have been subscribing to Peach List for some 9 maybe more years now, so I do understand how it works. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 5:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before > going totally insane, so we need at least one day a week to blow off > some steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max From ebarro at verizon.net Fri Jul 20 13:05:32 2007 From: ebarro at verizon.net (Eric Barro) Date: Fri, 20 Jul 2007 11:05:32 -0700 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <20070720173116.542ABBDDD@smtp-auth.no-ip.com> Message-ID: <0JLH00119OX00LPC@vms044.mailsrvcs.net> And this is what makes this list a community that stands above the rest. Most started off with Access and have since then moved on to other technologies such as .NET, SQL, Sharepoint, heck even Linux-based technologies. And those people still stick around because this list covers more than just straight "Microsoft Access-specific" topics. Otherwise you'd be better off going to Google to find answers... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 10:31 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT BTW Max, this is an Access list. I am not yanking your chain or anything, I just noticed that you mentioned "sticking to VBA". We do have a VB list as well which (other than OT Friday) pretty much sticks to VBA and VB.Net. I am going to make an assumption that you are new to our list and welcome you aboard. I'll also take this opportunity to explain that we are a community as well as a "list". There are a TON of developers who have been on this list for 10 years or more. As such we do tend to get a little more personal than some other lists. We are friends as well as developers. We have people assigned to police the list should things get too out of hand and we mostly leave it up to them to do the policing. But we do not run as tight a ship as you might be accustomed to on other lists and we like it that way. You are of course welcomed to the list, welcomed to contribute and hang out, but if you expect this list to be "just the facts ma'am", I can tell you up front you are in the wrong place. So welcome to the list and I hope you enjoy the community as much as you enjoy the immense knowledge base that our members bring to the list. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 1:01 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT Thank you, I would appreciate that. I also appreciate the many useful contributions thay you all put in. Max Ps. I have been subscribing to Peach List for some 9 maybe more years now, so I do understand how it works. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 5:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before > going totally insane, so we need at least one day a week to blow off > some steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Fri Jul 20 13:21:12 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 14:21:12 -0400 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: Message-ID: <20070720182115.3FF0FBF54@smtp-auth.no-ip.com> In your case? No. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Friday, July 20, 2007 1:10 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT I wish I would have known this earlier...... is there hope of recovery if you've gone totally insane? ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:01 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Traditionally, Fridays are very relaxed days with lots of nonsense. Developers can only be serious for a limited period of time before going totally insane, so we need at least one day a week to blow off some steam. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From max at sherman.org.uk Fri Jul 20 13:23:35 2007 From: max at sherman.org.uk (Max Sherman) Date: Fri, 20 Jul 2007 19:23:35 +0100 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <20070720173116.542ABBDDD@smtp-auth.no-ip.com> References: <015901c7caef$810bb0d0$8119fea9@LTVM> <20070720173116.542ABBDDD@smtp-auth.no-ip.com> Message-ID: <016901c7cafb$16d79e20$8119fea9@LTVM> >>There are a TON of developers who have been on this list for 10 years or more Yes, I am one of them. >> VBA Only said in a generalised sense, not to be restrictive. Perhaps I should have said "Access" >>we mostly leave it up to them to do the policing. Perhaps they need to check more often. Certainly if I were one of the scrutinisers, I would have spoken up by now. >>tight a ship as you might be accustomed to on other lists I don't need a tight ship. Some of the OT posting are very helpful and often informative - some amusing. BUT "one-liners" bouncing back and forward between a few people is just too much. Whatever your reasons, please remember what the purpose of this list is. It is there, as are all the other lists, to assist people and share information. There are plenty of joke lists around and if people feel a need then perhaps they could have a sub-list for those that feel the need to bounce these sort of things between them. What you are forgetting is that there are many people ("the silent majority") who just, like me I would suggest, just groan and hit the delete key. All I am attempting to do, is perhaps, respectfully, remind people that even on OT Friday, there is a limit to what should be acceptable. And this nonsense bouncing back and forward about strippers and fan dancers is just one posting to many for me - and that is after 10 odd years! Repartee, for my part, is not required. I have no doubt that you and your friend will come back on this, but before you do please remember that none of my comments are made as a personal criticism, but only as a reminder that there are others out there who will also be receiving your postings. Whilst posters might feel that they have made the "comment of the century", others would not view it as so. Also, remember, like many others, that I am very appreciative of the much help that all the contributors have given (freely) over the years. I have had much help and for that I am very grateful. I do not post very often, but I read and often take on board the good ideas that come off the list. Thank you all for that. Max -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 6:31 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT BTW Max, this is an Access list. I am not yanking your chain or anything, I just noticed that you mentioned "sticking to VBA". We do have a VB list as well which (other than OT Friday) pretty much sticks to VBA and VB.Net. I am going to make an assumption that you are new to our list and welcome you aboard. I'll also take this opportunity to explain that we are a community as well as a "list". There are a TON of developers who have been on this list for 10 years or more. As such we do tend to get a little more personal than some other lists. We are friends as well as developers. We have people assigned to police the list should things get too out of hand and we mostly leave it up to them to do the policing. But we do not run as tight a ship as you might be accustomed to on other lists and we like it that way. You are of course welcomed to the list, welcomed to contribute and hang out, but if you expect this list to be "just the facts ma'am", I can tell you up front you are in the wrong place. So welcome to the list and I hope you enjoy the community as much as you enjoy the immense knowledge base that our members bring to the list. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 1:01 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships - OT Thank you, I would appreciate that. I also appreciate the many useful contributions thay you all put in. Max Ps. I have been subscribing to Peach List for some 9 maybe more years now, so I do understand how it works. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 20, 2007 5:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Well said, Charlotte, and hats off to you for declaring it. Apologies also to Max, who apparently has not grasped that we like to have fun here, in addition to seeking and obtaining knowledge from the best in the business. Sorry, Max. In future I shall attempt to make my silly Friday messages targeted more precisely, to those members who like to take at least one day a week to have fun. I shall exclude you from this subcategory of this list, and I mean that in the nicest possible way. I did not intend to ruin your day. A. On 7/20/07, Charlotte Foust wrote: > > Traditionally, Fridays are very relaxed days with lots of nonsense. > Developers can only be serious for a limited period of time before > going totally insane, so we need at least one day a week to blow off > some steam. > > Charlotte > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman > Sent: Friday, July 20, 2007 8:55 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] One-to-One relationships > > Can we take all this sort of rubbish off-line please. There is enough > stuff coming through without having to wade through this sort of > nonsense. Can we please stick to VBA. > Thanks > Max -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Fri Jul 20 13:25:22 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 20 Jul 2007 11:25:22 -0700 Subject: [AccessD] One-to-One relationships - OT In-Reply-To: References: Message-ID: For you, Drew, the possibilities are out there. ;-> Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Friday, July 20, 2007 10:10 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT I wish I would have known this earlier...... is there hope of recovery if you've gone totally insane? ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 20, 2007 11:01 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] One-to-One relationships - OT Traditionally, Fridays are very relaxed days with lots of nonsense. Developers can only be serious for a limited period of time before going totally insane, so we need at least one day a week to blow off some steam. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Sherman Sent: Friday, July 20, 2007 8:55 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships Can we take all this sort of rubbish off-line please. There is enough stuff coming through without having to wade through this sort of nonsense. Can we please stick to VBA. Thanks Max The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Fri Jul 20 14:05:31 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 15:05:31 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> Message-ID: <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> John, I'm working a lot more with other Office products now than Access, so a list dedicated to Office might be nice, of course, specifying that Access traffic should remain on the AccessD list. Susan H. If anyone has a request for a new DBA list to discuss a specific subject please email me directly. Also, please leave this subject line in tact so I can sort these messages into a new email folder. From ssharkins at setel.com Fri Jul 20 14:05:30 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 15:05:30 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35><006501c7cacb$f129aa80$94b82ad1@SusanOne> <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> Message-ID: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> The first rule of database development is performance, above all other considerations. ======I strongly disagree -- the first rule is to ensure data integrity. Susan H. From listmaster at databaseadvisors.com Fri Jul 20 14:27:50 2007 From: listmaster at databaseadvisors.com (Bryan Carbonnell) Date: Fri, 20 Jul 2007 15:27:50 -0400 (EDT) Subject: [AccessD] One-to-One relationships - OT In-Reply-To: <016901c7cafb$16d79e20$8119fea9@LTVM> References: <015901c7caef$810bb0d0$8119fea9@LTVM> <20070720173116.542ABBDDD@smtp-auth.no-ip.com> <016901c7cafb$16d79e20$8119fea9@LTVM> Message-ID: <39200.159.33.10.92.1184959670.squirrel@carbonnell.ca> OK Folks this thread is closed. Move along. Nothing else to see here. -- Bryan Carbonnell - listmaster at databaseadvisors.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From fuller.artful at gmail.com Fri Jul 20 14:30:43 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 15:30:43 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> Message-ID: <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> Now that I have a sudden interest in Excel, I strongly agree! On 7/20/07, Susan Harkins wrote: > > John, I'm working a lot more with other Office products now than Access, > so > a list dedicated to Office might be nice, of course, specifying that > Access > traffic should remain on the AccessD list. > > Susan H. > > If anyone has a request for a new DBA list to discuss a specific subject > please email me directly. > > Also, please leave this subject line in tact so I can sort these messages > into a new email folder. > > > -- > 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 Jul 20 14:32:20 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 15:32:20 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35> <006501c7cacb$f129aa80$94b82ad1@SusanOne> <29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com> <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> Message-ID: <29f585dd0707201232k2e4a9920v6f8812c225c27796@mail.gmail.com> You're quite right, as usual, Susan. The second rule of db dev is performance; the first is integrity. A. On 7/20/07, Susan Harkins wrote: > > The first rule of database development is performance, above all other > considerations. > > ======I strongly disagree -- the first rule is to ensure data integrity. > > Susan H. > > From jwcolby at colbyconsulting.com Fri Jul 20 14:38:35 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 15:38:35 -0400 Subject: [AccessD] OT: Deal of the Day In-Reply-To: <004801c7cae5$6b62d830$0301a8c0@HAL9005> Message-ID: <20070720193838.B2281BF3A@smtp-auth.no-ip.com> They bought it at auction for $10? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Friday, July 20, 2007 11:48 AM To: dba-ot at databaseadvisors.com; 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Deal of the Day Today at Fry's: GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... $149.00. How do they make any money on this? Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Fri Jul 20 14:39:36 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 20 Jul 2007 15:39:36 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> Message-ID: <20070720193939.A9CB0BE8E@smtp-auth.no-ip.com> LOL, and I somewhat disagree. The first rule is to be useful and usable. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 20, 2007 3:06 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships The first rule of database development is performance, above all other considerations. ======I strongly disagree -- the first rule is to ensure data integrity. Susan H. -- 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 Jul 20 14:54:35 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Fri, 20 Jul 2007 14:54:35 -0500 Subject: [AccessD] One-to-One relationships Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CA8@xlivmbx35.aig.com> If it was performance above all we'd all be working with non-normalized flat databases. Joins cost time = reduce performance. But as we all know normalization is about having good data, not about getting at it as fast as possible. Just like Susan said. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 20, 2007 3:40 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships LOL, and I somewhat disagree. The first rule is to be useful and usable. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Friday, July 20, 2007 3:06 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] One-to-One relationships The first rule of database development is performance, above all other considerations. ======I strongly disagree -- the first rule is to ensure data integrity. 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 martyconnelly at shaw.ca Fri Jul 20 15:36:33 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Fri, 20 Jul 2007 13:36:33 -0700 Subject: [AccessD] Math in VBA In-Reply-To: References: Message-ID: <46A11CD1.80705@shaw.ca> If you just need a random 16 byte string how about creating a GUID Private Type GUID Data1 As Long Data2 As Integer Data3 As Integer Data4(7) As Byte End Type Private Declare Function CoCreateGuid Lib "OLE32.DLL" _ (pGuid As GUID) As Long Private Declare Function StringFromGUID2 Lib "OLE32.DLL" (rguid As GUID, _ ByVal lpsz As String, cbMax As Long) As Long 'More GUID routines here ' http://www.trigeminal.com/code/guids.bas Sub testguid() Dim pudtGUID As GUID Dim pstrGUID As String Dim plngRet As Long pstrGUID = String(256, 0) Debug.Print CoCreateGuid(pudtGUID) plngRet = StringFromGUID2(pudtGUID, pstrGUID, Len(pstrGUID)) Debug.Print plngRet Debug.Print "GUID = " & Left(pstrGUID, plngRet) Debug.Print pstrGUID End Sub Mark A Matte wrote: >Thanks Everyone, > >I ended up using a loop to get my powers...before I was the power by 1 for >each record...now I added a new loop to get the actual number if you >calculated out to the nth power. I was in the quadrillions when I finished. > Thanks Again, > >Mark > > Power = Power - 1 > PowerNum = CDec(36) > For PNLoop = 1 To Power - 1 > PowerNum = CDec(PowerNum * CDec(36)) > Next > > > > >>From: "Gustav Brock" >>Reply-To: Access Developers discussion and problem >>solving >>To: >>Subject: Re: [AccessD] Math in VBA >>Date: Thu, 19 Jul 2007 21:25:42 +0200 >> >>Hi Mark >> >>Chris is right. You have to keep the _numeric_ expressions within that of a >>Long if you wish to maintain accuracy. >> >>Thus: >>? CDec(36 ^10) >> 3656158440062980 >>? CDec(36 ^ 5) * CDec(36 ^ 5) >> 3656158440062976 >> >>because CDec(36 ^ 5) = 60466176. >> >>/gustav >> >> >> >>>>>cjeris at fas.harvard.edu 19-07-2007 20:37 >>> >>>>> >>>>> >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Mark A Matte wrote: >> >> >>>ttt = CDec(36 * 36 * 36) >>> >>> >>6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up >>and kick someone in the head for leaving a 16-bit signed integer type in >>a program written after 1995. >> >>Try >>ttt = CDec(36) * CDec(36) * CDec(36) >> >>Also, be careful! >> >> >>>tt = CDec(36 ^ 10) >>> >>> >>That ^ is the _floating_point_ exponentiation operator! The result is >>not the integer 6^20; if you look at tt, you will see that it ends in a >>0, which no power of 6 does. What you get there is the decimal >>conversion of the floating-point exponentiation. >> >>peace, Chris Jeris >> >> -- Marty Connelly Victoria, B.C. Canada From jmhecht at earthlink.net Fri Jul 20 16:00:06 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Fri, 20 Jul 2007 14:00:06 -0700 (GMT-07:00) Subject: [AccessD] OT: Deal of the Day Message-ID: <20503120.1184965206799.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> worst of both worlds -----Original Message----- >From: Jim Hewson >Sent: Jul 20, 2007 9:53 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] OT: Deal of the Day > >We have CompUSA but NO Fry's. > >Jim >jhewson at karta.com > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe Hecht >Sent: Friday, July 20, 2007 11:45 AM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] OT: Deal of the Day > >cause CompUSA aint around no more ? > >Joe > >Ex compUSA employee > >-----Original Message----- >>From: Rocky Smolin at Beach Access Software >>Sent: Jul 20, 2007 8:48 AM >>To: dba-ot at databaseadvisors.com, 'Access Developers discussion and problem solving' >>Subject: [AccessD] OT: Deal of the Day >> >>Today at Fry's: >> >>GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB >>RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... >> >> >>$149.00. >> >> >>How do they make any money on this? >> >> >>Rocky >> >> >> >> >> >> >>-- >>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 john at winhaven.net Fri Jul 20 16:01:02 2007 From: john at winhaven.net (John Bartow) Date: Fri, 20 Jul 2007 16:01:02 -0500 Subject: [AccessD] version of Access BE issues Message-ID: <024201c7cb11$15da0240$6402a8c0@ScuzzPaq> Has any one had any problems with using an A2k3 FE with A97 BE and then upgrading the BE to A2k3 but not changing the FE? From markamatte at hotmail.com Fri Jul 20 16:13:54 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 20 Jul 2007 21:13:54 +0000 Subject: [AccessD] Math in VBA In-Reply-To: <46A11CD1.80705@shaw.ca> Message-ID: Actually this wasn't about creating a random number...I using some 'big' math to encrypt and decrypt credit card numbers. It worked perfectly. Thanks for all of the help. Mark A. Matte >From: MartyConnelly >Reply-To: Access Developers discussion and problem >solving >To: Access Developers discussion and problem >solving >Subject: Re: [AccessD] Math in VBA >Date: Fri, 20 Jul 2007 13:36:33 -0700 > >If you just need a random 16 byte string how about creating a GUID > >Private Type GUID > Data1 As Long > Data2 As Integer > Data3 As Integer > Data4(7) As Byte >End Type > >Private Declare Function CoCreateGuid Lib "OLE32.DLL" _ > (pGuid As GUID) As Long >Private Declare Function StringFromGUID2 Lib "OLE32.DLL" (rguid As GUID, _ >ByVal lpsz As String, cbMax As Long) As Long > >'More GUID routines here >' http://www.trigeminal.com/code/guids.bas > >Sub testguid() > > Dim pudtGUID As GUID > Dim pstrGUID As String > Dim plngRet As Long > > pstrGUID = String(256, 0) > > Debug.Print CoCreateGuid(pudtGUID) > > plngRet = StringFromGUID2(pudtGUID, pstrGUID, Len(pstrGUID)) > Debug.Print plngRet > Debug.Print "GUID = " & Left(pstrGUID, plngRet) > Debug.Print pstrGUID > >End Sub > >Mark A Matte wrote: > > >Thanks Everyone, > > > >I ended up using a loop to get my powers...before I was the power by 1 >for > >each record...now I added a new loop to get the actual number if you > >calculated out to the nth power. I was in the quadrillions when I >finished. > > Thanks Again, > > > >Mark > > > > Power = Power - 1 > > PowerNum = CDec(36) > > For PNLoop = 1 To Power - 1 > > PowerNum = CDec(PowerNum * CDec(36)) > > Next > > > > > > > > > >>From: "Gustav Brock" > >>Reply-To: Access Developers discussion and problem > >>solving > >>To: > >>Subject: Re: [AccessD] Math in VBA > >>Date: Thu, 19 Jul 2007 21:25:42 +0200 > >> > >>Hi Mark > >> > >>Chris is right. You have to keep the _numeric_ expressions within that >of a > >>Long if you wish to maintain accuracy. > >> > >>Thus: > >>? CDec(36 ^10) > >> 3656158440062980 > >>? CDec(36 ^ 5) * CDec(36 ^ 5) > >> 3656158440062976 > >> > >>because CDec(36 ^ 5) = 60466176. > >> > >>/gustav > >> > >> > >> > >>>>>cjeris at fas.harvard.edu 19-07-2007 20:37 >>> > >>>>> > >>>>> > >>-----BEGIN PGP SIGNED MESSAGE----- > >>Hash: SHA1 > >> > >>Mark A Matte wrote: > >> > >> > >>>ttt = CDec(36 * 36 * 36) > >>> > >>> > >>6^6 = 46656 overflows a 16-bit signed integer. Now we can all line up > >>and kick someone in the head for leaving a 16-bit signed integer type in > >>a program written after 1995. > >> > >>Try > >>ttt = CDec(36) * CDec(36) * CDec(36) > >> > >>Also, be careful! > >> > >> > >>>tt = CDec(36 ^ 10) > >>> > >>> > >>That ^ is the _floating_point_ exponentiation operator! The result is > >>not the integer 6^20; if you look at tt, you will see that it ends in a > >>0, which no power of 6 does. What you get there is the decimal > >>conversion of the floating-point exponentiation. > >> > >>peace, Chris Jeris > >> > >> > >-- >Marty Connelly >Victoria, B.C. >Canada > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507 From ssharkins at setel.com Fri Jul 20 16:54:35 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 17:54:35 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707201232k2e4a9920v6f8812c225c27796@mail.gmail.com> References: <007e01c7ca5f$9a1d8c00$0a00a8c0@PCRURI35><006501c7cacb$f129aa80$94b82ad1@SusanOne><29f585dd0707200624l2814ac9ar7917e9892ed6e7b7@mail.gmail.com><00be01c7cb00$f1f6f280$94b82ad1@SusanOne> <29f585dd0707201232k2e4a9920v6f8812c225c27796@mail.gmail.com> Message-ID: <00e601c7cb18$907e04e0$94b82ad1@SusanOne> See JC???? ;) Now, I do agree that performance is important -- and I'd never force a rule simply for the sake of the rule and I'm perfectly Okay with denormalization for the sake of performance. Susan H. You're quite right, as usual, Susan. The second rule of db dev is performance; the first is integrity. From ssharkins at setel.com Fri Jul 20 16:54:35 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 17:54:35 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <20070720193939.A9CB0BE8E@smtp-auth.no-ip.com> References: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> <20070720193939.A9CB0BE8E@smtp-auth.no-ip.com> Message-ID: <00e701c7cb18$91f6c230$94b82ad1@SusanOne> I'd say that functionality and performance are right up there, but if the integrity's weak, nothing else matters. Susan H. LOL, and I somewhat disagree. The first rule is to be useful and usable. The first rule of database development is performance, above all other considerations. ======I strongly disagree -- the first rule is to ensure data integrity. From ssharkins at setel.com Fri Jul 20 16:54:35 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 17:54:35 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq><00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> Message-ID: <00e801c7cb18$9395a520$94b82ad1@SusanOne> Well, with enough interest, I suppose we could consider a dedicated list for the other larger apps, Word, Excel, and Outlook, and one more for the minor products? But, I don't see anything wrong with lumping them altogether -- if one app seems to become a focus, we could go with a dedicated list later. Susan H. Now that I have a sudden interest in Excel, I strongly agree! From fuller.artful at gmail.com Fri Jul 20 17:26:07 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 20 Jul 2007 18:26:07 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <00e701c7cb18$91f6c230$94b82ad1@SusanOne> References: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne> <20070720193939.A9CB0BE8E@smtp-auth.no-ip.com> <00e701c7cb18$91f6c230$94b82ad1@SusanOne> Message-ID: <29f585dd0707201526x48192d10lc8b36381818921f0@mail.gmail.com> Usefulness is in the mind of the beholder, not the design of the database. Usefulness is a front-end problem. I realize that many of us here do both jobs, but IMO they ought to be clearly distinguished. On the on hand you have the database and its design; on the other distant planet you have the user interface and its design. A. On 7/20/07, Susan Harkins wrote: > > I'd say that functionality and performance are right up there, but if the > integrity's weak, nothing else matters. > > Susan H. > > LOL, and I somewhat disagree. The first rule is to be useful and usable. > > > The first rule of database development is performance, above all other > considerations. > From ssharkins at setel.com Fri Jul 20 17:45:34 2007 From: ssharkins at setel.com (Susan Harkins) Date: Fri, 20 Jul 2007 18:45:34 -0400 Subject: [AccessD] One-to-One relationships In-Reply-To: <29f585dd0707201526x48192d10lc8b36381818921f0@mail.gmail.com> References: <00be01c7cb00$f1f6f280$94b82ad1@SusanOne><20070720193939.A9CB0BE8E@smtp-auth.no-ip.com><00e701c7cb18$91f6c230$94b82ad1@SusanOne> <29f585dd0707201526x48192d10lc8b36381818921f0@mail.gmail.com> Message-ID: <010801c7cb1f$c9c39010$94b82ad1@SusanOne> A clever developer can deliver both in Access. ;) Susan H. Usefulness is in the mind of the beholder, not the design of the database. Usefulness is a front-end problem. I realize that many of us here do both jobs, but IMO they ought to be clearly distinguished. On the on hand you have the database and its design; on the other distant planet you have the user interface and its design. From kathryn at bassett.net Fri Jul 20 20:22:23 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Fri, 20 Jul 2007 18:22:23 -0700 Subject: [AccessD] Many2Many try #2 In-Reply-To: <008301c7c8b9$ee78d630$6401a8c0@Kathryn> Message-ID: <009601c7cb35$97f66100$6401a8c0@Kathryn> Maybe the first time there was TMI because I only got one answer suggesting subforms. However, the ultimate goal is to duplicate this in MySql as the server in question doesn't do Access. I'm trying to understand the simplest approach in Access so that I'll be able to do the tranlation to MySql. In understanding my problem, I'm now thinking of these equivalents: tblCSnames = various people tblCScollections = various organizations A person can belong to many organizations. An organization can have many people. Here are the three tables so far. tblCScollections tblCScollectionID int(7) autoincrement, primary key tblCScollectionName varchar(50) populated with 11 collections for testing. tblCSnames tblCSnamesID int(7) autoincrement, primary key tblCSnameslastname varchar(50) tblCSnamesfirstname varchar(50) tblCSnamesMemo text populated with 5 members for testing tblCSjoin tblCSjoinIDcollection foreign key to tblCScollectionID tblCSjoinIDnames foreign key to tblCSnamesID There will only be one John Doe, one Jane Smith, etc, IOW one of each name, and the memo will take case of any explanations needed (and the memo may be empty if no explanation is needed). Don't worry about why, just accept that as fact. That means that all John Does will be tblCSnamesID=1 so I don't need any other fields to define John Doe. Q1) In tblCSjoin do I need tblCSjoinID int(7) autoincrement, primary key - - ? Q2) I will have provided to me a paper list of names that belong to a collection. So I need to make some sort of update query for collectionABC and add all the people who belong to that collection. If the name of a person already exists, then the query needs to figure that out, and update that person's list of collections. A dropdown list of names is not the answer because the list of names populating such a dropdown list would become unwieldly very fast. So the question is what would the sql be for the update query? Q3) One name complication is that it's possible to had a lastname Doe with an empty firstname, so in figuring out if the person already exists, it will have to look for (empty) Doe, John Doe, and Jane Doe. (Does empty always mean null?). Q3) isn't really a question, other than my parenthetical one. -- Kathryn Rhinehart Bassett (Pasadena CA) "Genealogy is my bag" "GH is my soap" kathryn at bassett.net http://bassett.net No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date: 19 Jul 07 6:10 pm From martyconnelly at shaw.ca Sat Jul 21 14:37:26 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Sat, 21 Jul 2007 12:37:26 -0700 Subject: [AccessD] Info: Microsoft Office Access 2007 Runtime download is back again In-Reply-To: <00e801c7cb18$9395a520$94b82ad1@SusanOne> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> <00e801c7cb18$9395a520$94b82ad1@SusanOne> Message-ID: <46A26076.5060601@shaw.ca> The Microsoft Office Access 2007 Runtime enables you to distribute Access 2007 applications to users who do not have the full version of Access 2007 installed on their computers. There is a known bug where some reports don't work in ADPs. A fix missed the build so maybe MS will post a hotfix soon. http://www.microsoft.com/downloads/details.aspx?FamilyId=D9AE78D9-9DC6-4B38-9FA6-2C745A175AED&displaylang=en -- Marty Connelly Victoria, B.C. Canada From shamil at users.mns.ru Sun Jul 22 02:11:32 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Sun, 22 Jul 2007 11:11:32 +0400 Subject: [AccessD] Does MSA2007 behaves well if on a machine with MSA 1997 and MSA 2000 and MSA2003? Message-ID: <000c01c7cc2f$888fc080$6401a8c0@nant> Hi All, Do you know if MSA2007 behaves well if on a machine with MSA 1997 and MSA 2000 and MSA2003 on it? (Of course all the mentioned above MS Access versions will be installed into different folders and in chronological order of their release dates). Thank you. -- Shamil "To live without stress and pressure, to live without shaky ground feeling - our tough times is so far away from everybody?s leisure, as happening a sex between Bluegill and Penguin." IG/SS - 22/07/2007 From miscellany at mvps.org Sun Jul 22 03:43:17 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sun, 22 Jul 2007 20:43:17 +1200 Subject: [AccessD] Does MSA2007 behaves well if on a machine with MSA 1997 and MSA 2000 and MSA2003? In-Reply-To: <000c01c7cc2f$888fc080$6401a8c0@nant> References: <000c01c7cc2f$888fc080$6401a8c0@nant> Message-ID: <46A318A5.7080300@mvps.org> Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and MSA > 2000 and MSA2003 on it? (Of course all the mentioned above MS Access > versions will be installed into different folders and in chronological order > of their release dates). From shamil at users.mns.ru Sun Jul 22 04:03:07 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Sun, 22 Jul 2007 13:03:07 +0400 Subject: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? In-Reply-To: <46A318A5.7080300@mvps.org> Message-ID: <000801c7cc3f$1ec680c0$6401a8c0@nant> Hello Steve, Thank you for your answer! Besides this issue of switching between running (?) instances of different MS Access versions are there any problems with previous version of MS Access or MS Access 2007 getting somehow stuck when working together on the same system? BTW, can one run MS Access 97 program databases on MS Access 2007? (Sorry no time to test here currently and I do not have MS Access 97 installed to make a good test database to run it on MS Access 2007)... Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 22, 2007 12:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and MSA > 2000 and MSA2003 on it? (Of course all the mentioned above MS Access > versions will be installed into different folders and in chronological order > of their release dates). -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Sun Jul 22 07:49:23 2007 From: ssharkins at setel.com (Susan Harkins) Date: Sun, 22 Jul 2007 08:49:23 -0400 Subject: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997 and MSA 2000 and MSA2003? In-Reply-To: <000801c7cc3f$1ec680c0$6401a8c0@nant> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant> Message-ID: <003f01c7cc5e$cad77b20$75b82ad1@SusanOne> Shamil, I have 2002, 2003, and 2007 on the same system. Things are definitely slower and about 1/3 of the time, launching 2003 or 2007 drags the installer into the act. :( So, I have to wait on that. Also, 2007 has usurped some of my shortcuts, but that's no biggee. I've noticed twice now that my system hasn't wanted to respond to a hard boot, so the above problem may be a symptom of my hd going bad and have nothing to do with 2007 -- however, I'm not having any trouble with other software (although I seldom use anything but Office). System is much slower over all though. I had planned to reformat and start over this month, but I've pushed that back to next month. I'm going to install VM so I can have a dedicated OS for 2007 -- I need both Outlook 2003 and 2007 to write about. I'm hoping that will take care of most of my performance problems. Susan H. Hello Steve, Thank you for your answer! Besides this issue of switching between running (?) instances of different MS Access versions are there any problems with previous version of MS Access or MS Access 2007 getting somehow stuck when working together on the same system? BTW, can one run MS Access 97 program databases on MS Access 2007? (Sorry no time to test here currently and I do not have MS Access 97 installed to make a good test database to run it on MS Access 2007)... Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 22, 2007 12:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and > MSA 2000 and MSA2003 on it? (Of course all the mentioned above MS > Access versions will be installed into different folders and in > chronological order > of their release dates). -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 2007/07/21 03:52 PM From robert at servicexp.com Sun Jul 22 12:47:40 2007 From: robert at servicexp.com (Robert) Date: Sun, 22 Jul 2007 13:47:40 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: <003f01c7cc5e$cad77b20$75b82ad1@SusanOne> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant> <003f01c7cc5e$cad77b20$75b82ad1@SusanOne> Message-ID: <002d01c7cc88$66e3eb60$0801a8c0@roberts> IIf(ServOption()=0,>1,ServOption()) This is the criteria in a query. ServOption is a function that returns a long. The query works when ServOption returns a specific option. However if ServOption returns 0, all the records are to be displayed, but doesn't WBR Robert From fuller.artful at gmail.com Sun Jul 22 13:07:06 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 22 Jul 2007 14:07:06 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: <002d01c7cc88$66e3eb60$0801a8c0@roberts> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant> <003f01c7cc5e$cad77b20$75b82ad1@SusanOne> <002d01c7cc88$66e3eb60$0801a8c0@roberts> Message-ID: <29f585dd0707221107n71e2a273pbe29381a0347b585@mail.gmail.com> Just a wag, but that query makes no sense to me. This could be the absence of information, of course, but what you wrote appears non-logical. Maybe you mis-typed, but given what you supplied and breaking it down, I end up with this: IIf( ServOption()=0, >1, ServOption() ) Perhaps that was one accidental keystroke (the ">") -- that's the part that makes no sense IMO. If ServOption() is a static function, then something like this might possibly work: (Assume ServOption() currently returns either zero or three, just to choose some value) SELECT * FROM mytables WHERE ServeOption() = 0 OR = ServeOption() Only one of these ORs can exist so I think that covers the bases. I could be more specific if I knew exactly what criteria ServeOption() was testing, but that's the general idea. hth, Arthur On 7/22/07, Robert wrote: > > > IIf(ServOption()=0,>1,ServOption()) > > This is the criteria in a query. > > ServOption is a function that returns a long. The query works when > ServOption returns a specific option. However if ServOption returns 0, all > the records are to be displayed, but doesn't > > > > > WBR > Robert > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From carbonnb at gmail.com Sun Jul 22 13:24:07 2007 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Sun, 22 Jul 2007 14:24:07 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <00e801c7cb18$9395a520$94b82ad1@SusanOne> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> <00e801c7cb18$9395a520$94b82ad1@SusanOne> Message-ID: On 7/20/07, Susan Harkins wrote: > Well, with enough interest, I suppose we could consider a dedicated list for > the other larger apps, Word, Excel, and Outlook, and one more for the minor > products? But, I don't see anything wrong with lumping them altogether -- if > one app seems to become a focus, we could go with a dedicated list later. That's one of the things that dba-tech is for. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From robert at servicexp.com Sun Jul 22 13:27:13 2007 From: robert at servicexp.com (Robert) Date: Sun, 22 Jul 2007 14:27:13 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: <29f585dd0707221107n71e2a273pbe29381a0347b585@mail.gmail.com> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant><003f01c7cc5e$cad77b20$75b82ad1@SusanOne><002d01c7cc88$66e3eb60$0801a8c0@roberts> <29f585dd0707221107n71e2a273pbe29381a0347b585@mail.gmail.com> Message-ID: <003401c7cc8d$ed3be910$0801a8c0@roberts> Arthur, Ok let me try and clear some things up... :-) IIf(ServOption()=0,>1,ServOption()) is in the criteria area of the saved query it's in. The query is a simple select query that returns records of past services. "ServOption()" returns the type of service rendered, (a long value, representing of the type of service and it's value can be from 2 to whatever.) which the user selected on a form. There is an option to show all service types or a selected type. The selected type works perfectly, but when I need to display all (i.e. >1) the query displays no records. If I hard code >1 it works fine, showing all records... The service type field in the query is numeric.. Clear as mud eh... :-) WBR Robert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 22, 2007 2:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Why doesn't this work? Just a wag, but that query makes no sense to me. This could be the absence of information, of course, but what you wrote appears non-logical. Maybe you mis-typed, but given what you supplied and breaking it down, I end up with this: IIf( ServOption()=0, >1, ServOption() ) Perhaps that was one accidental keystroke (the ">") -- that's the part that makes no sense IMO. If ServOption() is a static function, then something like this might possibly work: (Assume ServOption() currently returns either zero or three, just to choose some value) SELECT * FROM mytables WHERE ServeOption() = 0 OR = ServeOption() Only one of these ORs can exist so I think that covers the bases. I could be more specific if I knew exactly what criteria ServeOption() was testing, but that's the general idea. hth, Arthur On 7/22/07, Robert wrote: > > > IIf(ServOption()=0,>1,ServOption()) > > This is the criteria in a query. > > ServOption is a function that returns a long. The query works when > ServOption returns a specific option. However if ServOption returns 0, > all the records are to be displayed, but doesn't > > > > > WBR > Robert > > > -- > 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 DWUTKA at Marlow.com Sun Jul 22 13:43:57 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Sun, 22 Jul 2007 13:43:57 -0500 Subject: [AccessD] Why doesn't this work? In-Reply-To: <003401c7cc8d$ed3be910$0801a8c0@roberts> Message-ID: The problem is that IIF returns a value, and >1 isn't a value. So when the statement is true, ServOption() is returning a value that is being used as a criteria. Ie, ServOption() returns 3 then the WHERE clause looks like this: WHERE YourField=3 When it returns 0, your getting WHERE YourField=">1" And nothing will fit that criteria. There's two ways you can fix this. One, change your query to this: SELECT Table1.SomeNumber FROM Table1 WHERE SomeNumber Like IIf(ServOption()=0,"*",ServOption()) The other option is to have ServOption actually check the field for you. The above solution is probably best if ServOption only returns one value, but if you want ServOption to return more then one value, the next option would work better. Change ServOption to accept the field as an argument, and have it return true or false: SELECT Table1.SomeNumber FROM Table1 WHERE ServOption([SomeNumber])=True Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert Sent: Sunday, July 22, 2007 1:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Why doesn't this work? Arthur, Ok let me try and clear some things up... :-) IIf(ServOption()=0,>1,ServOption()) is in the criteria area of the saved query it's in. The query is a simple select query that returns records of past services. "ServOption()" returns the type of service rendered, (a long value, representing of the type of service and it's value can be from 2 to whatever.) which the user selected on a form. There is an option to show all service types or a selected type. The selected type works perfectly, but when I need to display all (i.e. >1) the query displays no records. If I hard code >1 it works fine, showing all records... The service type field in the query is numeric.. Clear as mud eh... :-) WBR Robert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 22, 2007 2:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Why doesn't this work? Just a wag, but that query makes no sense to me. This could be the absence of information, of course, but what you wrote appears non-logical. Maybe you mis-typed, but given what you supplied and breaking it down, I end up with this: IIf( ServOption()=0, >1, ServOption() ) Perhaps that was one accidental keystroke (the ">") -- that's the part that makes no sense IMO. If ServOption() is a static function, then something like this might possibly work: (Assume ServOption() currently returns either zero or three, just to choose some value) SELECT * FROM mytables WHERE ServeOption() = 0 OR = ServeOption() Only one of these ORs can exist so I think that covers the bases. I could be more specific if I knew exactly what criteria ServeOption() was testing, but that's the general idea. hth, Arthur On 7/22/07, Robert wrote: > > > IIf(ServOption()=0,>1,ServOption()) > > This is the criteria in a query. > > ServOption is a function that returns a long. The query works when > ServOption returns a specific option. However if ServOption returns 0, > all the records are to be displayed, but doesn't > > > > > WBR > Robert > > > -- > 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From fuller.artful at gmail.com Sun Jul 22 13:49:25 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 22 Jul 2007 14:49:25 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: References: <003401c7cc8d$ed3be910$0801a8c0@roberts> Message-ID: <29f585dd0707221149l7b62dfb7o2d35458b7a5267@mail.gmail.com> Exactly what I was attempting to say, but you did it better, Drew. A. On 7/22/07, Drew Wutka wrote: > > The problem is that IIF returns a value, and >1 isn't a value. So when > the statement is true, ServOption() is returning a value that is being > used as a criteria. > > Ie, ServOption() returns 3 then the WHERE clause looks like this: > > WHERE YourField=3 > > When it returns 0, your getting > > WHERE YourField=">1" > > And nothing will fit that criteria. > > There's two ways you can fix this. One, change your query to this: > > SELECT Table1.SomeNumber > FROM Table1 > WHERE SomeNumber Like IIf(ServOption()=0,"*",ServOption()) > > The other option is to have ServOption actually check the field for you. > The above solution is probably best if ServOption only returns one > value, but if you want ServOption to return more then one value, the > next option would work better. Change ServOption to accept the field as > an argument, and have it return true or false: > > SELECT Table1.SomeNumber > FROM Table1 > WHERE ServOption([SomeNumber])=True > > Drew > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert > Sent: Sunday, July 22, 2007 1:27 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Why doesn't this work? > > Arthur, > Ok let me try and clear some things up... :-) > > IIf(ServOption()=0,>1,ServOption()) is in the criteria area of the saved > query it's in. The query is a simple select query that returns records > of > past services. > > "ServOption()" returns the type of service rendered, (a long value, > representing of the type of service and it's value can be from 2 to > whatever.) which the user selected on a form. > > There is an option to show all service types or a selected type. The > selected type works perfectly, but when I need to display all (i.e. >1) > the > query displays no records. If I hard code >1 it works fine, showing all > records... > > > The service type field in the query is numeric.. > > > Clear as mud eh... :-) > > > WBR > Robert > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Sunday, July 22, 2007 2:07 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Why doesn't this work? > > Just a wag, but that query makes no sense to me. This could be the > absence > of information, of course, but what you wrote appears non-logical. Maybe > you > mis-typed, but given what you supplied and breaking it down, I end up > with > this: > > IIf( > ServOption()=0, > >1, > ServOption() > ) > > Perhaps that was one accidental keystroke (the ">") -- that's the part > that > makes no sense IMO. > > If ServOption() is a static function, then something like this might > possibly work: > > (Assume ServOption() currently returns either zero or three, just to > choose > some value) > > SELECT * FROM mytables > WHERE ServeOption() = 0 > OR = ServeOption() > > Only one of these ORs can exist so I think that covers the bases. I > could be > more specific if I knew exactly what criteria ServeOption() was testing, > but > that's the general idea. > > hth, > Arthur > > On 7/22/07, Robert wrote: > > > > > > IIf(ServOption()=0,>1,ServOption()) > > > > This is the criteria in a query. > > > > ServOption is a function that returns a long. The query works when > > ServOption returns a specific option. However if ServOption returns 0, > > > all the records are to be displayed, but doesn't > > > > > > > > > > WBR > > Robert > > > > > > -- > > 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 > The information contained in this transmission is intended only for the > person or entity to which it is addressed and may contain II-VI Proprietary > and/or II-VI BusinessSensitve material. If you are not the intended > recipient, please contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. You are notified that any > review, retransmission, copying, disclosure, dissemination, or other use of, > or taking of any action in reliance upon this information by persons or > entities other than the intended recipient is prohibited. > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From robert at servicexp.com Sun Jul 22 14:44:24 2007 From: robert at servicexp.com (Robert) Date: Sun, 22 Jul 2007 15:44:24 -0400 Subject: [AccessD] Why doesn't this work? In-Reply-To: References: <003401c7cc8d$ed3be910$0801a8c0@roberts> Message-ID: <003501c7cc98$b5bfa700$0801a8c0@roberts> Guys, Thanks a million for your help, Drew your suggestion worked perfectly.. WBR Robert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Sunday, July 22, 2007 2:44 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Why doesn't this work? The problem is that IIF returns a value, and >1 isn't a value. So when the statement is true, ServOption() is returning a value that is being used as a criteria. Ie, ServOption() returns 3 then the WHERE clause looks like this: WHERE YourField=3 When it returns 0, your getting WHERE YourField=">1" And nothing will fit that criteria. There's two ways you can fix this. One, change your query to this: SELECT Table1.SomeNumber FROM Table1 WHERE SomeNumber Like IIf(ServOption()=0,"*",ServOption()) The other option is to have ServOption actually check the field for you. The above solution is probably best if ServOption only returns one value, but if you want ServOption to return more then one value, the next option would work better. Change ServOption to accept the field as an argument, and have it return true or false: SELECT Table1.SomeNumber FROM Table1 WHERE ServOption([SomeNumber])=True Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert Sent: Sunday, July 22, 2007 1:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Why doesn't this work? Arthur, Ok let me try and clear some things up... :-) IIf(ServOption()=0,>1,ServOption()) is in the criteria area of the saved query it's in. The query is a simple select query that returns records of past services. "ServOption()" returns the type of service rendered, (a long value, representing of the type of service and it's value can be from 2 to whatever.) which the user selected on a form. There is an option to show all service types or a selected type. The selected type works perfectly, but when I need to display all (i.e. >1) the query displays no records. If I hard code >1 it works fine, showing all records... The service type field in the query is numeric.. Clear as mud eh... :-) WBR Robert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Sunday, July 22, 2007 2:07 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Why doesn't this work? Just a wag, but that query makes no sense to me. This could be the absence of information, of course, but what you wrote appears non-logical. Maybe you mis-typed, but given what you supplied and breaking it down, I end up with this: IIf( ServOption()=0, >1, ServOption() ) Perhaps that was one accidental keystroke (the ">") -- that's the part that makes no sense IMO. If ServOption() is a static function, then something like this might possibly work: (Assume ServOption() currently returns either zero or three, just to choose some value) SELECT * FROM mytables WHERE ServeOption() = 0 OR = ServeOption() Only one of these ORs can exist so I think that covers the bases. I could be more specific if I knew exactly what criteria ServeOption() was testing, but that's the general idea. hth, Arthur On 7/22/07, Robert wrote: > > > IIf(ServOption()=0,>1,ServOption()) > > This is the criteria in a query. > > ServOption is a function that returns a long. The query works when > ServOption returns a specific option. However if ServOption returns 0, > all the records are to be displayed, but doesn't > > > > > WBR > Robert > > > -- > 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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ssharkins at setel.com Sun Jul 22 15:31:04 2007 From: ssharkins at setel.com (Susan Harkins) Date: Sun, 22 Jul 2007 16:31:04 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq><00bf01c7cb00$f3981f60$94b82ad1@SusanOne><29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com><00e801c7cb18$9395a520$94b82ad1@SusanOne> Message-ID: <003f01c7cc9f$3e462800$6eb62ad1@SusanOne> On 7/20/07, Susan Harkins wrote: > Well, with enough interest, I suppose we could consider a dedicated > list for the other larger apps, Word, Excel, and Outlook, and one more > for the minor products? But, I don't see anything wrong with lumping > them altogether -- if one app seems to become a focus, we could go with a dedicated list later. That's one of the things that dba-tech is for. ======Well, we could say dba-tech is for everything else then -- so why ask for new list ideas? I'm confused. Susan H. From bheid at sc.rr.com Sun Jul 22 18:57:04 2007 From: bheid at sc.rr.com (Bobby Heid) Date: Sun, 22 Jul 2007 19:57:04 -0400 Subject: [AccessD] Access 2007 Run time re-released... Message-ID: <000c01c7ccbc$014c3d00$03e4b700$@rr.com> Found it here: http://accessextra.blogspot.com/2007/07/access-2007-runtime-re-issued-access .html Direct links: Runtime http://www.microsoft.com/downloads/details.aspx?familyid=d9ae78d9-9dc6-4b38- 9fa6-2c745a175aed&displaylang=en&tm Developer extensions http://www.microsoft.com/downloads/details.aspx?FamilyId=D96A8358-ECE4-4BEE- A844-F81856DCEB67&displaylang=en Bobby From bheid at sc.rr.com Sun Jul 22 16:05:58 2007 From: bheid at sc.rr.com (Bobby Heid) Date: Sun, 22 Jul 2007 17:05:58 -0400 Subject: [AccessD] Info: Microsoft Office Access 2007 Runtime download is back again In-Reply-To: <46A26076.5060601@shaw.ca> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> <00e801c7cb18$9395a520$94b82ad1@SusanOne> <46A26076.5060601@shaw.ca> Message-ID: <001401c7cca4$1a216ed0$4e644c70$@rr.com> Now I see your message after I posted about the new runtime... Bobby -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly Sent: Saturday, July 21, 2007 3:37 PM To: Access Developers discussion and problem solving Subject: [AccessD] Info: Microsoft Office Access 2007 Runtime download is back again The Microsoft Office Access 2007 Runtime enables you to distribute Access 2007 applications to users who do not have the full version of Access 2007 installed on their computers. There is a known bug where some reports don't work in ADPs. A fix missed the build so maybe MS will post a hotfix soon. http://www.microsoft.com/downloads/details.aspx?FamilyId=D9AE78D9-9DC6-4B38- 9FA6-2C745A175AED&displaylang=en -- Marty Connelly Victoria, B.C. Canada From bheid at sc.rr.com Sun Jul 22 16:18:52 2007 From: bheid at sc.rr.com (Bobby Heid) Date: Sun, 22 Jul 2007 17:18:52 -0400 Subject: [AccessD] Require password for linked MDB tables In-Reply-To: References: <006801c7c988$f7c3fba0$e74bf2e0$@rr.com> Message-ID: <001501c7cca5$e773e1f0$b65ba5d0$@rr.com> Sorry for the delay in getting back to you, I'm in the middle of installing Vista on my system and do not have everything installed yet. I do not open databases that way, I use something like: Set dbDatabase = Workspaces(0).OpenDatabase(lstrEnterpriseDB, True, False, ";pwd=" & SECUREPW) Where in your case, SECUREPW would be the password that the user entered. I am sure that you could modify your version to include the ';pw=somepassword' functionality. Basically your connection string looks like this (for later versions (not sure of 2007) of Access: Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\My.mdb;Password=SomePassword; Hope this helps, Bobby -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Thursday, July 19, 2007 9:53 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Require password for linked MDB tables But if I use the following to try to link...I get the error (invalid Password): Set tdf = dbs.CreateTableDef("Test") tdf.Connect = ";Database=C:\temp\test.mdb" tdf.SourceTableName = "tblPass" dbs.TableDefs.Append tdf >From: "Bobby Heid" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Require password for linked MDB tables >Date: Wed, 18 Jul 2007 18:14:10 -0400 > >I guess if you asked the user for the password before linking the table, >then it might work. You would have it unlink it after using it. > >Bobby > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Tuesday, July 17, 2007 3:49 PM >To: accessd at databaseadvisors.com >Subject: [AccessD] Require password for linked MDB tables > >Hello All, > >Can I have an MDB linked to a seperate MDB(with password)...and have the >user required to enter just a password to view the linked table each time? > >And is it different in different versions? > >Thanks, > >Mark A. Matte > From carbonnb at gmail.com Sun Jul 22 16:50:07 2007 From: carbonnb at gmail.com (Bryan Carbonnell) Date: Sun, 22 Jul 2007 17:50:07 -0400 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <003f01c7cc9f$3e462800$6eb62ad1@SusanOne> References: <00fe01c7cade$e0dae1e0$6402a8c0@ScuzzPaq> <00bf01c7cb00$f3981f60$94b82ad1@SusanOne> <29f585dd0707201230h7e8082fam968077c3881fc453@mail.gmail.com> <00e801c7cb18$9395a520$94b82ad1@SusanOne> <003f01c7cc9f$3e462800$6eb62ad1@SusanOne> Message-ID: On 7/22/07, Susan Harkins wrote: > ======Well, we could say dba-tech is for everything else then -- so why ask > for new list ideas? I'm confused. I was just pointing you to a place for your questions. If there is a "critical mass" for a new list then I'm sure John will discuss it with all involved to make it happen. But yea, tech is for anything that doesn't have it's own list at the moment. Just like OT is for all Off Topic discussions. I think Johns e-mail was in response to a post asking about and ASP or ASP.net list. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" From kathryn at bassett.net Sun Jul 22 17:55:38 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Sun, 22 Jul 2007 15:55:38 -0700 Subject: [AccessD] Let me try this another way - please help me understand this? In-Reply-To: <009601c7cb35$97f66100$6401a8c0@Kathryn> Message-ID: <005d01c7ccb3$6c5e4c40$6401a8c0@Kathryn> Maybe a screen capture will get someone to help me. http://www.genealogylibrarycenter.com/images/manymanyrelationship.jpg First, the word foreign in the tblCSjoin bottom field name has been corrected, so ignore that. The word was intended to be in the description. Now, here's my problem. I've only ever done Many-One or One-Many, I've never done a Many-Many and don't know how to join the tables. I've tried some different combos and nothing will turn that One-To-Many into Many-To-Many. And I'm not clear on Enforcing and the Cascading either. A name can belong to many collections. A collection can have many names. There is never going to be two people of the same name. Don't be concerned with why not, just be assured I've got my reasons, and a solution. So, how do I drag the tblCSjoin's foreign key's to the primary keys in the other tables, and what all do I checkmark? I'll get to other question after this part is solved. -- Kathryn Rhinehart Bassett (Pasadena CA) "Genealogy is my bag" "GH is my soap" kathryn at bassett.net http://bassett.net No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 21 Jul 07 3:52 pm From miscellany at mvps.org Sun Jul 22 18:07:27 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 23 Jul 2007 11:07:27 +1200 Subject: [AccessD] Let me try this another way - please help me understand this? In-Reply-To: <005d01c7ccb3$6c5e4c40$6401a8c0@Kathryn> References: <005d01c7ccb3$6c5e4c40$6401a8c0@Kathryn> Message-ID: <46A3E32F.1090905@mvps.org> Kathryn, You may be interested to read this short article... http://accesstips.datamanagementsolutions.biz/many.htm If I correctly understand your example, it seems to me that there should be a one-to-many join between: tblCScollections.tblCScollectionID and tblCSjoin.tblCSjoinIDcollection ... and also a one-to-many relationship between: tblCSnames.tblCSnamesID and tblCSjoin.tblCSjoinIDnames Regards Steve Kathryn Bassett wrote: > Maybe a screen capture will get someone to help me. > http://www.genealogylibrarycenter.com/images/manymanyrelationship.jpg > > First, the word foreign in the tblCSjoin bottom field name has been corrected, so ignore that. The word was intended to be in the description. Now, here's my problem. I've only ever done Many-One or One-Many, I've never done a Many-Many and don't know how to join the tables. I've tried some different combos and nothing will turn that One-To-Many into Many-To-Many. And I'm not clear on Enforcing and the Cascading either. > > A name can belong to many collections. > A collection can have many names. > > There is never going to be two people of the same name. Don't be concerned with why not, just be assured I've got my reasons, and a solution. > > So, how do I drag the tblCSjoin's foreign key's to the primary keys in the other tables, and what all do I checkmark? > > I'll get to other question after this part is solved. > From rockysmolin at bchacc.com Sun Jul 22 18:11:05 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Sun, 22 Jul 2007 16:11:05 -0700 Subject: [AccessD] Remote Assistance Message-ID: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky From rockysmolin at bchacc.com Sun Jul 22 18:29:52 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Sun, 22 Jul 2007 16:29:52 -0700 Subject: [AccessD] Request for new DBA List to discuss specific subjects In-Reply-To: <003f01c7cc9f$3e462800$6eb62ad1@SusanOne> Message-ID: <002601c7ccb8$347cee80$0301a8c0@HAL9005> And don't we run into the problem of Automation - that is, I want to do something with Outlook in Access or push some data from Access into and Excel spreadsheet. Which list do I go to? And for others that monitor the list - in order to learn all the stuff that's talked about related to Access they'd have to go to multiple lists. My opinion: the traffic on AccessD isn't that heavy. I use the delete key on threads I'm not interested in. I think more and varied topics on AccessD rather than fragmenting the list into too many topics. IMHO. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Sunday, July 22, 2007 1:31 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Request for new DBA List to discuss specific subjects On 7/20/07, Susan Harkins wrote: > Well, with enough interest, I suppose we could consider a dedicated > list for the other larger apps, Word, Excel, and Outlook, and one more > for the minor products? But, I don't see anything wrong with lumping > them altogether -- if one app seems to become a focus, we could go > with a dedicated list later. That's one of the things that dba-tech is for. ======Well, we could say dba-tech is for everything else then -- so why ask for new list ideas? I'm confused. Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 7/21/2007 3:52 PM From kathryn at bassett.net Sun Jul 22 18:32:42 2007 From: kathryn at bassett.net (Kathryn Bassett) Date: Sun, 22 Jul 2007 16:32:42 -0700 Subject: [AccessD] Let me try this another way - please help me understand this? In-Reply-To: <46A3E32F.1090905@mvps.org> Message-ID: <006901c7ccb8$99dd1480$6401a8c0@Kathryn> Steve pointed out the error in my thinking - tho collections and names are many to many, collections to join are many to one - duh! And that link was a good one. Now the question remains of which things I check, but maybe that needs more info. Once I get this working in Access, I have to get it all fixed up in MySql as the server doesn't "do" Access. Kathryn > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > Steve Schapel > Sent: 22 Jul 2007 4:07 pm > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Let me try this another way - please > help me understand this? > > Kathryn, > > You may be interested to read this short article... > http://accesstips.datamanagementsolutions.biz/many.htm > > If I correctly understand your example, it seems to me that > there should be a one-to-many join between: > tblCScollections.tblCScollectionID and > tblCSjoin.tblCSjoinIDcollection ... and also a one-to-many > relationship between: > tblCSnames.tblCSnamesID and tblCSjoin.tblCSjoinIDnames > > Regards > Steve > > > Kathryn Bassett wrote: > > Maybe a screen capture will get someone to help me. > > > http://www.genealogylibrarycenter.com/images/manymanyrelationship.jpg > > > > First, the word foreign in the tblCSjoin bottom field name > has been corrected, so ignore that. The word was intended to > be in the description. Now, here's my problem. I've only ever > done Many-One or One-Many, I've never done a Many-Many and > don't know how to join the tables. I've tried some different > combos and nothing will turn that One-To-Many into > Many-To-Many. And I'm not clear on Enforcing and the Cascading either. > > > > A name can belong to many collections. > > A collection can have many names. > > > > There is never going to be two people of the same name. > Don't be concerned with why not, just be assured I've got my > reasons, and a solution. > > > > So, how do I drag the tblCSjoin's foreign key's to the > primary keys in the other tables, and what all do I checkmark? > > > > I'll get to other question after this part is solved. > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.12/910 - Release > Date: 21 Jul 07 3:52 pm > > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 21 Jul 07 3:52 pm From fuller.artful at gmail.com Sun Jul 22 20:50:02 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 22 Jul 2007 21:50:02 -0400 Subject: [AccessD] Let me try this another way - please help me understand this? In-Reply-To: <006901c7ccb8$99dd1480$6401a8c0@Kathryn> References: <46A3E32F.1090905@mvps.org> <006901c7ccb8$99dd1480$6401a8c0@Kathryn> Message-ID: <29f585dd0707221850n35093b31jf6dcef594b7c7da3@mail.gmail.com> A Many-to-Many is easily resolved, Kath. Given tables A and B with PKs APK and BPK then Create table A2B having (now here comes the controversy (enter JWC LOL)) either an autoNumber or alternatively a compound PK consisting of APK+BPK (both of which columns must be present and not null). In either setup, you're good to go. In the case of MySQL I would go with the compound PK on the associative table, rather than the autonum, but that's strictly because of the behaviour of MySQL rather than a recommendation that can be generalized to all implementations of SQL. A. On 7/22/07, Kathryn Bassett wrote: > > Steve pointed out the error in my thinking - tho collections and names are > many to many, collections to join are many to one - duh! And that link was a > good one. > > Now the question remains of which things I check, but maybe that needs > more info. Once I get this working in Access, I have to get it all fixed up > in MySql as the server doesn't "do" Access. > > Kathryn > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > > Steve Schapel > > Sent: 22 Jul 2007 4:07 pm > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] Let me try this another way - please > > help me understand this? > > > > Kathryn, > > > > You may be interested to read this short article... > > http://accesstips.datamanagementsolutions.biz/many.htm > > > > If I correctly understand your example, it seems to me that > > there should be a one-to-many join between: > > tblCScollections.tblCScollectionID and > > tblCSjoin.tblCSjoinIDcollection ... and also a one-to-many > > relationship between: > > tblCSnames.tblCSnamesID and tblCSjoin.tblCSjoinIDnames > > > > Regards > > Steve > > > > > > Kathryn Bassett wrote: > > > Maybe a screen capture will get someone to help me. > > > > > http://www.genealogylibrarycenter.com/images/manymanyrelationship.jpg > > > > > > First, the word foreign in the tblCSjoin bottom field name > > has been corrected, so ignore that. The word was intended to > > be in the description. Now, here's my problem. I've only ever > > done Many-One or One-Many, I've never done a Many-Many and > > don't know how to join the tables. I've tried some different > > combos and nothing will turn that One-To-Many into > > Many-To-Many. And I'm not clear on Enforcing and the Cascading either. > > > > > > A name can belong to many collections. > > > A collection can have many names. > > > > > > There is never going to be two people of the same name. > > Don't be concerned with why not, just be assured I've got my > > reasons, and a solution. > > > > > > So, how do I drag the tblCSjoin's foreign key's to the > > primary keys in the other tables, and what all do I checkmark? > > > > > > I'll get to other question after this part is solved. > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.12/910 - Release > > Date: 21 Jul 07 3:52 pm > > > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.12/910 - Release Date: 21 Jul 07 > 3:52 pm > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From thewaddles at sbcglobal.net Sun Jul 22 21:48:50 2007 From: thewaddles at sbcglobal.net (Kevin Waddle) Date: Sun, 22 Jul 2007 19:48:50 -0700 Subject: [AccessD] OT: VB6 datarepeater control and checkboxes (Cross posted) Message-ID: <007301c7ccd4$05f73a90$6600a8c0@TheWaddles> I apologize for the OT post. I am trying to recreate an Access continuous form in a VB6 exe using the datarepeater control. I have created a ActiveX control containing a TextBox and a CheckBox. These are bound to an Access mdb file. I can display and update the textbox but cannot get anything to display properly on the checkboxes. The control will display the checkbox as true only when the record is active. Does anyone have an example using the datarepeater control with a checkbox or another avenue to create a continuous form in VB6? Thank you, Kevin Catscan: a hi-tech device for examining cats. From nd500_lo at charter.net Sun Jul 22 22:44:23 2007 From: nd500_lo at charter.net (Dian) Date: Sun, 22 Jul 2007 20:44:23 -0700 Subject: [AccessD] Remote Assistance In-Reply-To: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> References: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> Message-ID: <000001c7ccdb$c3053130$6400a8c0@dsunit1> I've done the Remote Assistance thing...and the other party CAN, if they know how, see everything and do anything on YOUR machine. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Sunday, July 22, 2007 4:11 PM To: 'Access Developers discussion and problem solving'; dba-ot at databaseadvisors.com; dba-tech-request at databaseadvisors.com Subject: [AccessD] Remote Assistance I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From nd500_lo at charter.net Sun Jul 22 22:45:57 2007 From: nd500_lo at charter.net (Dian) Date: Sun, 22 Jul 2007 20:45:57 -0700 Subject: [AccessD] Remote Assistance In-Reply-To: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> References: <002101c7ccb5$94ad9820$0301a8c0@HAL9005> Message-ID: <000101c7ccdb$fab44210$6400a8c0@dsunit1> OK...whoever STARTS the connection can do that...not the receiver. The receiver loses total control of the machine...sorry...it's late here and I'm tired. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Sunday, July 22, 2007 4:11 PM To: 'Access Developers discussion and problem solving'; dba-ot at databaseadvisors.com; dba-tech-request at databaseadvisors.com Subject: [AccessD] Remote Assistance I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Mon Jul 23 09:45:06 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 23 Jul 2007 07:45:06 -0700 Subject: [AccessD] Remote Assistance In-Reply-To: <000101c7ccdb$fab44210$6400a8c0@dsunit1> Message-ID: <002101c7cd38$0f831520$0301a8c0@HAL9005> OK, I'm connected between two machines now. #2 sent the invitation to #1. #1 accepted and can see everything on #2 screen. But the box labeled "Connection Status" says Connected/Screen View Only. On #1 I can see what's on the screen of #2 but can't figure a way to change anything. DO you know how #1 can get control of #2? TIA Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian Sent: Sunday, July 22, 2007 8:46 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Remote Assistance OK...whoever STARTS the connection can do that...not the receiver. The receiver loses total control of the machine...sorry...it's late here and I'm tired. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Sunday, July 22, 2007 4:11 PM To: 'Access Developers discussion and problem solving'; dba-ot at databaseadvisors.com; dba-tech-request at databaseadvisors.com Subject: [AccessD] Remote Assistance I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.14/912 - Release Date: 7/22/2007 7:02 PM From DWUTKA at Marlow.com Mon Jul 23 10:09:52 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 23 Jul 2007 10:09:52 -0500 Subject: [AccessD] Remote Assistance In-Reply-To: <002101c7cd38$0f831520$0301a8c0@HAL9005> Message-ID: Not sure if you can do that with plain old remote desktop. I know how to take control when you have terminal services running (with a remote desktop interface), you have to go into the terminal services manager snapin, then you just right click on the connected user and select remote control. If you can't get this to work, you could try a web-ex session. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Monday, July 23, 2007 9:45 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Remote Assistance OK, I'm connected between two machines now. #2 sent the invitation to #1. #1 accepted and can see everything on #2 screen. But the box labeled "Connection Status" says Connected/Screen View Only. On #1 I can see what's on the screen of #2 but can't figure a way to change anything. DO you know how #1 can get control of #2? TIA Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian Sent: Sunday, July 22, 2007 8:46 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Remote Assistance OK...whoever STARTS the connection can do that...not the receiver. The receiver loses total control of the machine...sorry...it's late here and I'm tired. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Sunday, July 22, 2007 4:11 PM To: 'Access Developers discussion and problem solving'; dba-ot at databaseadvisors.com; dba-tech-request at databaseadvisors.com Subject: [AccessD] Remote Assistance I have a prospect in Ecuador that would like an on-line demo. I suggested Remote Assistance since we've both got it. I just tested it on two of my boxes here and it seems pretty easy. He' saying that I should issue the invitation to him. When I made the connection it was view only. What I'm wondering is if there's a way for him to see anything in my machine other than what's on my screen. MTIA Rocky -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.14/912 - Release Date: 7/22/2007 7:02 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From cfoust at infostatsystems.com Mon Jul 23 10:08:32 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 23 Jul 2007 08:08:32 -0700 Subject: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997 and MSA 2000 and MSA2003? In-Reply-To: <000801c7cc3f$1ec680c0$6401a8c0@nant> References: <46A318A5.7080300@mvps.org> <000801c7cc3f$1ec680c0$6401a8c0@nant> Message-ID: Shamil, The other versions work all right, but the big pain is the installer running when you switch back to 2003 or 2007. The 2003 installer doesn't take overly long, but the 2007 installer takes a YEAR!! I've had some problems with some of my earlier dbs in 2007, depending on how creative I had been when I built them. Since I spend so little time in Access, now, I haven't really exercised it. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: Sunday, July 22, 2007 2:03 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997 and MSA 2000 and MSA2003? Hello Steve, Thank you for your answer! Besides this issue of switching between running (?) instances of different MS Access versions are there any problems with previous version of MS Access or MS Access 2007 getting somehow stuck when working together on the same system? BTW, can one run MS Access 97 program databases on MS Access 2007? (Sorry no time to test here currently and I do not have MS Access 97 installed to make a good test database to run it on MS Access 2007)... Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 22, 2007 12:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and > MSA 2000 and MSA2003 on it? (Of course all the mentioned above MS > Access versions will be installed into different folders and in > chronological order > of their release dates). -- 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 john at winhaven.net Mon Jul 23 10:58:06 2007 From: john at winhaven.net (John Bartow) Date: Mon, 23 Jul 2007 10:58:06 -0500 Subject: [AccessD] Remote Assistance In-Reply-To: <002101c7cd38$0f831520$0301a8c0@HAL9005> References: <000101c7ccdb$fab44210$6400a8c0@dsunit1> <002101c7cd38$0f831520$0301a8c0@HAL9005> Message-ID: <054c01c7cd42$43a15290$6402a8c0@ScuzzPaq> Rocky, Please take this off list or resume it on dba-tech. Anyone who likes to respond to questions like this please sub to dba-tech. John Bartow, President Database Advisors, Inc. Email: mailto:president at databaseadvisors.com Website: http://www.databaseadvisors.com From cjeris at fas.harvard.edu Mon Jul 23 12:50:47 2007 From: cjeris at fas.harvard.edu (Christopher Jeris) Date: Mon, 23 Jul 2007 13:50:47 -0400 Subject: [AccessD] Can't call methods I've added to a form? Message-ID: <46A4EA77.3070307@fas.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to build a set of forms according to MVC principles, and I think there's something fundamental I don't understand about Access form objects. Everything here is unbound forms, in Access 2002 sp3. I need to have "forms" that serve the same application role but present different user interfaces according to context, so I build a Controller object that creates different Form (view) objects depending on the context. But the Controller needs to tell the view to update itself in certain ways, so I have a method in the form's class like Public Sub InitializeFromBuffer(buffer As DataModelObject) and then the controller's process for opening up the form goes something like Set Me.activeForm = OpenFormByContext(intendedFormClass As String, _ context As ContextInfo) If Not Me.activeForm Is Nothing Then ' it worked Set Me.activeForm.Controller = Me Me.activeForm.InitializeFromBuffer theBuffer ' FAILURE End If Now calling InitializeFromBuffer ... or any other public method I try to add to a Form object ... from outside that Form's own class ... results in an "Application-defined or object-defined error". Is it really not possible to add methods to a Form that get called from outside the Form -- or am I missing something obvious ? I suppose, since adding _properties_ seems to work okay, one kludgy workaround would be to give the Form a property that is its "view proxy object", which is a user-defined class where all the methods I want to add are located, and call methods through the view proxy object ... but I'd rather say what I mean. thanks, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpOp35ICCNV0oGWARAiGDAJ9DwZIZ+eo3V/MsLOxBaT2/Y5wzwACgmb4+ j5Xtsy7ZmlM6bOkXXzOS3QY= =rjCB -----END PGP SIGNATURE----- From jwcolby at colbyconsulting.com Mon Jul 23 13:18:24 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 23 Jul 2007 14:18:24 -0400 Subject: [AccessD] Can't call methods I've added to a form? In-Reply-To: <46A4EA77.3070307@fas.harvard.edu> Message-ID: <20070723181833.72D1AC15C@smtp-auth.no-ip.com> >Now calling InitializeFromBuffer ... or any other public method I try to add to a Form object ... from outside that Form's own class ... results in an "Application-defined or object-defined error". You don't say how you are calling the form's method. You have to specify the form object, then the method so... Forms("MyForm").InitializeFromBuffer SomeParam Alternatively: Dim frm as form set frm=forms("MyForm") frm.InitializeFromBuffer SomeParam Remember that a form's code is a class and you have to get a pointer to that class in order to call a method of the class. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher Jeris Sent: Monday, July 23, 2007 1:51 PM To: accessd at databaseadvisors.com Subject: [AccessD] Can't call methods I've added to a form? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to build a set of forms according to MVC principles, and I think there's something fundamental I don't understand about Access form objects. Everything here is unbound forms, in Access 2002 sp3. I need to have "forms" that serve the same application role but present different user interfaces according to context, so I build a Controller object that creates different Form (view) objects depending on the context. But the Controller needs to tell the view to update itself in certain ways, so I have a method in the form's class like Public Sub InitializeFromBuffer(buffer As DataModelObject) and then the controller's process for opening up the form goes something like Set Me.activeForm = OpenFormByContext(intendedFormClass As String, _ context As ContextInfo) If Not Me.activeForm Is Nothing Then ' it worked Set Me.activeForm.Controller = Me Me.activeForm.InitializeFromBuffer theBuffer ' FAILURE End If Now calling InitializeFromBuffer ... or any other public method I try to add to a Form object ... from outside that Form's own class ... results in an "Application-defined or object-defined error". Is it really not possible to add methods to a Form that get called from outside the Form -- or am I missing something obvious ? I suppose, since adding _properties_ seems to work okay, one kludgy workaround would be to give the Form a property that is its "view proxy object", which is a user-defined class where all the methods I want to add are located, and call methods through the view proxy object ... but I'd rather say what I mean. thanks, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpOp35ICCNV0oGWARAiGDAJ9DwZIZ+eo3V/MsLOxBaT2/Y5wzwACgmb4+ j5Xtsy7ZmlM6bOkXXzOS3QY= =rjCB -----END PGP SIGNATURE----- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From garykjos at gmail.com Mon Jul 23 13:21:15 2007 From: garykjos at gmail.com (Gary Kjos) Date: Mon, 23 Jul 2007 13:21:15 -0500 Subject: [AccessD] OT: VB6 datarepeater control and checkboxes (Cross posted) In-Reply-To: <007301c7ccd4$05f73a90$6600a8c0@TheWaddles> References: <007301c7ccd4$05f73a90$6600a8c0@TheWaddles> Message-ID: Hi Kevin; This question would be appropriate for our VB list. You can subscribe to that list here; http://databaseadvisors.com/mailman/listinfo/dba-vb Gary Kjos AccessD Moderator On 7/22/07, Kevin Waddle wrote: > I apologize for the OT post. > > I am trying to recreate an Access continuous form in a VB6 exe using the > datarepeater control. > > I have created a ActiveX control containing a TextBox and a CheckBox. > These are bound to an Access mdb file. > I can display and update the textbox but cannot get anything to display > properly on the checkboxes. > > The control will display the checkbox as true only when the record is > active. > > Does anyone have an example using the datarepeater control with a checkbox > or another avenue to create a continuous form in VB6? > > Thank you, > Kevin > > > > Catscan: a hi-tech device for examining cats. > > -- > 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 cjeris at fas.harvard.edu Mon Jul 23 13:39:19 2007 From: cjeris at fas.harvard.edu (Christopher Jeris) Date: Mon, 23 Jul 2007 14:39:19 -0400 Subject: [AccessD] Can't call methods I've added to a form? In-Reply-To: <20070723181833.72D1AC15C@smtp-auth.no-ip.com> References: <20070723181833.72D1AC15C@smtp-auth.no-ip.com> Message-ID: <46A4F5D7.8020006@fas.harvard.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jwcolby wrote: > You don't say how you are calling the form's method. You have to specify > the form object, then the method so... > > Forms("MyForm").InitializeFromBuffer SomeParam > > Alternatively: > > Dim frm as form > set frm=forms("MyForm") > frm.InitializeFromBuffer SomeParam > > Remember that a form's code is a class and you have to get a pointer to that > class in order to call a method of the class. I constructed a toy example based on your suggestion, and it seems like the actual problem was related to what you're describing: some things were declared Friend that should have been Public. Thanks for your input! peace, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpPXX5ICCNV0oGWARAoEpAJwOlQk6et82vflCKRlw4k/n1WxnjwCfZReN ixeEOhj3eGG7NxpHuqJqO8A= =poCW -----END PGP SIGNATURE----- From bheygood at abestsystems.com Mon Jul 23 14:21:37 2007 From: bheygood at abestsystems.com (Bob Heygood) Date: Mon, 23 Jul 2007 12:21:37 -0700 Subject: [AccessD] OT: Deal of the Day In-Reply-To: <004801c7cae5$6b62d830$0301a8c0@HAL9005> References: <004801c7cae5$6b62d830$0301a8c0@HAL9005> Message-ID: <008101c7cd5e$b09f0560$6401a8c0@speedy> I remember looking at that exact ad and seeing further down on the page Win Vista Something for $$$. How in the hell can they "give" the computer away soo cheap??? Or does Bill G "give" away his OS to some??? Bob Heygood -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Friday, July 20, 2007 8:48 AM To: dba-ot at databaseadvisors.com; 'Access Developers discussion and problem solving' Subject: [AccessD] OT: Deal of the Day Today at Fry's: GQ5140 computer - Celeron D 352, 512K L2 Cache, 3.2GHz, 533 MHz FSB, 512MB RAM, 80GB 7200RPM SATA HD, DVD/CD-RW combo, Windows Vista Home (boo)... $149.00. How do they make any money on this? Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Mon Jul 23 14:23:18 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 23 Jul 2007 15:23:18 -0400 Subject: [AccessD] Can't call methods I've added to a form? In-Reply-To: <46A4F5D7.8020006@fas.harvard.edu> Message-ID: <20070723192328.31C12BDB6@smtp-auth.no-ip.com> Glad I could help. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Christopher Jeris Sent: Monday, July 23, 2007 2:39 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Can't call methods I've added to a form? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jwcolby wrote: > You don't say how you are calling the form's method. You have to > specify the form object, then the method so... > > Forms("MyForm").InitializeFromBuffer SomeParam > > Alternatively: > > Dim frm as form > set frm=forms("MyForm") > frm.InitializeFromBuffer SomeParam > > Remember that a form's code is a class and you have to get a pointer > to that class in order to call a method of the class. I constructed a toy example based on your suggestion, and it seems like the actual problem was related to what you're describing: some things were declared Friend that should have been Public. Thanks for your input! peace, Chris Jeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpPXX5ICCNV0oGWARAoEpAJwOlQk6et82vflCKRlw4k/n1WxnjwCfZReN ixeEOhj3eGG7NxpHuqJqO8A= =poCW -----END PGP SIGNATURE----- -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From reuben at gfconsultants.com Mon Jul 23 14:35:56 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Mon, 23 Jul 2007 15:35:56 -0400 Subject: [AccessD] check for file in ftp site Message-ID: I am wanting to log into an ftp site, look thru all the txt files (only txt files), and download all files that are new since the last check. The files are all numbered sequentially so I can parse out the numbers to determine what files are new. However, I could use some assistance in looping thru the txt file names. Thanks. Reuben Cummings GFC, LLC 812.523.1017 From shamil at users.mns.ru Mon Jul 23 14:57:01 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Mon, 23 Jul 2007 23:57:01 +0400 Subject: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997and MSA 2000 and MSA2003? In-Reply-To: Message-ID: <001001c7cd63$a3691de0$6401a8c0@nant> Thank you Charlotte! - I'd avoid having MS Access 2003 and 2007 on the same PC.... -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Monday, July 23, 2007 7:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997and MSA 2000 and MSA2003? Shamil, The other versions work all right, but the big pain is the installer running when you switch back to 2003 or 2007. The 2003 installer doesn't take overly long, but the 2007 installer takes a YEAR!! I've had some problems with some of my earlier dbs in 2007, depending on how creative I had been when I built them. Since I spend so little time in Access, now, I haven't really exercised it. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: Sunday, July 22, 2007 2:03 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine withMSA1997 and MSA 2000 and MSA2003? Hello Steve, Thank you for your answer! Besides this issue of switching between running (?) instances of different MS Access versions are there any problems with previous version of MS Access or MS Access 2007 getting somehow stuck when working together on the same system? BTW, can one run MS Access 97 program databases on MS Access 2007? (Sorry no time to test here currently and I do not have MS Access 97 installed to make a good test database to run it on MS Access 2007)... Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Sunday, July 22, 2007 12:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Does MSA2007 behaves well if on a machine with MSA1997 and MSA 2000 and MSA2003? Shamil, More of an annoyance, rather than a serious misbehaviour, but there is a problem with an extremely long delay in the process when you switch between using Access 2007 and other versions. Regards Steve Shamil Salakhetdinov wrote: > Do you know if MSA2007 behaves well if on a machine with MSA 1997 and > MSA 2000 and MSA2003 on it? (Of course all the mentioned above MS > Access versions will be installed into different folders and in > chronological order > of their release dates). -- 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 markamatte at hotmail.com Mon Jul 23 15:25:01 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Mon, 23 Jul 2007 20:25:01 +0000 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: Sending You a zip file offline. >From: "Reuben Cummings" >Reply-To: Access Developers discussion and problem >solving >To: "AccessD" >Subject: [AccessD] check for file in ftp site >Date: Mon, 23 Jul 2007 15:35:56 -0400 > >I am wanting to log into an ftp site, look thru all the txt files (only txt >files), and download all files that are new since the last check. > >The files are all numbered sequentially so I can parse out the numbers to >determine what files are new. > >However, I could use some assistance in looping thru the txt file names. > >Thanks. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://newlivehotmail.com From darrend at nimble.com.au Mon Jul 23 20:31:58 2007 From: darrend at nimble.com.au (Darren D) Date: Tue, 24 Jul 2007 11:31:58 +1000 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: <200707240131.l6O1Vw7E007197@databaseadvisors.com> Hi Mark Would love to see a copy as well - thanks DD -----Original Message----- From: Mark A Matte [mailto:markamatte at hotmail.com] Sent: Tuesday, 24 July 2007 6:25 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] check for file in ftp site Sending You a zip file offline. >From: "Reuben Cummings" >Reply-To: Access Developers discussion and problem >solving >To: "AccessD" >Subject: [AccessD] check for file in ftp site >Date: Mon, 23 Jul 2007 15:35:56 -0400 > >I am wanting to log into an ftp site, look thru all the txt files (only txt >files), and download all files that are new since the last check. > >The files are all numbered sequentially so I can parse out the numbers to >determine what files are new. > >However, I could use some assistance in looping thru the txt file names. > >Thanks. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://newlivehotmail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From thewaddles at sbcglobal.net Mon Jul 23 20:55:23 2007 From: thewaddles at sbcglobal.net (Kevin Waddle) Date: Mon, 23 Jul 2007 18:55:23 -0700 Subject: [AccessD] OT: VB6 datarepeater control and checkboxes (Crossposted) In-Reply-To: References: <007301c7ccd4$05f73a90$6600a8c0@TheWaddles> Message-ID: <000501c7cd95$b3ab7d10$6600a8c0@TheWaddles> Garry, Thank you. I'll post the question there as soon as my registration is confirmed. Thanks, Kevin c'est la guere -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gary Kjos Sent: Monday, July 23, 2007 11:21 AM To: Access Developers discussion and problem solving Cc: ACCESS-L at peach.ease.lsoft.com Subject: Re: [AccessD] OT: VB6 datarepeater control and checkboxes (Crossposted) Hi Kevin; This question would be appropriate for our VB list. You can subscribe to that list here; http://databaseadvisors.com/mailman/listinfo/dba-vb Gary Kjos AccessD Moderator On 7/22/07, Kevin Waddle wrote: > I apologize for the OT post. > > I am trying to recreate an Access continuous form in a VB6 exe using > the datarepeater control. > > I have created a ActiveX control containing a TextBox and a CheckBox. > These are bound to an Access mdb file. > I can display and update the textbox but cannot get anything to > display properly on the checkboxes. > > The control will display the checkbox as true only when the record is > active. > > Does anyone have an example using the datarepeater control with a > checkbox or another avenue to create a continuous form in VB6? > > Thank you, > Kevin > > > > Catscan: a hi-tech device for examining cats. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- Gary Kjos garykjos at gmail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From reuben at gfconsultants.com Tue Jul 24 09:31:07 2007 From: reuben at gfconsultants.com (Reuben Cummings) Date: Tue, 24 Jul 2007 10:31:07 -0400 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: Thanks, Mark. Reuben Cummings GFC, LLC 812.523.1017 > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte > Sent: Monday, July 23, 2007 4:25 PM > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] check for file in ftp site > > > Sending You a zip file offline. > > > >From: "Reuben Cummings" > >Reply-To: Access Developers discussion and problem > >solving > >To: "AccessD" > >Subject: [AccessD] check for file in ftp site > >Date: Mon, 23 Jul 2007 15:35:56 -0400 > > > >I am wanting to log into an ftp site, look thru all the txt > files (only txt > >files), and download all files that are new since the last check. > > > >The files are all numbered sequentially so I can parse out the numbers to > >determine what files are new. > > > >However, I could use some assistance in looping thru the txt file names. > > > >Thanks. > > > >Reuben Cummings > >GFC, LLC > >812.523.1017 > > > > > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.com > > _________________________________________________________________ > http://newlivehotmail.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From doug at starntech.com Tue Jul 24 09:49:10 2007 From: doug at starntech.com (Doug Barnes) Date: Tue, 24 Jul 2007 10:49:10 -0400 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: Would love to see a copy, as well Douglas Barnes Starn Technical Services P.O. Box 1172 15957 Conneaut Lake Road, Suite 7 Meadville, PA 16335 doug at starntech.com P: 814.724.1045 F: 814.337.3460 -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte Sent: Monday, July 23, 2007 4:25 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] check for file in ftp site Sending You a zip file offline. >From: "Reuben Cummings" >Reply-To: Access Developers discussion and problem >solving >To: "AccessD" >Subject: [AccessD] check for file in ftp site >Date: Mon, 23 Jul 2007 15:35:56 -0400 > >I am wanting to log into an ftp site, look thru all the txt files (only txt >files), and download all files that are new since the last check. > >The files are all numbered sequentially so I can parse out the numbers to >determine what files are new. > >However, I could use some assistance in looping thru the txt file names. > >Thanks. > >Reuben Cummings >GFC, LLC >812.523.1017 > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ http://newlivehotmail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From JHewson at karta.com Tue Jul 24 09:55:26 2007 From: JHewson at karta.com (Jim Hewson) Date: Tue, 24 Jul 2007 09:55:26 -0500 Subject: [AccessD] Primary Key Best Practices Message-ID: I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. From jwcolby at colbyconsulting.com Tue Jul 24 10:04:50 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 24 Jul 2007 11:04:50 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070724150501.001B0BD13@smtp-auth.no-ip.com> LOL, here we go again. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue Jul 24 10:09:58 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 24 Jul 2007 08:09:58 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: There are good arguments for 1. is you're using SQL Server, since you can't update those tables from the FE unless they have a PK. 4. seems to be a justification for 2. rather than a real rule of thumb. An autonumber, etc., will always uniquely identify a row, but if you have to create a unique key on that table anyhow using several fields, that gives you TWO unique keys on the same row, which can be argued about endlessly (and has, here! LOL). 3. ignores the fact that junction/join tables often or perhaps usually use the PKs from the tables being joined to uniquely identify the record and form a natural PK. Just my opinions, of course. ;> Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 7:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue Jul 24 10:10:25 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 24 Jul 2007 08:10:25 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070724150501.001B0BD13@smtp-auth.no-ip.com> References: <20070724150501.001B0BD13@smtp-auth.no-ip.com> Message-ID: Head for the storm cellar, quick!!! Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 8:05 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices LOL, here we go again. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim 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 JHewson at karta.com Tue Jul 24 10:24:23 2007 From: JHewson at karta.com (Jim Hewson) Date: Tue, 24 Jul 2007 10:24:23 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <20070724150501.001B0BD13@smtp-auth.no-ip.com> Message-ID: That's where I'm at now! And the rain is coming in! Jim jhewson at karta.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Tuesday, July 24, 2007 10:10 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Head for the storm cellar, quick!!! Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 8:05 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices LOL, here we go again. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim 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 markamatte at hotmail.com Tue Jul 24 10:25:16 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 24 Jul 2007 15:25:16 +0000 Subject: [AccessD] check for file in ftp site In-Reply-To: Message-ID: Hello All, I am more than happy to send almost anything to almost anyone...but as we are getting back into some of our Netiquette Practices...please send any other "Me Too"'s to me directly...to lessen the List traffic. Thanks, Mark A. Matte P.S...Doug, I sent you a copy already...good luck...its just an ugly scrapped together example. >From: "Doug Barnes" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] check for file in ftp site >Date: Tue, 24 Jul 2007 10:49:10 -0400 > >Would love to see a copy, as well > > >Douglas Barnes > >Starn Technical Services >P.O. Box 1172 >15957 Conneaut Lake Road, Suite 7 >Meadville, PA 16335 > >doug at starntech.com >P: 814.724.1045 >F: 814.337.3460 > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte >Sent: Monday, July 23, 2007 4:25 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] check for file in ftp site > > >Sending You a zip file offline. > > > >From: "Reuben Cummings" > >Reply-To: Access Developers discussion and problem > >solving > >To: "AccessD" > >Subject: [AccessD] check for file in ftp site > >Date: Mon, 23 Jul 2007 15:35:56 -0400 > > > >I am wanting to log into an ftp site, look thru all the txt files (only >txt > >files), and download all files that are new since the last check. > > > >The files are all numbered sequentially so I can parse out the numbers to > >determine what files are new. > > > >However, I could use some assistance in looping thru the txt file names. > > > >Thanks. > > > >Reuben Cummings > >GFC, LLC > >812.523.1017 > > > > > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.com > >_________________________________________________________________ >http://newlivehotmail.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 _________________________________________________________________ Need a brain boost? Recharge with a stimulating game. Play now!? http://club.live.com/home.aspx?icid=club_hotmailtextlink1 From jimdettman at verizon.net Tue Jul 24 10:30:03 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Tue, 24 Jul 2007 11:30:03 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <000301c7ce07$81d373c0$8abea8c0@XPS> Groan...I guess I'll stick my neck out a bit. <<1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table.>> Yes, so a record is always uniquely identified. <<2. PKs should always be an autonumber (Access), Identity (SQL) or GUID.>> I don't agree with that 100%. Surrogate keys are in widespread use and for most tables are used 98% of the time in today's designs, but I think it's really silly to add a surrogate key to a many to many linking table when you already have a FK pair that must be unique and would serve perfectly well as a PK. <<3. Avoid complex PKs such as two PKs from two other tables.>> Don't agree in regards to M-M linking tables. <<4. Avoid complex PKs such as two fields from one table.>> If your in the surrogate key world, this doesn't ever apply. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Tue Jul 24 10:50:24 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 24 Jul 2007 11:50:24 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070724155034.B9365BCC8@smtp-auth.no-ip.com> I always and only use autonumber type PKs. I differentiate between PKs and unique indexes, whereas many people do not. A unique index's job is to prevent the same "unique" data from going into the table twice. A PK's job is to act as a pointer to a specific record and to allow EFFICIENT joins between tables (act as a pointer). Those are two completely different functions, and they BOTH must be addressed, but they do NOT have to be addressed in the same structure. In fact the EFFICIENT join PREVENTS them being addressed in the same structure! Pulling fields from parent / grandparent / greatgrandparent/greatgreatgreatgreatgreat...grandparent tables down into the current table just causes a slew of problems, from performance to update issues. Autoincrement PKs neatly sidestep all of those problems. In my experience, most of those who demand natural keys use "convenience" reasons such as "I can always look in any table and see where the data comes from or who owns the data (lineage). True, but irrelevant. That is laziness, not requirement. I have also heard a lot of arguments like "if parent records are deleted I can still see who the data belongs to". True but irrelevant. That is again laziness (too lazy / sloppy to implement RI). I do not allow parents to be deleted unless children are deleted. I have been doing this a long time and NEVER REQUIRED a natural key, and in fact AFAICR have never built a table with a natural key. Now I will grant there is a gray area such as "colors" where the color is the only "value" field in the table and so "why not" use it as the PK. The answer comes back to speed issues. Integers are faster to deal with inside of a computer when doing things like joins. Thus even in such cases I use autonumber PKs. I can tell you that I have been doing databases since 1995 and have never, in even one case, REQUIRED a natural key. I DO require unique indexes just as anyone else will. Just my opinion, ymmv etc. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Tue Jul 24 11:14:18 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Tue, 24 Jul 2007 09:14:18 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070724155034.B9365BCC8@smtp-auth.no-ip.com> References: <20070724155034.B9365BCC8@smtp-auth.no-ip.com> Message-ID: Yes, John, we know. Now wipe the foam off your lips and lie down quietly until the fit passes. LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 8:50 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I always and only use autonumber type PKs. I differentiate between PKs and unique indexes, whereas many people do not. A unique index's job is to prevent the same "unique" data from going into the table twice. A PK's job is to act as a pointer to a specific record and to allow EFFICIENT joins between tables (act as a pointer). Those are two completely different functions, and they BOTH must be addressed, but they do NOT have to be addressed in the same structure. In fact the EFFICIENT join PREVENTS them being addressed in the same structure! Pulling fields from parent / grandparent / greatgrandparent/greatgreatgreatgreatgreat...grandparent tables down into the current table just causes a slew of problems, from performance to update issues. Autoincrement PKs neatly sidestep all of those problems. In my experience, most of those who demand natural keys use "convenience" reasons such as "I can always look in any table and see where the data comes from or who owns the data (lineage). True, but irrelevant. That is laziness, not requirement. I have also heard a lot of arguments like "if parent records are deleted I can still see who the data belongs to". True but irrelevant. That is again laziness (too lazy / sloppy to implement RI). I do not allow parents to be deleted unless children are deleted. I have been doing this a long time and NEVER REQUIRED a natural key, and in fact AFAICR have never built a table with a natural key. Now I will grant there is a gray area such as "colors" where the color is the only "value" field in the table and so "why not" use it as the PK. The answer comes back to speed issues. Integers are faster to deal with inside of a computer when doing things like joins. Thus even in such cases I use autonumber PKs. I can tell you that I have been doing databases since 1995 and have never, in even one case, REQUIRED a natural key. I DO require unique indexes just as anyone else will. Just my opinion, ymmv etc. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim 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 jwcolby at colbyconsulting.com Tue Jul 24 11:52:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 24 Jul 2007 12:52:23 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070724165233.E45B0BE8D@smtp-auth.no-ip.com> ROTFLMAO. The fit never passes. It just subsides until the moon rises again. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Tuesday, July 24, 2007 12:14 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Yes, John, we know. Now wipe the foam off your lips and lie down quietly until the fit passes. LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 8:50 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I always and only use autonumber type PKs. I differentiate between PKs and unique indexes, whereas many people do not. A unique index's job is to prevent the same "unique" data from going into the table twice. A PK's job is to act as a pointer to a specific record and to allow EFFICIENT joins between tables (act as a pointer). Those are two completely different functions, and they BOTH must be addressed, but they do NOT have to be addressed in the same structure. In fact the EFFICIENT join PREVENTS them being addressed in the same structure! Pulling fields from parent / grandparent / greatgrandparent/greatgreatgreatgreatgreat...grandparent tables down into the current table just causes a slew of problems, from performance to update issues. Autoincrement PKs neatly sidestep all of those problems. In my experience, most of those who demand natural keys use "convenience" reasons such as "I can always look in any table and see where the data comes from or who owns the data (lineage). True, but irrelevant. That is laziness, not requirement. I have also heard a lot of arguments like "if parent records are deleted I can still see who the data belongs to". True but irrelevant. That is again laziness (too lazy / sloppy to implement RI). I do not allow parents to be deleted unless children are deleted. I have been doing this a long time and NEVER REQUIRED a natural key, and in fact AFAICR have never built a table with a natural key. Now I will grant there is a gray area such as "colors" where the color is the only "value" field in the table and so "why not" use it as the PK. The answer comes back to speed issues. Integers are faster to deal with inside of a computer when doing things like joins. Thus even in such cases I use autonumber PKs. I can tell you that I have been doing databases since 1995 and have never, in even one case, REQUIRED a natural key. I DO require unique indexes just as anyone else will. Just my opinion, ymmv etc. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson Sent: Tuesday, July 24, 2007 10:55 AM To: Access Developers discussion and problem solving Subject: [AccessD] Primary Key Best Practices I need a few good references (preferably electronic) on the Best Practices for defining Primary Keys (PK) Here at the office we have had a few heated discussions about primary keys. I don't' mean to stir the pot on this list, just curious what others think. 1. All tables should have a primary key even though it will not be used as a foreign key (FK) in another table. 2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. 3. Avoid complex PKs such as two PKs from two other tables. 4. Avoid complex PKs such as two fields from one table. You could probably come up with some more. Thanks, Jim 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 dwaters at usinternet.com Tue Jul 24 12:01:45 2007 From: dwaters at usinternet.com (Dan Waters) Date: Tue, 24 Jul 2007 12:01:45 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? Message-ID: <004101c7ce14$5117cad0$0200a8c0@danwaters> In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan From jwcolby at colbyconsulting.com Tue Jul 24 12:13:16 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 24 Jul 2007 13:13:16 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <004101c7ce14$5117cad0$0200a8c0@danwaters> Message-ID: <20070724171327.05A92BD62@smtp-auth.no-ip.com> You could reasonably quickly set up a test to find out by building a dynamic query, a string such as select PKID from tblX where (PKID=1 or PKID=2 or...). Add 10 (or 100) at a time and see how far you get. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 1:02 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Number of 'OR's in queries - what's the limit? In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Tue Jul 24 12:31:31 2007 From: dwaters at usinternet.com (Dan Waters) Date: Tue, 24 Jul 2007 12:31:31 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <20070724171327.05A92BD62@smtp-auth.no-ip.com> References: <004101c7ce14$5117cad0$0200a8c0@danwaters> <20070724171327.05A92BD62@smtp-auth.no-ip.com> Message-ID: <004201c7ce18$79e7cd80$0200a8c0@danwaters> That's a good plan! I was hoping to do a customer update within the next half hour though. I was hoping that someone had seen some documentation on this. The number 40 was documented 'somewhere' in Access help. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? You could reasonably quickly set up a test to find out by building a dynamic query, a string such as select PKID from tblX where (PKID=1 or PKID=2 or...). Add 10 (or 100) at a time and see how far you get. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 1:02 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Number of 'OR's in queries - what's the limit? In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan -- 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 markamatte at hotmail.com Tue Jul 24 13:22:36 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Tue, 24 Jul 2007 18:22:36 +0000 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <004201c7ce18$79e7cd80$0200a8c0@danwaters> Message-ID: I found it in A97 and A2002...search help for 'Specifications'...in 97 its query specs...and in 2002 its access specs...97 is 40...2002 is 99. I don't have 2003 to look. Good Luck, Mark A. Matte >From: "Dan Waters" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? >Date: Tue, 24 Jul 2007 12:31:31 -0500 > >That's a good plan! I was hoping to do a customer update within the next >half hour though. > >I was hoping that someone had seen some documentation on this. The number >40 was documented 'somewhere' in Access help. > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby >Sent: Tuesday, July 24, 2007 12:13 PM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > >You could reasonably quickly set up a test to find out by building a >dynamic >query, a string such as select PKID from tblX where (PKID=1 or PKID=2 >or...). Add 10 (or 100) at a time and see how far you get. > > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters >Sent: Tuesday, July 24, 2007 1:02 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Number of 'OR's in queries - what's the limit? > >In Access 97, there was a limit of 40 OR words in a query. There is a >limit >in Access 2003, it's >250, but I don't know what it actually is. > >Does anyone know? > >Thanks! >Dan > > > >-- >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 _________________________________________________________________ http://newlivehotmail.com From ebarro at verizon.net Tue Jul 24 13:45:02 2007 From: ebarro at verizon.net (Eric Barro) Date: Tue, 24 Jul 2007 11:45:02 -0700 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <004201c7ce18$79e7cd80$0200a8c0@danwaters> Message-ID: <0JLP007V75EOGYZ0@vms046.mailsrvcs.net> Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with Ors tend to take longer to execute. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? That's a good plan! I was hoping to do a customer update within the next half hour though. I was hoping that someone had seen some documentation on this. The number 40 was documented 'somewhere' in Access help. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? You could reasonably quickly set up a test to find out by building a dynamic query, a string such as select PKID from tblX where (PKID=1 or PKID=2 or...). Add 10 (or 100) at a time and see how far you get. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 1:02 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Number of 'OR's in queries - what's the limit? In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM From ssharkins at setel.com Tue Jul 24 13:47:49 2007 From: ssharkins at setel.com (Susan Harkins) Date: Tue, 24 Jul 2007 14:47:49 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <000301c7ce07$81d373c0$8abea8c0@XPS> References: <000301c7ce07$81d373c0$8abea8c0@XPS> Message-ID: <006c01c7ce23$22f5cda0$dc34fad1@SusanOne> I don't agree with that 100%. Surrogate keys are in widespread use and for most tables are used 98% of the time in today's designs, but I think it's really silly to add a surrogate key to a many to many linking table when you already have a FK pair that must be unique and would serve perfectly well as a PK. ======Other than habit -- consistency can be a good thing. Now to add to your list -- and you can thank Martin Reid for this additional few: PK should be stable. In real life, things do change, hence cascading updates, but use a key that's not prone to change. When using natural keys, choose the key with the fewest fields necessary -- I know that should be a given, but I've seen some that made me shake my head... :( Susan H. From EdTesiny at oasas.state.ny.us Tue Jul 24 14:04:15 2007 From: EdTesiny at oasas.state.ny.us (Tesiny, Ed) Date: Tue, 24 Jul 2007 15:04:15 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: References: <004201c7ce18$79e7cd80$0200a8c0@danwaters> Message-ID: Still looks like 99 in 2003 Ed Tesiny EdTesiny at oasas.state.ny.us > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > Mark A Matte > Sent: Tuesday, July 24, 2007 2:23 PM > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > I found it in A97 and A2002...search help for > 'Specifications'...in 97 its > query specs...and in 2002 its access specs...97 is 40...2002 is 99. > > I don't have 2003 to look. > > Good Luck, > > Mark A. Matte > > > >From: "Dan Waters" > >Reply-To: Access Developers discussion and problem > >solving > >To: "'Access Developers discussion and problem > >solving'" > >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > >Date: Tue, 24 Jul 2007 12:31:31 -0500 > > > >That's a good plan! I was hoping to do a customer update > within the next > >half hour though. > > > >I was hoping that someone had seen some documentation on > this. The number > >40 was documented 'somewhere' in Access help. > > > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > >Sent: Tuesday, July 24, 2007 12:13 PM > >To: 'Access Developers discussion and problem solving' > >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > > >You could reasonably quickly set up a test to find out by building a > >dynamic > >query, a string such as select PKID from tblX where (PKID=1 or PKID=2 > >or...). Add 10 (or 100) at a time and see how far you get. > > > > > >John W. Colby > >Colby Consulting > >www.ColbyConsulting.com > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > >Sent: Tuesday, July 24, 2007 1:02 PM > >To: 'Access Developers discussion and problem solving' > >Subject: [AccessD] Number of 'OR's in queries - what's the limit? > > > >In Access 97, there was a limit of 40 OR words in a query. > There is a > >limit > >in Access 2003, it's >250, but I don't know what it actually is. > > > >Does anyone know? > > > >Thanks! > >Dan > > > > > > > >-- > >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 > > _________________________________________________________________ > http://newlivehotmail.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From dwaters at usinternet.com Tue Jul 24 14:10:05 2007 From: dwaters at usinternet.com (Dan Waters) Date: Tue, 24 Jul 2007 14:10:05 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <0JLP007V75EOGYZ0@vms046.mailsrvcs.net> References: <004201c7ce18$79e7cd80$0200a8c0@danwaters> <0JLP007V75EOGYZ0@vms046.mailsrvcs.net> Message-ID: <005101c7ce26$3ec58680$0200a8c0@danwaters> Perhaps this will bypass the limit altogether! Thanks Eric! Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Tuesday, July 24, 2007 1:45 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with Ors tend to take longer to execute. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 10:32 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? That's a good plan! I was hoping to do a customer update within the next half hour though. I was hoping that someone had seen some documentation on this. The number 40 was documented 'somewhere' in Access help. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 24, 2007 12:13 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? You could reasonably quickly set up a test to find out by building a dynamic query, a string such as select PKID from tblX where (PKID=1 or PKID=2 or...). Add 10 (or 100) at a time and see how far you get. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Tuesday, July 24, 2007 1:02 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Number of 'OR's in queries - what's the limit? In Access 97, there was a limit of 40 OR words in a query. There is a limit in Access 2003, it's >250, but I don't know what it actually is. Does anyone know? Thanks! Dan -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dwaters at usinternet.com Tue Jul 24 14:10:05 2007 From: dwaters at usinternet.com (Dan Waters) Date: Tue, 24 Jul 2007 14:10:05 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: References: <004201c7ce18$79e7cd80$0200a8c0@danwaters> Message-ID: <005201c7ce26$3f1665a0$0200a8c0@danwaters> 2003 is also 99. But, using WHERE PKID IN (1,2,4,8, ...) looks like there will be no limit. We'll find out. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Tuesday, July 24, 2007 1:23 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? I found it in A97 and A2002...search help for 'Specifications'...in 97 its query specs...and in 2002 its access specs...97 is 40...2002 is 99. I don't have 2003 to look. Good Luck, Mark A. Matte >From: "Dan Waters" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? >Date: Tue, 24 Jul 2007 12:31:31 -0500 > >That's a good plan! I was hoping to do a customer update within the next >half hour though. > >I was hoping that someone had seen some documentation on this. The number >40 was documented 'somewhere' in Access help. > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby >Sent: Tuesday, July 24, 2007 12:13 PM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > >You could reasonably quickly set up a test to find out by building a >dynamic >query, a string such as select PKID from tblX where (PKID=1 or PKID=2 >or...). Add 10 (or 100) at a time and see how far you get. > > >John W. Colby >Colby Consulting >www.ColbyConsulting.com >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters >Sent: Tuesday, July 24, 2007 1:02 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Number of 'OR's in queries - what's the limit? > >In Access 97, there was a limit of 40 OR words in a query. There is a >limit >in Access 2003, it's >250, but I don't know what it actually is. > >Does anyone know? > >Thanks! >Dan > > > >-- >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 _________________________________________________________________ http://newlivehotmail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jmhecht at earthlink.net Tue Jul 24 16:22:10 2007 From: jmhecht at earthlink.net (Joe Hecht) Date: Tue, 24 Jul 2007 14:22:10 -0700 (GMT-07:00) Subject: [AccessD] Primary Key Best Practices Message-ID: <28691268.1185312130566.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> I anm digging a deep hole for this one. Looking out from stuff flying from JC's mountain fortress of code. -----Original Message----- >From: Jim Hewson >Sent: Jul 24, 2007 7:55 AM >To: Access Developers discussion and problem solving >Subject: [AccessD] Primary Key Best Practices > >I need a few good references (preferably electronic) on the Best >Practices for defining Primary Keys (PK) >Here at the office we have had a few heated discussions about primary >keys. >I don't' mean to stir the pot on this list, just curious what others >think. > >1. All tables should have a primary key even though it will not be used >as a foreign key (FK) in another table. >2. PKs should always be an autonumber (Access), Identity (SQL) or GUID. >3. Avoid complex PKs such as two PKs from two other tables. >4. Avoid complex PKs such as two fields from one table. > >You could probably come up with some more. > >Thanks, > >Jim H. > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Tue Jul 24 19:47:55 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 24 Jul 2007 17:47:55 -0700 Subject: [AccessD] Allow Edits Message-ID: <00ba01c7ce55$706e7e60$0301a8c0@HAL9005> Dear List: I have an unbound combo box on a form with a list of employees. If the current user chooses their own name (it's stored in a table, I can do a DLookup) then I allow additions and edits. If they don't choose their own name I set allow additions and edit to false. Works great that far. Problem is that the combo box isn't editable so after a name is chosen which is NOT the current user and AllowEdits is set to False, they can't choose another record. The combo box won't update. I tried putting Me.AllowEdits = True in the click event of the combo box but the click event is firing AFTER the ArfterUpdate event so that's not working. Brute force solution would be to disable all of the text boxes on the form if the chosen user isn't the current user and V.V. But is there a more elegant way? MTIA Rocky From ssharkins at setel.com Tue Jul 24 20:01:24 2007 From: ssharkins at setel.com (Susan Harkins) Date: Tue, 24 Jul 2007 21:01:24 -0400 Subject: [AccessD] Allow Edits In-Reply-To: <00ba01c7ce55$706e7e60$0301a8c0@HAL9005> References: <00ba01c7ce55$706e7e60$0301a8c0@HAL9005> Message-ID: <004501c7ce57$532c7e90$4eb82ad1@SusanOne> Problem is that the combo box isn't editable so after a name is chosen which is NOT the current user and AllowEdits is set to False, they can't choose another record. The combo box won't update. ========If you're inhibiting edits, why would you want to allow one? Susan H. From newsgrps at dalyn.co.nz Tue Jul 24 20:08:52 2007 From: newsgrps at dalyn.co.nz (David Emerson) Date: Wed, 25 Jul 2007 13:08:52 +1200 Subject: [AccessD] Allow Edits In-Reply-To: <004501c7ce57$532c7e90$4eb82ad1@SusanOne> References: <00ba01c7ce55$706e7e60$0301a8c0@HAL9005> <004501c7ce57$532c7e90$4eb82ad1@SusanOne> Message-ID: <20070725010904.OKUK9092.fep01.xtra.co.nz@Dalyn.dalyn.co.nz> Rocky, Put some code on the Enter event of the combo box to allow edits, then on the Exit event determine from the value of the combo box whether to set AllowEdits to true or false. Regards David Emerson Dalyn Software Ltd Wellington, New Zealand At 25/07/2007, you wrote: > >Problem is that the combo box isn't editable so after a name is chosen which >is NOT the current user and AllowEdits is set to False, they can't choose >another record. The combo box won't update. > >========If you're inhibiting edits, why would you want to allow one? > >Susan H. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Tue Jul 24 21:36:21 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 24 Jul 2007 19:36:21 -0700 Subject: [AccessD] Allow Edits In-Reply-To: <004501c7ce57$532c7e90$4eb82ad1@SusanOne> Message-ID: <00c201c7ce64$96757500$0301a8c0@HAL9005> If the person who logged in selects their own name then editing their own information is OK. Otherwise, they can look at anyone else's but not change it. (BTW, legacy application - I wouldn't have done it this way.) Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Tuesday, July 24, 2007 6:01 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Allow Edits Problem is that the combo box isn't editable so after a name is chosen which is NOT the current user and AllowEdits is set to False, they can't choose another record. The combo box won't update. ========If you're inhibiting edits, why would you want to allow one? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM From rockysmolin at bchacc.com Tue Jul 24 21:37:28 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 24 Jul 2007 19:37:28 -0700 Subject: [AccessD] Allow Edits In-Reply-To: <20070725010904.OKUK9092.fep01.xtra.co.nz@Dalyn.dalyn.co.nz> Message-ID: <00c301c7ce64$be484fd0$0301a8c0@HAL9005> David: Perfect! Enter and Exit versus Click and AfterUpdate. Who knew? Thanks so much for the quick response. My bacon been saved again! Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson Sent: Tuesday, July 24, 2007 6:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Allow Edits Rocky, Put some code on the Enter event of the combo box to allow edits, then on the Exit event determine from the value of the combo box whether to set AllowEdits to true or false. Regards David Emerson Dalyn Software Ltd Wellington, New Zealand At 25/07/2007, you wrote: > >Problem is that the combo box isn't editable so after a name is chosen >which is NOT the current user and AllowEdits is set to False, they >can't choose another record. The combo box won't update. > >========If you're inhibiting edits, why would you want to allow one? > >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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM From darrend at nimble.com.au Wed Jul 25 01:55:51 2007 From: darrend at nimble.com.au (Darren D) Date: Wed, 25 Jul 2007 16:55:51 +1000 Subject: [AccessD] Allow Edits In-Reply-To: <00c301c7ce64$be484fd0$0301a8c0@HAL9005> Message-ID: <200707250655.l6P6tmDu022599@databaseadvisors.com> Hi Rocky Glad you got it sorted In these situations where I DO want certain fields to be editable or visible - and others not I setup and interrogate the control's TAG property EG I set up the TAG to say something meaningful like "CanBeEnabled" etc Then in the relevant code I call something like this Private Sub ps_EnableSomeControls() Dim ctl as Control For each ctl in me.controls 'The whole form If ctl.TAG = "CanBeEnabled" then 'you can even set if ctl.type = XXX (EG disable all the combos etc) ctl.enabled = true 'or 'ctl.visible = true Else 'Can write an else here End if Next ctl End sub -----Original Message----- From: Rocky Smolin at Beach Access Software [mailto:rockysmolin at bchacc.com] Sent: Wednesday, 25 July 2007 12:37 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Allow Edits David: Perfect! Enter and Exit versus Click and AfterUpdate. Who knew? Thanks so much for the quick response. My bacon been saved again! Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson Sent: Tuesday, July 24, 2007 6:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Allow Edits Rocky, Put some code on the Enter event of the combo box to allow edits, then on the Exit event determine from the value of the combo box whether to set AllowEdits to true or false. Regards David Emerson Dalyn Software Ltd Wellington, New Zealand At 25/07/2007, you wrote: > >Problem is that the combo box isn't editable so after a name is chosen >which is NOT the current user and AllowEdits is set to False, they >can't choose another record. The combo box won't update. > >========If you're inhibiting edits, why would you want to allow one? > >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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bbruen at unwired.com.au Wed Jul 25 07:11:43 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Wed, 25 Jul 2007 22:11:43 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070724165233.E45B0BE8D@smtp-auth.no-ip.com> References: <20070724165233.E45B0BE8D@smtp-auth.no-ip.com> Message-ID: <200707252211.43659.bbruen@unwired.com.au> On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce From rockysmolin at bchacc.com Wed Jul 25 08:09:38 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Wed, 25 Jul 2007 06:09:38 -0700 Subject: [AccessD] Allow Edits In-Reply-To: <200707250655.l6P6tmDu022599@databaseadvisors.com> Message-ID: <001f01c7cebd$0e44a8f0$0301a8c0@HAL9005> Yeah, I always forget about that TAG property. I've used it before - to allow the user interrupt a long process for example by pressing a key. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D Sent: Tuesday, July 24, 2007 11:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Allow Edits Hi Rocky Glad you got it sorted In these situations where I DO want certain fields to be editable or visible - and others not I setup and interrogate the control's TAG property EG I set up the TAG to say something meaningful like "CanBeEnabled" etc Then in the relevant code I call something like this Private Sub ps_EnableSomeControls() Dim ctl as Control For each ctl in me.controls 'The whole form If ctl.TAG = "CanBeEnabled" then 'you can even set if ctl.type = XXX (EG disable all the combos etc) ctl.enabled = true 'or 'ctl.visible = true Else 'Can write an else here End if Next ctl End sub -----Original Message----- From: Rocky Smolin at Beach Access Software [mailto:rockysmolin at bchacc.com] Sent: Wednesday, 25 July 2007 12:37 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Allow Edits David: Perfect! Enter and Exit versus Click and AfterUpdate. Who knew? Thanks so much for the quick response. My bacon been saved again! Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David Emerson Sent: Tuesday, July 24, 2007 6:09 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Allow Edits Rocky, Put some code on the Enter event of the combo box to allow edits, then on the Exit event determine from the value of the combo box whether to set AllowEdits to true or false. Regards David Emerson Dalyn Software Ltd Wellington, New Zealand At 25/07/2007, you wrote: > >Problem is that the combo box isn't editable so after a name is chosen >which is NOT the current user and AllowEdits is set to False, they >can't choose another record. The combo box won't update. > >========If you're inhibiting edits, why would you want to allow one? > >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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 7:45 PM -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: 7/24/2007 1:50 PM From jwcolby at colbyconsulting.com Wed Jul 25 08:18:02 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 09:18:02 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707252211.43659.bbruen@unwired.com.au> Message-ID: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Bruce, >Any table that does not have a natural primary key is not a pure dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Wed Jul 25 09:14:14 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 10:14:14 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <006c01c7ce23$22f5cda0$dc34fad1@SusanOne> References: <000301c7ce07$81d373c0$8abea8c0@XPS> <006c01c7ce23$22f5cda0$dc34fad1@SusanOne> Message-ID: <00f801c7cec6$14e13b20$8abea8c0@XPS> Susan, True, but in the case of a M to M table your just introducing another column and a index that really is not needed. It seems silly to me to have something like: tblLinking LinkID - Autonumber - PK BookID - Long - CK1A AuthorID - Long - CK1B Instead of tblLinking BookID - Long - PK1A AuthorID - Long - PK1B just for the sake of having an auto number in there. The BookID and AuthorID already form a unique pair and they typically would not be used as a foreign key in another table. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Tuesday, July 24, 2007 2:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I don't agree with that 100%. Surrogate keys are in widespread use and for most tables are used 98% of the time in today's designs, but I think it's really silly to add a surrogate key to a many to many linking table when you already have a FK pair that must be unique and would serve perfectly well as a PK. ======Other than habit -- consistency can be a good thing. Now to add to your list -- and you can thank Martin Reid for this additional few: PK should be stable. In real life, things do change, hence cascading updates, but use a key that's not prone to change. When using natural keys, choose the key with the fewest fields necessary -- I know that should be a given, but I've seen some that made me shake my head... :( Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 09:35:27 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 10:35:27 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Message-ID: <20070725143539.6CA22BD0E@smtp-auth.no-ip.com> >So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. And I forgot to add: 3) Should be efficient, which is where the autoincrement shines. Integers are the basic currency of the modern CPU and as such they are the fastest possible unit of information when doing compares. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure >dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 Jul 25 09:42:00 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 10:42:00 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> References: <200707252211.43659.bbruen@unwired.com.au> <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Message-ID: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> John, <<1) The PK should be stable (NEVER changes). >> Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. <> That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. In theory you cannot have a PK without it being a unique index. That's part of the definition of what a natural PK is. Out of the pool of CK's, you would use the CK that is the most stable, shortest in length, and the least complex (simple vs compound). <> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. Surrogate keys work well in computer systems, but the relational model can be applied to much more then computer systems and the PK as you describe it vs what it is in the relational model are not the same thing. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 cfoust at infostatsystems.com Wed Jul 25 09:57:17 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 07:57:17 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707252211.43659.bbruen@unwired.com.au> References: <20070724165233.E45B0BE8D@smtp-auth.no-ip.com> <200707252211.43659.bbruen@unwired.com.au> Message-ID: Troublemaker!! LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 5:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 09:59:38 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 07:59:38 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> References: <200707252211.43659.bbruen@unwired.com.au><20070725131815.187FDBD8E@smtp-auth.no-ip.com> <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: Jim, I'm going to flag your post for future reference ... and the next time the moon is full! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 25, 2007 7:42 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <<1) The PK should be stable (NEVER changes). >> Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. <> That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. In theory you cannot have a PK without it being a unique index. That's part of the definition of what a natural PK is. Out of the pool of CK's, you would use the CK that is the most stable, shortest in length, and the least complex (simple vs compound). <> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. Surrogate keys work well in computer systems, but the relational model can be applied to much more then computer systems and the PK as you describe it vs what it is in the relational model are not the same thing. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure >dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 setel.com Wed Jul 25 10:17:50 2007 From: ssharkins at setel.com (Susan Harkins) Date: Wed, 25 Jul 2007 11:17:50 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> References: <200707252211.43659.bbruen@unwired.com.au><20070725131815.187FDBD8E@smtp-auth.no-ip.com> <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: <002a01c7cece$f7b5a550$2c34fad1@SusanOne> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. =======If we didn't have reliable systems, we wouldn't be using relational databases. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. =======You have the original model and you have what is currently in practice. If the relational model, as originally devised, can't change, then you're right. But, in practice, it absolutely has changed. Susan H From jwcolby at colbyconsulting.com Wed Jul 25 10:19:00 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 11:19:00 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Jim, >Surrogate keys are nothing more then pointers. Correct!!!!!!!!!!!!!!!!!!!!!!!!!! This is a logical construct Jim. You accept that a PK can be a surrogate, you state that a PK is nothing but a pointer, therefore you accept (and state) that a PK is nothing but a pointer. AND... from the perspective of the child, a FK is nothing but a pointer. Does a table HAVE TO HAVE a PK at all? Not if it has no children. Ergo, what matters from the child's perspective is what the PK is all about, and that is simply a POINTER back to the parent. AND... Since a surrogate key functions as a PK, then... A PK must be nothing but a pointer... > Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. And I don't give a rat's patuty about relational theory, I care about what works. Relational theory says you should normalize to 16 (IIRC) different levels. When was the last time you did that? Do you even UNDERSTAND 9th (or 12th, or 16th) normal form? OK YOU probably do but I don't and don't care that I don't. So day in and day out you (or at least I) ignore relational theory and yet you attempt to flaunt that same theory in the great PK debate for what purpose??? Having the PK change is a no-no. Sorry, it just is. It causes a whole host of issues and given that it doesn't HAVE to change.... >That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. And I don't give a rat's patuty about relational theory, I care about what works. >Surrogates only work in computer systems because we have systems that are reliable. But we do, so what's your point? Natural keys only work (in large systems) because we have systems that are reliable. Imagine trying to manually correct 100 million records where something got corrupted. No easier (without a reliable system). I have NEVER used paper and pencil in a database so who really cares. >To call them a PK in regards to the relational model is simply incorrect. OK, and who cares? I simply do not care about the relational model (in this debate), I care about what works efficiently. I use what works (of the model) and I abandon what is inefficient (natural keys). Natural keys are NOT A REQUIREMENT, you admit that yourself. I still have a PK, it is just a surrogate. If you accept that surrogates do work then why does the insistence in relational model PK being a natural key even matter? You are nitpicking to death stuff that simply does not matter. If you want to insist that the PK HAS TO BE a natural key, then how can you say in the next breath that "I don't object to the use of surrogate keys" C'mon Jim, give it up. I will sign a piece of paper stating whatever you want about PKs and natural keys and relational theory, I simply DO NOT CARE. What I care about is that they are inefficient and cause problems that surrogate keys avoid. Happy? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 25, 2007 10:42 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <<1) The PK should be stable (NEVER changes). >> Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. <> That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. In theory you cannot have a PK without it being a unique index. That's part of the definition of what a natural PK is. Out of the pool of CK's, you would use the CK that is the most stable, shortest in length, and the least complex (simple vs compound). <> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. Surrogate keys work well in computer systems, but the relational model can be applied to much more then computer systems and the PK as you describe it vs what it is in the relational model are not the same thing. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure >dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 john at winhaven.net Wed Jul 25 10:30:32 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 10:30:32 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00f801c7cec6$14e13b20$8abea8c0@XPS> References: <000301c7ce07$81d373c0$8abea8c0@XPS><006c01c7ce23$22f5cda0$dc34fad1@SusanOne> <00f801c7cec6$14e13b20$8abea8c0@XPS> Message-ID: <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> Jim, This is something I haven't seen before and is in my early morning mind, quite brilliant! Are there any drawbacks to doing this? I can't imagine it would be much of a difference (size or performance wise) in any of my applications / databases but it is certainly something worth considering implementing in the future. Always open to technical improvements... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman True, but in the case of a M to M table your just introducing another column and a index that really is not needed. It seems silly to me to have something like: tblLinking LinkID - Autonumber - PK BookID - Long - CK1A AuthorID - Long - CK1B Instead of tblLinking BookID - Long - PK1A AuthorID - Long - PK1B just for the sake of having an auto number in there. The BookID and AuthorID already form a unique pair and they typically would not be used as a foreign key in another table. From john at winhaven.net Wed Jul 25 10:30:32 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 10:30:32 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> References: <200707252211.43659.bbruen@unwired.com.au> <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Message-ID: <010f01c7ced0$bf524db0$6402a8c0@ScuzzPaq> While I agree with you on the subject matter at hand - I don't recall seeing this as criteria for a primary key before. Is this a Colbyism or am I just not quite awake yet? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. From jwelz at hotmail.com Wed Jul 25 10:39:11 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Wed, 25 Jul 2007 09:39:11 -0600 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: Jim: I'm generally with John on this one. The question was about best practices, not relational theory. Every comment you made to John was about relational theory. This is about computer databases; about 'Practices', not 'Theory'. In practice, you can not beat an autonumber for size and speed (performance) in a computer environment. Apply it consistently in conjuction with any other unique indexes on fields or combinations of fields you identify as candidate keys and no user can mess up any more than they possibly could using any other key. None of the 'Theory' comments impact the practical utility and validity of using a unique long or GUID as a primary key. If occasionally you have a key that will likely not be used in a join, at least you retain the flexibilty should the unforseen arise. In terms of additional space wasted for the case where such a key is never used in a join, it is the smallest amout possible for the flexiblity and consistency gained. That sounds like a best practice to me. Regardless of whether anyone agrees with me, it is my practice because it works well. You won't hear from mea again on this topic this year. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Jim Dettman" > >John, > ><<1) The PK should be stable (NEVER changes). >> > > Don' agree with "never". You want it as stable as possible, but there >is >nothing in relational theory that says it can never change. > ><real life or in theory.>> > > That is simply not true. With relational theory, the PK is derived from >the pool of CK's, which is based on the data. In theory you cannot have a >PK without it being a unique index. That's part of the definition of what >a >natural PK is. Out of the pool of CK's, you would use the CK that is the >most stable, shortest in length, and the least complex (simple vs >compound). > ><surrogate key avoids a whole slew of real life problems, and creates none >(in my experience).>> > > Surrogates only work in computer systems because we have systems that >are >reliable. If I gave you pen and paper and had you keep track of data using >the relational model, you'd be in a pretty big mess fairly quick if you >used >surrogate keys. > > I don't object to the use of surrogate keys, but what I do object to is >the apples and oranges approach you use to claim what a PK is and surrogate >keys fit in the relational model. Surrogate keys are nothing more then >pointers. To call them a PK in regards to the relational model is simply >incorrect. > > Surrogate keys work well in computer systems, but the relational model >can >be applied to much more then computer systems and the PK as you describe it >vs what it is in the relational model are not the same thing. > >Jim. _________________________________________________________________ Fight Allergies With Live Search http://search.live.com/results.aspx?q=Remedies+For+Spring+Allergies&mkt=en-ca&FORM=SERNEP From jwcolby at colbyconsulting.com Wed Jul 25 10:46:23 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 11:46:23 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <010f01c7ced0$bf524db0$6402a8c0@ScuzzPaq> Message-ID: <20070725154636.092FDBCB9@smtp-auth.no-ip.com> John, This is definitely a Colbyism. Basically I make no claim to making any of this stuff up. I am a logical person, I do what works most efficiently whenever I can. Did I make that up? Probably not. It comes from discussions here on this list where any time you expose the PK to view, some idiot wants to use it for some purpose that it is not supposed to be used for (like a "must be in order, with no values missing" number in an accounting system. Obviously we can and do delete records all the time so using the PK for such a rule / purpose guarantees issues whenever the idiot strikes, thus simply NEVER expose it to view. The PK's function (in real life) is exactly and only for use as a pointer from a child back to the parent. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 11:31 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices While I agree with you on the subject matter at hand - I don't recall seeing this as criteria for a primary key before. Is this a Colbyism or am I just not quite awake yet? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 10:48:55 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 11:48:55 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> Jurgen, Why can't I state it in such reasoned and logical terms? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 25, 2007 11:39 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Jim: I'm generally with John on this one. The question was about best practices, not relational theory. Every comment you made to John was about relational theory. This is about computer databases; about 'Practices', not 'Theory'. In practice, you can not beat an autonumber for size and speed (performance) in a computer environment. Apply it consistently in conjuction with any other unique indexes on fields or combinations of fields you identify as candidate keys and no user can mess up any more than they possibly could using any other key. None of the 'Theory' comments impact the practical utility and validity of using a unique long or GUID as a primary key. If occasionally you have a key that will likely not be used in a join, at least you retain the flexibilty should the unforseen arise. In terms of additional space wasted for the case where such a key is never used in a join, it is the smallest amout possible for the flexiblity and consistency gained. That sounds like a best practice to me. Regardless of whether anyone agrees with me, it is my practice because it works well. You won't hear from mea again on this topic this year. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.com From jimdettman at verizon.net Wed Jul 25 10:53:01 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 11:53:01 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <002a01c7cece$f7b5a550$2c34fad1@SusanOne> References: <200707252211.43659.bbruen@unwired.com.au><20070725131815.187FDBD8E@smtp-auth.no-ip.com> <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <002a01c7cece$f7b5a550$2c34fad1@SusanOne> Message-ID: <012401c7ced3$e1e12b00$8abea8c0@XPS> Susan, <> Well the model hasn't changed that I'm aware of, but your right, it has changed in practice. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 11:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. =======If we didn't have reliable systems, we wouldn't be using relational databases. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. =======You have the original model and you have what is currently in practice. If the relational model, as originally devised, can't change, then you're right. But, in practice, it absolutely has changed. Susan H -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Wed Jul 25 11:01:51 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 11:01:51 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> References: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> Message-ID: <013f01c7ced5$1ed88250$6402a8c0@ScuzzPaq> emotional response? too much caffiene? ... ;o) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Jurgen, Why can't I state it in such reasoned and logical terms? John W. Colby From john at winhaven.net Wed Jul 25 11:10:38 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 11:10:38 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725154636.092FDBCB9@smtp-auth.no-ip.com> References: <010f01c7ced0$bf524db0$6402a8c0@ScuzzPaq> <20070725154636.092FDBCB9@smtp-auth.no-ip.com> Message-ID: <014301c7ced6$57f9a450$6402a8c0@ScuzzPaq> LOL! I actually have the same view on PK but have recently had to expose PKs in an application for a client. (Well, I suppose I could have told them NO but then I'd probably not still be working for them.) They implemented a new functionality in their GIS system. Instead of paying me to implement it correctly, they tried to have "local" firm implement the GIS (spatial) portion and retain me to do the "tabular" portion. (The whole thing is ridiculous but when you do government work you come to expect this.) Anyway, I had to expose the PK of certain tables in the interface because the "local" firm apparently doesn't know how to connect to an mdb in order to pull up a combo box in for the staff to choose from. Hence the staff is manually entering the PK to connect the spatial elements to the tabular elements. Wrought with danger is all I can say. I don't think the local firm is working there anymore - so hopefully I get to fix this mess some day }:-p -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby It comes from discussions here on this list where any time you expose the PK to view, some idiot wants to use it for some purpose that it is not supposed to be used for (like a "must be in order, with no values missing" number in an accounting system. Obviously we can and do delete records all the time so using the PK for such a rule / purpose guarantees issues whenever the idiot strikes, thus simply NEVER expose it to view. The PK's function (in real life) is exactly and only for use as a pointer from a child back to the parent. From jwcolby at colbyconsulting.com Wed Jul 25 11:20:03 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 12:20:03 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <013f01c7ced5$1ed88250$6402a8c0@ScuzzPaq> Message-ID: <20070725162016.43DFABD1C@smtp-auth.no-ip.com> Both? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 12:02 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices emotional response? too much caffiene? ... ;o) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Jurgen, Why can't I state it in such reasoned and logical terms? John W. Colby -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 11:41:06 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 09:41:06 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> References: <000301c7ce07$81d373c0$8abea8c0@XPS><006c01c7ce23$22f5cda0$dc34fad1@SusanOne><00f801c7cec6$14e13b20$8abea8c0@XPS> <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> Message-ID: It's usually the approach I use for M to M tables, and the only drawback I can think of is that if you needed a foreign key back to this table, you'd have to use both/all PK fields, not just a single autonumber. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 8:31 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Jim, This is something I haven't seen before and is in my early morning mind, quite brilliant! Are there any drawbacks to doing this? I can't imagine it would be much of a difference (size or performance wise) in any of my applications / databases but it is certainly something worth considering implementing in the future. Always open to technical improvements... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman True, but in the case of a M to M table your just introducing another column and a index that really is not needed. It seems silly to me to have something like: tblLinking LinkID - Autonumber - PK BookID - Long - CK1A AuthorID - Long - CK1B Instead of tblLinking BookID - Long - PK1A AuthorID - Long - PK1B just for the sake of having an auto number in there. The BookID and AuthorID already form a unique pair and they typically would not be used as a foreign key in another table. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Wed Jul 25 11:44:17 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 12:44:17 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725151912.941B1BCEA@smtp-auth.no-ip.com> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: <013601c7cedb$0b91e960$8abea8c0@XPS> John, <> No I don't. A surrogate key is not a primary key in terms of the model. It has no relation to the data what so ever. I agree it's a pointer, but nothing more then that. <> Really? I don't have to have any method of ensuring that each row in a table is unique? <> Yeah, I know you don't as we have been down this road a few times before (something about pig's teats comes to mind). Personally I like to fundamentally understand something as much as possible. It helps me apply things to other areas. <> Because a "primary key" and a "key" don't mean the same things to me. One denotes something that is connected to the data. The other could be anything. As for using a surrogate key, I don't object to them and I use them all the time. But I think it's important to understand that they are a short cut. In this case, the benefits are many and the ramifications few. Does it matter? In a day to day context no. But in understanding how data can be modeled certainly yes. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 11:19 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Jim, >Surrogate keys are nothing more then pointers. Correct!!!!!!!!!!!!!!!!!!!!!!!!!! This is a logical construct Jim. You accept that a PK can be a surrogate, you state that a PK is nothing but a pointer, therefore you accept (and state) that a PK is nothing but a pointer. AND... from the perspective of the child, a FK is nothing but a pointer. Does a table HAVE TO HAVE a PK at all? Not if it has no children. Ergo, what matters from the child's perspective is what the PK is all about, and that is simply a POINTER back to the parent. AND... Since a surrogate key functions as a PK, then... A PK must be nothing but a pointer... > Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. And I don't give a rat's patuty about relational theory, I care about what works. Relational theory says you should normalize to 16 (IIRC) different levels. When was the last time you did that? Do you even UNDERSTAND 9th (or 12th, or 16th) normal form? OK YOU probably do but I don't and don't care that I don't. So day in and day out you (or at least I) ignore relational theory and yet you attempt to flaunt that same theory in the great PK debate for what purpose??? Having the PK change is a no-no. Sorry, it just is. It causes a whole host of issues and given that it doesn't HAVE to change.... >That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. And I don't give a rat's patuty about relational theory, I care about what works. >Surrogates only work in computer systems because we have systems that are reliable. But we do, so what's your point? Natural keys only work (in large systems) because we have systems that are reliable. Imagine trying to manually correct 100 million records where something got corrupted. No easier (without a reliable system). I have NEVER used paper and pencil in a database so who really cares. >To call them a PK in regards to the relational model is simply incorrect. OK, and who cares? I simply do not care about the relational model (in this debate), I care about what works efficiently. I use what works (of the model) and I abandon what is inefficient (natural keys). Natural keys are NOT A REQUIREMENT, you admit that yourself. I still have a PK, it is just a surrogate. If you accept that surrogates do work then why does the insistence in relational model PK being a natural key even matter? You are nitpicking to death stuff that simply does not matter. If you want to insist that the PK HAS TO BE a natural key, then how can you say in the next breath that "I don't object to the use of surrogate keys" C'mon Jim, give it up. I will sign a piece of paper stating whatever you want about PKs and natural keys and relational theory, I simply DO NOT CARE. What I care about is that they are inefficient and cause problems that surrogate keys avoid. Happy? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 25, 2007 10:42 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <<1) The PK should be stable (NEVER changes). >> Don' agree with "never". You want it as stable as possible, but there is nothing in relational theory that says it can never change. <> That is simply not true. With relational theory, the PK is derived from the pool of CK's, which is based on the data. In theory you cannot have a PK without it being a unique index. That's part of the definition of what a natural PK is. Out of the pool of CK's, you would use the CK that is the most stable, shortest in length, and the least complex (simple vs compound). <> Surrogates only work in computer systems because we have systems that are reliable. If I gave you pen and paper and had you keep track of data using the relational model, you'd be in a pretty big mess fairly quick if you used surrogate keys. I don't object to the use of surrogate keys, but what I do object to is the apples and oranges approach you use to claim what a PK is and surrogate keys fit in the relational model. Surrogate keys are nothing more then pointers. To call them a PK in regards to the relational model is simply incorrect. Surrogate keys work well in computer systems, but the relational model can be applied to much more then computer systems and the PK as you describe it vs what it is in the relational model are not the same thing. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 9:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Bruce, >Any table that does not have a natural primary key is not a pure >dataset, ... No, Any table that does not have a natural primary key CANDIDATE is not a pure dataset, ... A candidate key is exactly that, a field or set of fields that can serve the purpose of uniquely identifying the data record, and thus becomes a CANDIDATE to be the PK. In fact you can have multiple candidates. Nothing says you actually have to USE the candidate as the PK. That is again the difference between the unique index and the PK. One of the CANDIDATES is used as the unique index, but a surrogate can still be used as the PK. Take an employee table. ONE candidate key could be first / last / phone, another could be an employee number (a quasi-surrogate key by the way), another could be the SSN. Thus we have (at least) THREE CANDIDATE keys. Do you have to use all of them as the PK? Obviously not. Do you have to use ANY of them as the PK? Obviously not. Throw in a true surrogate key - an autoincrement - and you can use that as well. So which you use simply doesn't matter AS LONG AS the PK meets a few criteria. 1) The PK should be stable (NEVER changes). That eliminates the first / last / phone idea because the name could change (I got married, I got tired of my name) AND the phone number could (and probably will) change. The SSN fails for the same reason. SSNs CAN (believe it or not) change. Alien workers steal SSNs all the time. Now they become a citizen... Oooops the SSN has to change. 2) Has no meaning. From the perspective of the CHILD record, the FK is nothing more than a pointer back to the parent record. As such it should be a behind the scenes, never directly viewed artificial construct designed to do its job as efficiently as possible. In fact, a surrogate key can (and DOES) uniquely identify a single row of the table. If it did not, then it could not be the PK. As you know, you cannot take a simple integer, make it a value of 1 for every record, and make that the PK of the table. It is the very fact that you make the field autoincrement (or whatever) is what makes it possible to serve as the PK. However a surrogate cannot be used for the unique index, the purpose of preventing duplicates. OTOH it does not need to, its sole purpose in live is to act as a pointer, placed in child records to point back to itself. Again, the PK and the unique index are NOT the same structure, either in real life or in theory. The purpose of the PK is to uniquely identify a record so that it can be linked to a child record. Nothing more, nothing less. You can do that with a natural key, and you can do that with a surrogate. The purpose of the unique index is to prevent entering the same record in the database twice (data integrity). Different function. The fact that the fields used in the unique index can also serve as a PK is irrelevant. It does NOT HAVE TO BE the primary key. Think about normalization for a moment. The basic concept behind normalization is that ONLY information about a specific object is in the table about that object. Only bank info is in the bank table, only customer info is in the customer table, only check info is in the check table. One goal of normalization should be to minimize the fluff around lineage. Yes a check was drawn by a specific customer, but that does not mean that we have to have any specific piece of the customer table in the check table, it only means that we have to be able to uniquely identify which customer wrote the check. So it simply does NOT MATTER whether we use a SURROGATE KEY from the customer table, or the customer SSN (the very WORST choice), the first /last / eye color / hair color / phone / zip / and whatever else you might have decided was the CANDIDATE KEY of the customer table. Either one WORKS. What works, and what is the best choice are different matters. The surrogate key avoids a whole slew of real life problems, and creates none (in my experience). John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Wednesday, July 25, 2007 8:12 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 02:52, jwcolby wrote: > ROTFLMAO. > > The fit never passes. It just subsides until the moon rises again. > > > John W. Colby Any table that does not have a natural primary key is not a pure dataset, ... ... ... no, I'm not talking about natural v surrogate. bruce -- 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 cfoust at infostatsystems.com Wed Jul 25 11:42:41 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 09:42:41 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> References: <20070725154907.BADA1BCEF@smtp-auth.no-ip.com> Message-ID: Hmmn ... Logical, reasonalbe ... Foaming mouth... I wonder?? LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 8:49 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Jurgen, Why can't I state it in such reasoned and logical terms? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 25, 2007 11:39 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Jim: I'm generally with John on this one. The question was about best practices, not relational theory. Every comment you made to John was about relational theory. This is about computer databases; about 'Practices', not 'Theory'. In practice, you can not beat an autonumber for size and speed (performance) in a computer environment. Apply it consistently in conjuction with any other unique indexes on fields or combinations of fields you identify as candidate keys and no user can mess up any more than they possibly could using any other key. None of the 'Theory' comments impact the practical utility and validity of using a unique long or GUID as a primary key. If occasionally you have a key that will likely not be used in a join, at least you retain the flexibilty should the unforseen arise. In terms of additional space wasted for the case where such a key is never used in a join, it is the smallest amout possible for the flexiblity and consistency gained. That sounds like a best practice to me. Regardless of whether anyone agrees with me, it is my practice because it works well. You won't hear from mea again on this topic this year. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.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 Jul 25 11:49:40 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 12:49:40 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> Message-ID: <013701c7cedb$cbd9d980$8abea8c0@XPS> Jurgen, <> Excellent point. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Wednesday, July 25, 2007 11:39 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Jim: I'm generally with John on this one. The question was about best practices, not relational theory. Every comment you made to John was about relational theory. This is about computer databases; about 'Practices', not 'Theory'. In practice, you can not beat an autonumber for size and speed (performance) in a computer environment. Apply it consistently in conjuction with any other unique indexes on fields or combinations of fields you identify as candidate keys and no user can mess up any more than they possibly could using any other key. None of the 'Theory' comments impact the practical utility and validity of using a unique long or GUID as a primary key. If occasionally you have a key that will likely not be used in a join, at least you retain the flexibilty should the unforseen arise. In terms of additional space wasted for the case where such a key is never used in a join, it is the smallest amout possible for the flexiblity and consistency gained. That sounds like a best practice to me. Regardless of whether anyone agrees with me, it is my practice because it works well. You won't hear from mea again on this topic this year. Ciao J|rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Jim Dettman" > >John, > ><<1) The PK should be stable (NEVER changes). >> > > Don' agree with "never". You want it as stable as possible, but there >is >nothing in relational theory that says it can never change. > ><real life or in theory.>> > > That is simply not true. With relational theory, the PK is derived from >the pool of CK's, which is based on the data. In theory you cannot have a >PK without it being a unique index. That's part of the definition of what >a >natural PK is. Out of the pool of CK's, you would use the CK that is the >most stable, shortest in length, and the least complex (simple vs >compound). > ><surrogate key avoids a whole slew of real life problems, and creates none >(in my experience).>> > > Surrogates only work in computer systems because we have systems that >are >reliable. If I gave you pen and paper and had you keep track of data using >the relational model, you'd be in a pretty big mess fairly quick if you >used >surrogate keys. > > I don't object to the use of surrogate keys, but what I do object to is >the apples and oranges approach you use to claim what a PK is and surrogate >keys fit in the relational model. Surrogate keys are nothing more then >pointers. To call them a PK in regards to the relational model is simply >incorrect. > > Surrogate keys work well in computer systems, but the relational model >can >be applied to much more then computer systems and the PK as you describe it >vs what it is in the relational model are not the same thing. > >Jim. _________________________________________________________________ Fight Allergies With Live Search http://search.live.com/results.aspx?q=Remedies+For+Spring+Allergies&mkt=en-c a&FORM=SERNEP From jimdettman at verizon.net Wed Jul 25 11:51:34 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 25 Jul 2007 12:51:34 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> References: <000301c7ce07$81d373c0$8abea8c0@XPS><006c01c7ce23$22f5cda0$dc34fad1@SusanOne> <00f801c7cec6$14e13b20$8abea8c0@XPS> <010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> Message-ID: <013b01c7cedc$0ff09320$8abea8c0@XPS> John, <> I have never found any. I've been forced to do it both ways. Other then to say that there is some additional overhead with the first rather then the second, there is no real difference in terms of outcome. For me, old habits die hard; I still program like I did when my programs needed to run in 64K. As a result, my apps are generally snappier then most. Something like this seems like a no-brainer. In fact, I think doing it the first way actually confuses the design because there is no obvious reason for having it that way. Of course that could just be me. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 11:31 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Jim, This is something I haven't seen before and is in my early morning mind, quite brilliant! Are there any drawbacks to doing this? I can't imagine it would be much of a difference (size or performance wise) in any of my applications / databases but it is certainly something worth considering implementing in the future. Always open to technical improvements... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman True, but in the case of a M to M table your just introducing another column and a index that really is not needed. It seems silly to me to have something like: tblLinking LinkID - Autonumber - PK BookID - Long - CK1A AuthorID - Long - CK1B Instead of tblLinking BookID - Long - PK1A AuthorID - Long - PK1B just for the sake of having an auto number in there. The BookID and AuthorID already form a unique pair and they typically would not be used as a foreign key in another table. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Wed Jul 25 12:12:15 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 25 Jul 2007 13:12:15 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725162016.43DFABD1C@smtp-auth.no-ip.com> References: <013f01c7ced5$1ed88250$6402a8c0@ScuzzPaq> <20070725162016.43DFABD1C@smtp-auth.no-ip.com> Message-ID: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Apparently I have a much different view on this subject than most here. My view has evolved over years in this business, and changed due to increasing complexity of databases. 1. I used to think that ANPKs were the only way to go. Given a dozen or even two dozen tables, it made sense. Given 500 tables plus the low cost of disk space, I no longer agree with that model. As a consequence, I no longer agree that compound PKs are bad that ANPKs are always superior. 2. Any Front End worth its salt can easily pass multiple values to the BE to create a row in some related table. This is not difficult, and if the related table is something so simple as State/Province, containing about 62 rows each of which is uniquely identified by its abbreviation (i.e. SK = Saskatchewan, WY = Wyoming, FL = Florida), then what is gained by storing these as FKs derived from the States/Provinces table? Why not reduce said table to two columns, one being char(2) and the other being varchar(20)? What is gained by this strategy is that a table does not need to be joined in order to obtain the value that interests humans. 3. The aforementioned difficulty cascades to all related tables in the tree. Eventually you find yourself creating surrogate indexes on surrogate indexes in some related table, and it can cascade from there. With 5 or 6 tables, this may not seem an issue, but try 40 tables in a tree and you will get my point. 4. I used to be in the school of ANPKs everywhere but I have since departed, primarily due to the effects created in rich databases (e.g. large databases are a small number of tables with millions of rows; rich databases are a large number of tables with relatively few rows each; it's possible but seldom occurs that a db is both large and rich). In a rich database, I do not have the time to do 20 joins to grab the keys of the related data. I want it NOW, not one minute from now. Correctness of results and speed of retrieval are the most important tests. Disk space, long ago, was the paramount consideration, and caused many of us (including me) to think that ANPKs were the solution. Thanks to a couple of books I read, I have since then shed that illusion. That doesn't mean that I don't like ANPKs. I still love and treasure them. But I have learned that they don't belong in any table where the number of rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the case of a table called State/Provinces, consisting of about 62 rows representing the states in USA and the provinces and territories in Canada. All of these items can be represented uniquely by a two-letter combination. Why on earth would you then introduce an ANPK into this table? It makes NO sense, IMO. It rather exemplifies the ridiculous application of a maxim learned long ago and adhered to since, without further examination. Let's go further. Suppose your firm has 100 products all of which are uniquely identified by three alpha characters. Why would you bother creating an ANPK on said table? IMO it's asinine. You just force me to create joins down the road (as in reporting), while providing me with no real gain in the here and now. You wanna benchmark your index on an ANPK versus mine on a three-letter alpha column? Ok? Let's go. I'll give you half a second maximum, and then let's look at the rewards I get that you don't. After 30 years in the database business, I have only recently come to appreciate the value of compound PKs and PKs that are not necessarily ANPKs. It's taken me a while to realize this, I confess, and I'm sure that many of you will disagree. But having been in the situation of 500 tables some of which have 50 million rows, and 20 joins are required for some query or other, I now understand that ANPKs are stupid in this situation. Far better, and 10 times faster, are meaningful char PKs such as the State/Province example listed above. In a given table, I already have the value "CA" meaning California. I don't need to reference an ANPK to look up this value -- I already have it. This perspective may make sense only to those who work with millions of rows in hundreds of tables. But that pretty much describes where I work. In these circumstances, I would definitely raise red flags wherever ANPKs are introduced in lookup tables, while defending their place in transaction tables. Arthur On 7/25/07, jwcolby wrote: > > Both? > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow > Sent: Wednesday, July 25, 2007 12:02 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Primary Key Best Practices > > emotional response? too much caffiene? ... > ;o) > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > > Jurgen, > > Why can't I state it in such reasoned and logical terms? > > John W. Colby > > -- > 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 jwcolby at colbyconsulting.com Wed Jul 25 12:33:43 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 13:33:43 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <013601c7cedb$0b91e960$8abea8c0@XPS> Message-ID: <20070725173355.613A7BE1C@smtp-auth.no-ip.com> Jim, > No I don't. A surrogate key is not a primary key in terms of the model. But I don't work in the model, I work in the real world. A PK is a PK because the database assigns it the PK symbol, and as such I then use it as a pointer. The PK object in any database system (I use) CAN BE a surrogate so the REAL WORLD accepts that surrogates can be PKs. I don't see you calling up MS and complaining that a PK symbol is assigned to your surrogate PK. It may be called a surrogate key, but in the real world it is called it a surrogate PK. > Really? I don't have to have any method of ensuring that each row in a table is unique? Open SQL Server (or Access). Create a table. Create a unique index on it. You now have NO PK but you do have a unique index, ensuring that each row is unique. So SQL Server at least differentiates between PK and unique index. I know that Access works this way. I suspect that the rest do too. A PK and a unique index are NOT the same thing. You MAY specify that a field is the PK, and as such the database will create a unique index - I acknowledge that it has to do that, but again, the index itself does NOT MAKE the PK, the unique index is a necessary attribute of the PK. Being a PK is not an attribute of a unique index. Let's stop discussing the model. It is not useful, I already signed my life away stating that anything you wish to claim about the model is true, so stop with the model already. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Wednesday, July 25, 2007 12:44 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <> No I don't. A surrogate key is not a primary key in terms of the model. It has no relation to the data what so ever. I agree it's a pointer, but nothing more then that. <> Really? I don't have to have any method of ensuring that each row in a table is unique? <> Yeah, I know you don't as we have been down this road a few times before (something about pig's teats comes to mind). Personally I like to fundamentally understand something as much as possible. It helps me apply things to other areas. <> Because a "primary key" and a "key" don't mean the same things to me. One denotes something that is connected to the data. The other could be anything. As for using a surrogate key, I don't object to them and I use them all the time. But I think it's important to understand that they are a short cut. In this case, the benefits are many and the ramifications few. Does it matter? In a day to day context no. But in understanding how data can be modeled certainly yes. Jim. From jwcolby at colbyconsulting.com Wed Jul 25 12:46:29 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 13:46:29 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Message-ID: <20070725174642.69646BE67@smtp-auth.no-ip.com> And you know what Arthur, your logic is flawless. There are a number of cases where there is only a single field in the table and only ever going to be a single field. In those cases I would reluctantly put down my ANPK. IN THOSE cases, the table is really being used as a simple data integrity monitor to force the user to select a valid choice. The two column "with a code" I would not so quickly put down my ANPK. In the case of a product with a 3 char code and a ton of other useful info I absolutely would continue to use an ANPK. The reason is simple, and comes back to join speed. Yea, people MAY memorize all the 3 character codes but just as likely you would be joining your 3 char field to pull more data where I would be joining an integer. But congrats anyway, you have pointed out the (so far) single case where a natural key is as good as an ANPK and causes no further problems. And BTW, disk space is not my primary objection, but rather join speed. No matter whether a lowly PC desktop or a supercomputer, speed is always an issue. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 25, 2007 1:12 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Apparently I have a much different view on this subject than most here. My view has evolved over years in this business, and changed due to increasing complexity of databases. 1. I used to think that ANPKs were the only way to go. Given a dozen or even two dozen tables, it made sense. Given 500 tables plus the low cost of disk space, I no longer agree with that model. As a consequence, I no longer agree that compound PKs are bad that ANPKs are always superior. 2. Any Front End worth its salt can easily pass multiple values to the BE to create a row in some related table. This is not difficult, and if the related table is something so simple as State/Province, containing about 62 rows each of which is uniquely identified by its abbreviation (i.e. SK = Saskatchewan, WY = Wyoming, FL = Florida), then what is gained by storing these as FKs derived from the States/Provinces table? Why not reduce said table to two columns, one being char(2) and the other being varchar(20)? What is gained by this strategy is that a table does not need to be joined in order to obtain the value that interests humans. 3. The aforementioned difficulty cascades to all related tables in the tree. Eventually you find yourself creating surrogate indexes on surrogate indexes in some related table, and it can cascade from there. With 5 or 6 tables, this may not seem an issue, but try 40 tables in a tree and you will get my point. 4. I used to be in the school of ANPKs everywhere but I have since departed, primarily due to the effects created in rich databases (e.g. large databases are a small number of tables with millions of rows; rich databases are a large number of tables with relatively few rows each; it's possible but seldom occurs that a db is both large and rich). In a rich database, I do not have the time to do 20 joins to grab the keys of the related data. I want it NOW, not one minute from now. Correctness of results and speed of retrieval are the most important tests. Disk space, long ago, was the paramount consideration, and caused many of us (including me) to think that ANPKs were the solution. Thanks to a couple of books I read, I have since then shed that illusion. That doesn't mean that I don't like ANPKs. I still love and treasure them. But I have learned that they don't belong in any table where the number of rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the case of a table called State/Provinces, consisting of about 62 rows representing the states in USA and the provinces and territories in Canada. All of these items can be represented uniquely by a two-letter combination. Why on earth would you then introduce an ANPK into this table? It makes NO sense, IMO. It rather exemplifies the ridiculous application of a maxim learned long ago and adhered to since, without further examination. Let's go further. Suppose your firm has 100 products all of which are uniquely identified by three alpha characters. Why would you bother creating an ANPK on said table? IMO it's asinine. You just force me to create joins down the road (as in reporting), while providing me with no real gain in the here and now. You wanna benchmark your index on an ANPK versus mine on a three-letter alpha column? Ok? Let's go. I'll give you half a second maximum, and then let's look at the rewards I get that you don't. After 30 years in the database business, I have only recently come to appreciate the value of compound PKs and PKs that are not necessarily ANPKs. It's taken me a while to realize this, I confess, and I'm sure that many of you will disagree. But having been in the situation of 500 tables some of which have 50 million rows, and 20 joins are required for some query or other, I now understand that ANPKs are stupid in this situation. Far better, and 10 times faster, are meaningful char PKs such as the State/Province example listed above. In a given table, I already have the value "CA" meaning California. I don't need to reference an ANPK to look up this value -- I already have it. This perspective may make sense only to those who work with millions of rows in hundreds of tables. But that pretty much describes where I work. In these circumstances, I would definitely raise red flags wherever ANPKs are introduced in lookup tables, while defending their place in transaction tables. Arthur From john at winhaven.net Wed Jul 25 12:57:47 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 12:57:47 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <013b01c7cedc$0ff09320$8abea8c0@XPS> References: <000301c7ce07$81d373c0$8abea8c0@XPS><006c01c7ce23$22f5cda0$dc34fad1@SusanOne><00f801c7cec6$14e13b20$8abea8c0@XPS><010e01c7ced0$be0e0de0$6402a8c0@ScuzzPaq> <013b01c7cedc$0ff09320$8abea8c0@XPS> Message-ID: <001f01c7cee5$50decd80$6402a8c0@ScuzzPaq> Well having never thought of this... that may be an indication of my brain capacity! ;o) I would imagine its just a consistency thing, once I start doing something I generally do it consistently unless I have a good reason not to. This seems like a good reason. However, I must await the inevitable drawback which will be pointed out by someone who has thought this through more than I have. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Something like this seems like a no-brainer. In fact, I think doing it the first way actually confuses the design because there is no obvious reason for having it that way. From fuller.artful at gmail.com Wed Jul 25 13:09:52 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 25 Jul 2007 14:09:52 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725174642.69646BE67@smtp-auth.no-ip.com> References: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> <20070725174642.69646BE67@smtp-auth.no-ip.com> Message-ID: <29f585dd0707251109mb8ca6bat9404f3190d0a5f97@mail.gmail.com> Blush! "your logic is flawless." From you, that's truly awesome praise. On 7/25/07, jwcolby wrote: > > And you know what Arthur, your logic is flawless. There are a number of > cases where there is only a single field in the table and only ever going > to > be a single field. In those cases I would reluctantly put down my > ANPK. IN > THOSE cases, the table is really being used as a simple data integrity > monitor to force the user to select a valid choice. The two column "with > a > code" I would not so quickly put down my ANPK. In the case of a product > with a 3 char code and a ton of other useful info I absolutely would > continue to use an ANPK. The reason is simple, and comes back to join > speed. Yea, people MAY memorize all the 3 character codes but just as > likely you would be joining your 3 char field to pull more data where I > would be joining an integer. > > But congrats anyway, you have pointed out the (so far) single case where a > natural key is as good as an ANPK and causes no further problems. > > And BTW, disk space is not my primary objection, but rather join > speed. No > matter whether a lowly PC desktop or a supercomputer, speed is always an > issue. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > From fuller.artful at gmail.com Wed Jul 25 13:57:58 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 25 Jul 2007 14:57:58 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <005101c7ce26$3ec58680$0200a8c0@danwaters> References: <004201c7ce18$79e7cd80$0200a8c0@danwaters> <0JLP007V75EOGYZ0@vms046.mailsrvcs.net> <005101c7ce26$3ec58680$0200a8c0@danwaters> Message-ID: <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> IN() forces a table scan. There's a much hipper way to do this. Given some arbitrary front end that asks you for values and you supply 1, 307, 590, and 12 (which correspond to PKs or FKs of interest), then write these values to a temp table and then do a join to the real table of interest. Even assuming 100 user-supplied values, resulting in 100 rows in the temp table, this is WAY faster than any other known method. Compared to IN(), against a large number of rows, there is no comparison. IN() forces a table scan. The parser is not smart enough to create a temp table of the values supplied, and therefore cannot use the index to find the rows. Instead it walks the entire table. Create the temp table as described above, then do a join to the real table of interest and boink! You've got your rows WAY more quickly than in the other methods. hth, Arthur On 7/24/07, Dan Waters wrote: > > Perhaps this will bypass the limit altogether! > > Thanks Eric! > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro > Sent: Tuesday, July 24, 2007 1:45 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with Ors > tend > to take longer to execute. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 10:32 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > That's a good plan! I was hoping to do a customer update within the next > half hour though. > > I was hoping that someone had seen some documentation on this. The number > 40 was documented 'somewhere' in Access help. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Tuesday, July 24, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > You could reasonably quickly set up a test to find out by building a > dynamic > query, a string such as select PKID from tblX where (PKID=1 or PKID=2 > or...). Add 10 (or 100) at a time and see how far you get. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 1:02 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Number of 'OR's in queries - what's the limit? > > In Access 97, there was a limit of 40 OR words in a query. There is a > limit > in Access 2003, it's >250, but I don't know what it actually is. > > Does anyone know? > > Thanks! > Dan > > > > -- > 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 > 7:45 PM > > > -- > 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 jwcolby at colbyconsulting.com Wed Jul 25 14:13:12 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 15:13:12 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> Message-ID: <20070725191324.A7753BC78@smtp-auth.no-ip.com> Do you need to create an index on the field in the temp table? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 25, 2007 2:58 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? IN() forces a table scan. There's a much hipper way to do this. Given some arbitrary front end that asks you for values and you supply 1, 307, 590, and 12 (which correspond to PKs or FKs of interest), then write these values to a temp table and then do a join to the real table of interest. Even assuming 100 user-supplied values, resulting in 100 rows in the temp table, this is WAY faster than any other known method. Compared to IN(), against a large number of rows, there is no comparison. IN() forces a table scan. The parser is not smart enough to create a temp table of the values supplied, and therefore cannot use the index to find the rows. Instead it walks the entire table. Create the temp table as described above, then do a join to the real table of interest and boink! You've got your rows WAY more quickly than in the other methods. hth, Arthur On 7/24/07, Dan Waters wrote: > > Perhaps this will bypass the limit altogether! > > Thanks Eric! > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro > Sent: Tuesday, July 24, 2007 1:45 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with > Ors tend to take longer to execute. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 10:32 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > That's a good plan! I was hoping to do a customer update within the > next half hour though. > > I was hoping that someone had seen some documentation on this. The > number 40 was documented 'somewhere' in Access help. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Tuesday, July 24, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > You could reasonably quickly set up a test to find out by building a > dynamic query, a string such as select PKID from tblX where (PKID=1 or > PKID=2 or...). Add 10 (or 100) at a time and see how far you get. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 1:02 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Number of 'OR's in queries - what's the limit? > > In Access 97, there was a limit of 40 OR words in a query. There is a > limit in Access 2003, it's >250, but I don't know what it actually is. > > Does anyone know? > > Thanks! > Dan > > > > -- > 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: > 7/23/2007 > 7:45 PM > > > -- > 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 robert at webedb.com Wed Jul 25 14:31:19 2007 From: robert at webedb.com (Robert L. Stewart) Date: Wed, 25 Jul 2007 14:31:19 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <200707251936.l6PJarGv004472@databaseadvisors.com> At 12:00 PM 7/25/2007, you wrote: >Date: Wed, 25 Jul 2007 11:19:00 -0400 >From: "jwcolby" >Subject: Re: [AccessD] Primary Key Best Practices >To: "'Access Developers discussion and problem solving'" > >Message-ID: <20070725151912.941B1BCEA at smtp-auth.no-ip.com> >Content-Type: text/plain; charset="us-ascii" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. Ergo, >what matters from the child's perspective is what the PK is all about, and >that is simply a POINTER back to the parent. AND... Since a surrogate key >functions as a PK, then... A PK must be nothing but a pointer... From john at winhaven.net Wed Jul 25 15:27:19 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 15:27:19 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707251936.l6PJarGv004472@databaseadvisors.com> References: <200707251936.l6PJarGv004472@databaseadvisors.com> Message-ID: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> Good point. And one I glossed over while postulating my responses. I can't remember ever having a table without a PK in any RDBMS. I can't even imagine what data would be stored in an RDBMS that didn't need a PK. This is what is so befuddling to me when it comes to Outlook's contacts... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Wednesday, July 25, 2007 2:31 PM At 12:00 PM 7/25/2007, you wrote: >From: "jwcolby" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. >Ergo, what matters from the child's perspective is what the PK is all >about, and that is simply a POINTER back to the parent. AND... Since a >surrogate key functions as a PK, then... A PK must be nothing but a pointer... From dwaters at usinternet.com Wed Jul 25 15:30:01 2007 From: dwaters at usinternet.com (Dan Waters) Date: Wed, 25 Jul 2007 15:30:01 -0500 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> References: <004201c7ce18$79e7cd80$0200a8c0@danwaters><0JLP007V75EOGYZ0@vms046.mailsrvcs.net><005101c7ce26$3ec58680$0200a8c0@danwaters> <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> Message-ID: <002701c7cefa$93e14b70$0200a8c0@danwaters> Hi Arthur, I am using this method to define a query that will be used as the recordsource for a form, and the records must be updateable. Yesterday when I used this, 484 records were included, it was very fast, and the records are updateable. The table currently has about 1000 records, and will top out at roughly 10,000. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 25, 2007 1:58 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? IN() forces a table scan. There's a much hipper way to do this. Given some arbitrary front end that asks you for values and you supply 1, 307, 590, and 12 (which correspond to PKs or FKs of interest), then write these values to a temp table and then do a join to the real table of interest. Even assuming 100 user-supplied values, resulting in 100 rows in the temp table, this is WAY faster than any other known method. Compared to IN(), against a large number of rows, there is no comparison. IN() forces a table scan. The parser is not smart enough to create a temp table of the values supplied, and therefore cannot use the index to find the rows. Instead it walks the entire table. Create the temp table as described above, then do a join to the real table of interest and boink! You've got your rows WAY more quickly than in the other methods. hth, Arthur On 7/24/07, Dan Waters wrote: > > Perhaps this will bypass the limit altogether! > > Thanks Eric! > Dan > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro > Sent: Tuesday, July 24, 2007 1:45 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > Why not do a WHERE PKID IN (1,2,3,5,15) query instead? Queries with Ors > tend > to take longer to execute. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 10:32 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > That's a good plan! I was hoping to do a customer update within the next > half hour though. > > I was hoping that someone had seen some documentation on this. The number > 40 was documented 'somewhere' in Access help. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Tuesday, July 24, 2007 12:13 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Number of 'OR's in queries - what's the limit? > > You could reasonably quickly set up a test to find out by building a > dynamic > query, a string such as select PKID from tblX where (PKID=1 or PKID=2 > or...). Add 10 (or 100) at a time and see how far you get. > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters > Sent: Tuesday, July 24, 2007 1:02 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Number of 'OR's in queries - what's the limit? > > In Access 97, there was a limit of 40 OR words in a query. There is a > limit > in Access 2003, it's >250, but I don't know what it actually is. > > Does anyone know? > > Thanks! > Dan > > > > -- > 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 7/23/2007 > 7:45 PM > > > -- > 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 Wed Jul 25 15:56:52 2007 From: ssharkins at gmail.com (Susan Harkins) Date: Wed, 25 Jul 2007 16:56:52 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> References: <200707251936.l6PJarGv004472@databaseadvisors.com> <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> Message-ID: <002001c7cefe$5bc746f0$5cb62ad1@SusanOne> This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? Susan H. From jwelz at hotmail.com Wed Jul 25 16:05:23 2007 From: jwelz at hotmail.com (Jurgen Welz) Date: Wed, 25 Jul 2007 15:05:23 -0600 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Message-ID: Arthur: Interesting comments as performance has always been an issue for me. In recognition of some of those concerns I evolved an approach that oviates some of your concerns, but it is hardly a common approach. In the case of displaying State/Province in a form or report, I've always set the primary record source to the parent table record and used a combo bound to the province key to display the province. This is the approach I use for virtually all lookup tables. I even occasionally use a value list row source (gasp!) that is simply a way to limit and validate data that I can't bother to store in a two record table. In the case of forms or reports using province or similar data, no fancy query or join processing (assuming client/server) is required and the join is functionally performed at the combo. Going beyond this, for nearly all smaller lookup tables (up to a couple thousand records), I've found it expedient to pull the common combo data one time with a recordset and getrows and fill the combos with callbacks. For static tables like province, this is pulled on demand the first time required. For semi-static data, i check a single record date time stamp that indicates the last edit/add to a lookup table. If the time stamp is after my last data load, I refresh the array. I don't really see the utilty of displaying 'AL, AK, AB, AZ or AR' in a user's view of the data. My preference is to display the combo with all the information. Rather than placing an edit button by the field to pop a list of choices or allowing a user to enter anything they want and then run a validation routine, a combo keeps a browseable list ready to hand. By using combos for one record to one lookup joins and subforms for one record to many record joins, and in certain cases, listboxes for one to many joins, complex query sources for forms and reports are exceedingly rare. With a just in time approach for subforms and lists, selecting on a numeric PK continues to make sense. My current 47 user database reports 191 tables and performance remains snappy. Since the original question is regarding best practices and what I do is not for everyone, I can see where you have some useful insights. It would be interesting to know what the impact is of one approach over the other in a client/server environment as opposed to a file/server environment. Since I am in a mdb only environment, allowing the form controls to process the joins limiting data requests to the absolute minimum traffic by caching lookup data made the most sense to me. I had benchmarked a few approaches to filling some of my more complex forms using a couple of different data designs and I know that AN PKs remain the only game in town for me. Ciao J?rgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Arthur Fuller" > >Apparently I have a much different view on this subject than most here. My >view has evolved over years in this business, and changed due to increasing >complexity of databases. > >1. I used to think that ANPKs were the only way to go. Given a dozen or >even >two dozen tables, it made sense. Given 500 tables plus the low cost of disk >space, I no longer agree with that model. As a consequence, I no longer >agree that compound PKs are bad that ANPKs are always superior. > >2. Any Front End worth its salt can easily pass multiple values to the BE >to >create a row in some related table. This is not difficult, and if the >related table is something so simple as State/Province, containing about 62 >rows each of which is uniquely identified by its abbreviation (i.e. SK = >Saskatchewan, WY = Wyoming, FL = Florida), then what is gained by storing >these as FKs derived from the States/Provinces table? Why not reduce said >table to two columns, one being char(2) and the other being varchar(20)? >What is gained by this strategy is that a table does not need to be joined >in order to obtain the value that interests humans. > >3. The aforementioned difficulty cascades to all related tables in the >tree. >Eventually you find yourself creating surrogate indexes on surrogate >indexes >in some related table, and it can cascade from there. With 5 or 6 tables, >this may not seem an issue, but try 40 tables in a tree and you will get my >point. > >4. I used to be in the school of ANPKs everywhere but I have since >departed, >primarily due to the effects created in rich databases (e.g. large >databases >are a small number of tables with millions of rows; rich databases are a >large number of tables with relatively few rows each; it's possible but >seldom occurs that a db is both large and rich). In a rich database, I do >not have the time to do 20 joins to grab the keys of the related data. I >want it NOW, not one minute from now. Correctness of results and speed of >retrieval are the most important tests. Disk space, long ago, was the >paramount consideration, and caused many of us (including me) to think that >ANPKs were the solution. > >Thanks to a couple of books I read, I have since then shed that illusion. >That doesn't mean that I don't like ANPKs. I still love and treasure them. >But I have learned that they don't belong in any table where the number of >rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the >case >of a table called State/Provinces, consisting of about 62 rows representing >the states in USA and the provinces and territories in Canada. All of these >items can be represented uniquely by a two-letter combination. Why on earth >would you then introduce an ANPK into this table? It makes NO sense, IMO. >It >rather exemplifies the ridiculous application of a maxim learned long ago >and adhered to since, without further examination. > >Let's go further. Suppose your firm has 100 products all of which are >uniquely identified by three alpha characters. Why would you bother >creating >an ANPK on said table? IMO it's asinine. You just force me to create joins >down the road (as in reporting), while providing me with no real gain in >the >here and now. You wanna benchmark your index on an ANPK versus mine on a >three-letter alpha column? Ok? Let's go. I'll give you half a second >maximum, and then let's look at the rewards I get that you don't. > >After 30 years in the database business, I have only recently come to >appreciate the value of compound PKs and PKs that are not necessarily >ANPKs. >It's taken me a while to realize this, I confess, and I'm sure that many of >you will disagree. But having been in the situation of 500 tables some of >which have 50 million rows, and 20 joins are required for some query or >other, I now understand that ANPKs are stupid in this situation. Far >better, >and 10 times faster, are meaningful char PKs such as the State/Province >example listed above. In a given table, I already have the value "CA" >meaning California. I don't need to reference an ANPK to look up this value >-- I already have it. > >This perspective may make sense only to those who work with millions of >rows >in hundreds of tables. But that pretty much describes where I work. In >these >circumstances, I would definitely raise red flags wherever ANPKs are >introduced in lookup tables, while defending their place in transaction >tables. > >Arthur _________________________________________________________________ http://liveearth.msn.com From Lambert.Heenan at AIG.com Wed Jul 25 16:10:23 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Wed, 25 Jul 2007 17:10:23 -0400 Subject: [AccessD] Primary Key Best Practices Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> Well, just like a MailItem, a ContactItem has a property called "EntryID" which is of type String. For MailItems this looks like some kind of GUID... 00000000AF9B53E7CCFAD01199D500805FD4C8DA07001D7828CDB8350747AFE9D69E0E90DA1F 00001D15892D000034C8A2AB1EF3564CB0D64DB6AFFDD5C2000009BA2DB10000 And though I have not checked this out, I suspect the EntryID of a ContactItem is of the same form. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 4:57 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 16:43:13 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 14:43:13 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> Message-ID: LOL Not something you'd want to have to remember or type in!! Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Wednesday, July 25, 2007 2:10 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Well, just like a MailItem, a ContactItem has a property called "EntryID" which is of type String. For MailItems this looks like some kind of GUID... 00000000AF9B53E7CCFAD01199D500805FD4C8DA07001D7828CDB8350747AFE9D69E0E90 DA1F 00001D15892D000034C8A2AB1EF3564CB0D64DB6AFFDD5C2000009BA2DB10000 And though I have not checked this out, I suspect the EntryID of a ContactItem is of the same form. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 4:57 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? 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 jwcolby at colbyconsulting.com Wed Jul 25 16:45:54 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 17:45:54 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707251936.l6PJarGv004472@databaseadvisors.com> Message-ID: <20070725214607.338EEBE3C@smtp-auth.no-ip.com> >Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. True, but it does NOT require one for the table to exist in SQL Server. I am simply making a point that the PK is not the unique index. The PK HAS ONE unique index, and it has to have a unique index to be labeled as the PK (by the database engine) but it is NOT JUST A UNIQUE INDEX, it is a pointer to a record that, oh by the way, happens to have a unique index. You can create a table in SQL Server and not label any field or combinations of fields as the PK inside of SQL Server. Make that field an auto increment. DO NOT place a unique index on it. Create 1 million records. Now go link that table to Access and TELL ACCESS that the autonumber field is the PK. Now you can do the deletes and updates. IT IS JUST A POINTER. It does NOT have a unique index in SQL Server, and it is not LABELED as the PK in SQL Server. But the field still (correctly) points to a single record back in SQL Server and can be used to find and delete a record. Now, go into that table in SQL Server and assign some natural key as the PK. Go back to Access. Even though you have not told ACCESS that the natural key is the PK, you can STILL delete a specific record out in SQL Server using the original autonumber. The field is JUST A POINTER. Now go into SQL Server and find a second (and third and fourth) CANDIDATE KEYS and create unique indexes on them. You haven't in any fashion made those candidate keys the PK, all you have done is set up a new unique index. Call it what you want, I don't care. A unique index is NOT a PK and a PK is NOT a unique index. Different things entirely. The FIELD or FIELDS that have a unique index applied to them may be chosen as the PK, but the index itself is NOT THE PK, and the PK IS NOT THE UNIQUE INDEX. The field itself (with or without an index) is the PK, and the contents of the field are used for the lookup to find the matching records in other tables. The unique index does nothing more or less than enforce uniqueness, which of course is a requirement of the CONTENTS of the field(s) that make up the PK, and the unique index is thus FORCED to exist by the database engine (correctly so). Now quote the model all you want, as I said, the model is not of interest to me, reality is of interest to me. Models do exactly that, MODEL REALITY, they are not the complete representation of reality. If they were they would cease to be a model and become the real thing. The model is interesting but it is not complete, and it is being very effectively used to obscure the issues in this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Wednesday, July 25, 2007 3:31 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices At 12:00 PM 7/25/2007, you wrote: >Date: Wed, 25 Jul 2007 11:19:00 -0400 >From: "jwcolby" >Subject: Re: [AccessD] Primary Key Best Practices >To: "'Access Developers discussion and problem solving'" > >Message-ID: <20070725151912.941B1BCEA at smtp-auth.no-ip.com> >Content-Type: text/plain; charset="us-ascii" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. >Ergo, what matters from the child's perspective is what the PK is all >about, and that is simply a POINTER back to the parent. AND... Since a >surrogate key functions as a PK, then... A PK must be nothing but a pointer... -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 16:46:41 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 17:46:41 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> Message-ID: <20070725214654.07370BE08@smtp-auth.no-ip.com> Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 4:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Good point. And one I glossed over while postulating my responses. I can't remember ever having a table without a PK in any RDBMS. I can't even imagine what data would be stored in an RDBMS that didn't need a PK. This is what is so befuddling to me when it comes to Outlook's contacts... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Wednesday, July 25, 2007 2:31 PM At 12:00 PM 7/25/2007, you wrote: >From: "jwcolby" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. >Ergo, what matters from the child's perspective is what the PK is all >about, and that is simply a POINTER back to the parent. AND... Since a >surrogate key functions as a PK, then... A PK must be nothing but a pointer... -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 16:50:15 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 14:50:15 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725214654.07370BE08@smtp-auth.no-ip.com> References: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> <20070725214654.07370BE08@smtp-auth.no-ip.com> Message-ID: You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 4:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Good point. And one I glossed over while postulating my responses. I can't remember ever having a table without a PK in any RDBMS. I can't even imagine what data would be stored in an RDBMS that didn't need a PK. This is what is so befuddling to me when it comes to Outlook's contacts... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Wednesday, July 25, 2007 2:31 PM At 12:00 PM 7/25/2007, you wrote: >From: "jwcolby" Whooo, there cowboy. Without a PK, how are you going to identify rows for updates and delets? Good design REQUIRES a primary key of some kind even if it is a composite key. Try updating a SQL Server table linked to MS Access that does not have a primary key. It will not let you make any change to it at all. >AND... from the perspective of the child, a FK is nothing but a pointer. >Does a table HAVE TO HAVE a PK at all? Not if it has no children. >Ergo, what matters from the child's perspective is what the PK is all >about, and that is simply a POINTER back to the parent. AND... Since a >surrogate key functions as a PK, then... A PK must be nothing but a pointer... -- 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 john at winhaven.net Wed Jul 25 17:26:44 2007 From: john at winhaven.net (John Bartow) Date: Wed, 25 Jul 2007 17:26:44 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725214654.07370BE08@smtp-auth.no-ip.com> References: <005201c7cefa$33e6ad50$6402a8c0@ScuzzPaq> <20070725214654.07370BE08@smtp-auth.no-ip.com> Message-ID: <009201c7cf0a$e25e6c50$6402a8c0@ScuzzPaq> OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. From stuart at lexacorp.com.pg Wed Jul 25 18:26:56 2007 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Thu, 26 Jul 2007 09:26:56 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> References: <013f01c7ced5$1ed88250$6402a8c0@ScuzzPaq>, <20070725162016.43DFABD1C@smtp-auth.no-ip.com>, <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Message-ID: <46A7DC40.5047.433D1810@stuart.lexacorp.com.pg> On 25 Jul 2007 at 13:12, Arthur Fuller wrote: > rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the case > of a table called State/Provinces, consisting of about 62 rows representing > the states in USA and the provinces and territories in Canada. All of these > items can be represented uniquely by a two-letter combination. Why on earth > would you then introduce an ANPK into this table? It makes NO sense, IMO. It > rather exemplifies the ridiculous application of a maxim learned long ago > and adhered to since, without further examination. > Now imagine that your system expands and you need to another country in addition to US and Canada - what happens when another country has the same 2 letter abbreviation for one of their states/provinces? > Let's go further. Suppose your firm has 100 products all of which are > uniquely identified by three alpha characters. Why would you bother creating > an ANPK on said table? IMO it's asinine. You just force me to create joins > down the road (as in reporting), while providing me with no real gain in the > here and now. You wanna benchmark your index on an ANPK versus mine on a > three-letter alpha column? Ok? Let's go. I'll give you half a second > maximum, and then let's look at the rewards I get that you don't. > Been there, done that - after a few years, they merged with another firm and the codes had to be changed. Hell of a job to rebuild all the relationships. From ssharkins at gmail.com Wed Jul 25 18:56:09 2007 From: ssharkins at gmail.com (Susan Harkins) Date: Wed, 25 Jul 2007 19:56:09 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CE1@xlivmbx35.aig.com> Message-ID: <003e01c7cf17$6467a520$5cb62ad1@SusanOne> That's what I thought. Susan H. Well, just like a MailItem, a ContactItem has a property called "EntryID" which is of type String. For MailItems this looks like some kind of GUID... 00000000AF9B53E7CCFAD01199D500805FD4C8DA07001D7828CDB8350747AFE9D69E0E90DA1F 00001D15892D000034C8A2AB1EF3564CB0D64DB6AFFDD5C2000009BA2DB10000 And though I have not checked this out, I suspect the EntryID of a ContactItem is of the same form. From jwcolby at colbyconsulting.com Wed Jul 25 18:56:29 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 19:56:29 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070725235642.967DABC8F@smtp-auth.no-ip.com> Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com From jwcolby at colbyconsulting.com Wed Jul 25 18:57:01 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 19:57:01 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <009201c7cf0a$e25e6c50$6402a8c0@ScuzzPaq> Message-ID: <20070725235713.D6BA1BC8F@smtp-auth.no-ip.com> There are lots of tables that do not require a PK. Any table without children. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 6:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 19:31:36 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 20:31:36 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <009201c7cf0a$e25e6c50$6402a8c0@ScuzzPaq> Message-ID: <20070726003148.F107EBCA2@smtp-auth.no-ip.com> >Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Of course not, it would not be a relational db if there was not a child table. >Have you ever created a table that didn't have a PK? (when you were done creating it). Yes, but not often. I almost always add the ANPK whether or not I need one. But any table with no children does not require a PK in order to exist and contain data. In order to select it for editing / deletion is another story but it still does not have to contain a field, marked by the database as being a PK, nor does it have to have a unique index on it. ANY field(s) with unique data (candidate key) can be used in a where clause to pull a specific record or set of records for editing or deletion, and it does NOT have to be marked as the PK to do so. We all know what candidate keys are. They are a field or set of fields which taken together CURRENTLY contains data that is unique within that set of fields in that table. We all know that we can take any candidate key and use it as a FK in a child table. It is not marked in the parent as the PK, but the fact that (the data in) it is unique allows us to use that as the FK in the child table. So in fact by this example we can have a table FULL OF candidate keys DOZENS OF THEM if we can discover that many candidate keys. We can intentionally not designate any one of them as the PK, yet in fact we can use any valid candidate key as the FK (pointer back to the parent) in a child table. You can demonstrate that for yourself simply by doing a join on two such tables, or even by building a where clause on such candidate key. The FUNCTIONALITY of the PK is obtained even though no PK is specified in the parent table. That is why it is important to not get hung up on the model! A PK is an artificial construct from the get go. It is a useful construct but is not required to do many of the things that some people here on the list believe it is required for. Given that it is an artificial construct, and given that a surrogate ANPK can be substituted at the drop of a hat for a natural PK, and given that the ANPK solves many problems that are created by a natural PK, I choose in almost every case to use one. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 6:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Wed Jul 25 20:19:10 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Wed, 25 Jul 2007 18:19:10 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725235642.967DABC8F@smtp-auth.no-ip.com> References: <20070725235642.967DABC8F@smtp-auth.no-ip.com> Message-ID: That's cheating, John. From an interface, you need a PK. Why bother to be a stickler about anything if you're going to play directly in the tables? Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Wed Jul 25 20:54:00 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 25 Jul 2007 21:54:00 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726015413.0FBA8BCF1@smtp-auth.no-ip.com> >That's cheating, John. From an interface, you need a PK. I think you should look at your definition of a PK. I have already demonstrated that even from Access you do NOT have to have a PK. You have to have a candidate key, and you have to lie to Access and TELL ACCESS that some candidate key is the PK, but in fact it doesn't really have to be the PK of the SQL Server table. >Why bother to be a stickler about anything if you're going to play directly in the tables? I do a lot of "playing" directly in the tables. There are TONS of scenarios where direct fiddling in the tables is required - usually by various queries directly manipulating data. Have you not been reading about my application where I do all of this stuff in these huge tables and NEVER look at the data directly. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 9:19 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices That's cheating, John. From an interface, you need a PK. Why bother to be a stickler about anything if you're going to play directly in the tables? Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 developer at ultradnt.com Wed Jul 25 21:37:54 2007 From: developer at ultradnt.com (Steve Conklin) Date: Wed, 25 Jul 2007 22:37:54 -0400 Subject: [AccessD] check for file in ftp site In-Reply-To: References: Message-ID: <007601c7cf2d$fb5e55d0$0200a8c0@ULTRADNT> I don't necessarily want your file, but would rather see here a discussion of technique and maybe a couple lines of the most relevant code. I think more of us benefit that way. There are so many ways to do this - Are you using an API? A 3rd party client? Generating a script to use with the built-in FTP.exe (which is what I normally do) ? Tia, Steve -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte Sent: Tuesday, July 24, 2007 11:25 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] check for file in ftp site Hello All, I am more than happy to send almost anything to almost anyone...but as we are getting back into some of our Netiquette Practices...please send any other "Me Too"'s to me directly...to lessen the List traffic. Thanks, Mark A. Matte P.S...Doug, I sent you a copy already...good luck...its just an ugly scrapped together example. >From: "Doug Barnes" >Reply-To: Access Developers discussion and problem >solving >To: "Access Developers discussion and problem >solving" >Subject: Re: [AccessD] check for file in ftp site >Date: Tue, 24 Jul 2007 10:49:10 -0400 > >Would love to see a copy, as well > > >Douglas Barnes > >Starn Technical Services >P.O. Box 1172 >15957 Conneaut Lake Road, Suite 7 >Meadville, PA 16335 > >doug at starntech.com >P: 814.724.1045 >F: 814.337.3460 > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte >Sent: Monday, July 23, 2007 4:25 PM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] check for file in ftp site > > >Sending You a zip file offline. > > > >From: "Reuben Cummings" > >Reply-To: Access Developers discussion and problem > >solving > >To: "AccessD" > >Subject: [AccessD] check for file in ftp site > >Date: Mon, 23 Jul 2007 15:35:56 -0400 > > > >I am wanting to log into an ftp site, look thru all the txt files (only >txt > >files), and download all files that are new since the last check. > > > >The files are all numbered sequentially so I can parse out the numbers to > >determine what files are new. > > > >However, I could use some assistance in looping thru the txt file names. > > > >Thanks. > > > >Reuben Cummings > >GFC, LLC > >812.523.1017 > > > > > > > >-- > >AccessD mailing list > >AccessD at databaseadvisors.com > >http://databaseadvisors.com/mailman/listinfo/accessd > >Website: http://www.databaseadvisors.com > >_________________________________________________________________ >http://newlivehotmail.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 _________________________________________________________________ Need a brain boost? Recharge with a stimulating game. Play now! http://club.live.com/home.aspx?icid=club_hotmailtextlink1 From DWUTKA at Marlow.com Wed Jul 25 21:55:19 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Wed, 25 Jul 2007 21:55:19 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <29f585dd0707251012s181ae005oc3687eea77866270@mail.gmail.com> Message-ID: >From a bound front end, absolutely agree. There's no reason to have autonumbers in a lookup table... Until you go unbound. When dealing with a lookup table, there's no point in creating data integrity logic to deal with multiple people changing the same record. In a lot of cases, the change may be the same thing, but if the system thinks the pk is 'FL', and one person changes it to FLA, when another tries to change another field in the same record...you get jumbled. In a bound front end, not a problem, Access is going to lock the records for you. In an unbound solution, an autonumber primary key also fixes the problem. This is not to say that the key is used as a foreign key in other tables, it is strictly to maintain a unique id for a record. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Wednesday, July 25, 2007 12:12 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Apparently I have a much different view on this subject than most here. My view has evolved over years in this business, and changed due to increasing complexity of databases. 1. I used to think that ANPKs were the only way to go. Given a dozen or even two dozen tables, it made sense. Given 500 tables plus the low cost of disk space, I no longer agree with that model. As a consequence, I no longer agree that compound PKs are bad that ANPKs are always superior. 2. Any Front End worth its salt can easily pass multiple values to the BE to create a row in some related table. This is not difficult, and if the related table is something so simple as State/Province, containing about 62 rows each of which is uniquely identified by its abbreviation (i.e. SK = Saskatchewan, WY = Wyoming, FL = Florida), then what is gained by storing these as FKs derived from the States/Provinces table? Why not reduce said table to two columns, one being char(2) and the other being varchar(20)? What is gained by this strategy is that a table does not need to be joined in order to obtain the value that interests humans. 3. The aforementioned difficulty cascades to all related tables in the tree. Eventually you find yourself creating surrogate indexes on surrogate indexes in some related table, and it can cascade from there. With 5 or 6 tables, this may not seem an issue, but try 40 tables in a tree and you will get my point. 4. I used to be in the school of ANPKs everywhere but I have since departed, primarily due to the effects created in rich databases (e.g. large databases are a small number of tables with millions of rows; rich databases are a large number of tables with relatively few rows each; it's possible but seldom occurs that a db is both large and rich). In a rich database, I do not have the time to do 20 joins to grab the keys of the related data. I want it NOW, not one minute from now. Correctness of results and speed of retrieval are the most important tests. Disk space, long ago, was the paramount consideration, and caused many of us (including me) to think that ANPKs were the solution. Thanks to a couple of books I read, I have since then shed that illusion. That doesn't mean that I don't like ANPKs. I still love and treasure them. But I have learned that they don't belong in any table where the number of rows is fewer than 500 or so. It's silly. Disk space is cheap. Take the case of a table called State/Provinces, consisting of about 62 rows representing the states in USA and the provinces and territories in Canada. All of these items can be represented uniquely by a two-letter combination. Why on earth would you then introduce an ANPK into this table? It makes NO sense, IMO. It rather exemplifies the ridiculous application of a maxim learned long ago and adhered to since, without further examination. Let's go further. Suppose your firm has 100 products all of which are uniquely identified by three alpha characters. Why would you bother creating an ANPK on said table? IMO it's asinine. You just force me to create joins down the road (as in reporting), while providing me with no real gain in the here and now. You wanna benchmark your index on an ANPK versus mine on a three-letter alpha column? Ok? Let's go. I'll give you half a second maximum, and then let's look at the rewards I get that you don't. After 30 years in the database business, I have only recently come to appreciate the value of compound PKs and PKs that are not necessarily ANPKs. It's taken me a while to realize this, I confess, and I'm sure that many of you will disagree. But having been in the situation of 500 tables some of which have 50 million rows, and 20 joins are required for some query or other, I now understand that ANPKs are stupid in this situation. Far better, and 10 times faster, are meaningful char PKs such as the State/Province example listed above. In a given table, I already have the value "CA" meaning California. I don't need to reference an ANPK to look up this value -- I already have it. This perspective may make sense only to those who work with millions of rows in hundreds of tables. But that pretty much describes where I work. In these circumstances, I would definitely raise red flags wherever ANPKs are introduced in lookup tables, while defending their place in transaction tables. Arthur The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Wed Jul 25 22:01:05 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Wed, 25 Jul 2007 22:01:05 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <014301c7ced6$57f9a450$6402a8c0@ScuzzPaq> Message-ID: I have exposed an ANPK, in fact, the system I'm working on at the moment exposes it for the main table. It's a help desk system, and the Request table ID field, "TicketNumber" is an AutoNumber, the primary key, and is what the user sees as their 'ticket number'. As far as the concern of someone saying they have to be sequential...they are sequential. The interface provides NO way to delete a request. In fact, I find I build VERY few systems where I ever delete data. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 11:11 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices LOL! I actually have the same view on PK but have recently had to expose PKs in an application for a client. (Well, I suppose I could have told them NO but then I'd probably not still be working for them.) They implemented a new functionality in their GIS system. Instead of paying me to implement it correctly, they tried to have "local" firm implement the GIS (spatial) portion and retain me to do the "tabular" portion. (The whole thing is ridiculous but when you do government work you come to expect this.) Anyway, I had to expose the PK of certain tables in the interface because the "local" firm apparently doesn't know how to connect to an mdb in order to pull up a combo box in for the staff to choose from. Hence the staff is manually entering the PK to connect the spatial elements to the tabular elements. Wrought with danger is all I can say. I don't think the local firm is working there anymore - so hopefully I get to fix this mess some day }:-p -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby It comes from discussions here on this list where any time you expose the PK to view, some idiot wants to use it for some purpose that it is not supposed to be used for (like a "must be in order, with no values missing" number in an accounting system. Obviously we can and do delete records all the time so using the PK for such a rule / purpose guarantees issues whenever the idiot strikes, thus simply NEVER expose it to view. The PK's function (in real life) is exactly and only for use as a pointer from a child back to the parent. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From DWUTKA at Marlow.com Wed Jul 25 22:03:14 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Wed, 25 Jul 2007 22:03:14 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <002001c7cefe$5bc746f0$5cb62ad1@SusanOne> Message-ID: Not sure what he was getting at either, they do have id's, they just aren't exposed. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 3:57 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From john at winhaven.net Thu Jul 26 02:43:43 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 02:43:43 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <002001c7cefe$5bc746f0$5cb62ad1@SusanOne> Message-ID: <014301c7cf58$b1f62a00$6402a8c0@ScuzzPaq> They are not easy to work with. Depending on how you access them (CDO, VBA, MAPI) you get a different result. It seems easier to query by every field in the record than by the EntryID. Querying based on PKs is easy. Querying based on EntryIDs is a PITA. If I fill a combo box with EntryID and Fullname, then select a record based on that combo box I'd think it would be easiest to draw any other data fields info from Outlook using the EntryID as the criteria for queries. I'm not seeing it. To use the GetItemFromID method to retrieve data you first have to find the StoreID which is the ID of the folder containing the Contact (or whatever). So you find the item you want and work backward to find the container ID and then go forward again to find the data for the item. I'm at the point where I'm thinking I must have missed something critical. The methods I'm using to do this is no way to work with data. But - I was warned about it here so... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Wednesday, July 25, 2007 10:03 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Not sure what he was getting at either, they do have id's, they just aren't exposed. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, July 25, 2007 3:57 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices This is what is so befuddling to me when it comes to Outlook's contacts... ========Don't they have id's? From jimdettman at verizon.net Thu Jul 26 06:28:19 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 26 Jul 2007 07:28:19 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725235642.967DABC8F@smtp-auth.no-ip.com> References: <20070725235642.967DABC8F@smtp-auth.no-ip.com> Message-ID: <00cd01c7cf78$11c31050$8abea8c0@XPS> <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Thu Jul 26 06:33:07 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 26 Jul 2007 07:33:07 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070726003148.F107EBCA2@smtp-auth.no-ip.com> References: <009201c7cf0a$e25e6c50$6402a8c0@ScuzzPaq> <20070726003148.F107EBCA2@smtp-auth.no-ip.com> Message-ID: <00d101c7cf78$bd18e920$8abea8c0@XPS> John, <<>Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Of course not, it would not be a relational db if there was not a child table.>> That is not correct. A "relation" does not refer to the relationship between two tables, it refers to the tables themselves. When designing a relational system, before you can start the normalization process with 1NF, you have to form the relations using the following rules: The relation 1. Describes one entity. 2. Has no duplicate rows; hence there is always a primary key. 3. Columns are unordered. 4. Rows are unordered. Most definitely yes a single table is relational. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 8:32 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Of course not, it would not be a relational db if there was not a child table. >Have you ever created a table that didn't have a PK? (when you were done creating it). Yes, but not often. I almost always add the ANPK whether or not I need one. But any table with no children does not require a PK in order to exist and contain data. In order to select it for editing / deletion is another story but it still does not have to contain a field, marked by the database as being a PK, nor does it have to have a unique index on it. ANY field(s) with unique data (candidate key) can be used in a where clause to pull a specific record or set of records for editing or deletion, and it does NOT have to be marked as the PK to do so. We all know what candidate keys are. They are a field or set of fields which taken together CURRENTLY contains data that is unique within that set of fields in that table. We all know that we can take any candidate key and use it as a FK in a child table. It is not marked in the parent as the PK, but the fact that (the data in) it is unique allows us to use that as the FK in the child table. So in fact by this example we can have a table FULL OF candidate keys DOZENS OF THEM if we can discover that many candidate keys. We can intentionally not designate any one of them as the PK, yet in fact we can use any valid candidate key as the FK (pointer back to the parent) in a child table. You can demonstrate that for yourself simply by doing a join on two such tables, or even by building a where clause on such candidate key. The FUNCTIONALITY of the PK is obtained even though no PK is specified in the parent table. That is why it is important to not get hung up on the model! A PK is an artificial construct from the get go. It is a useful construct but is not required to do many of the things that some people here on the list believe it is required for. Given that it is an artificial construct, and given that a surrogate ANPK can be substituted at the drop of a hat for a natural PK, and given that the ANPK solves many problems that are created by a natural PK, I choose in almost every case to use one. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 6:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. -- 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 jwcolby at colbyconsulting.com Thu Jul 26 07:15:25 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 08:15:25 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00d101c7cf78$bd18e920$8abea8c0@XPS> Message-ID: <20070726121539.6EEC0BD62@smtp-auth.no-ip.com> Well then, there ya go. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:33 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices John, <<>Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Of course not, it would not be a relational db if there was not a child table.>> That is not correct. A "relation" does not refer to the relationship between two tables, it refers to the tables themselves. When designing a relational system, before you can start the normalization process with 1NF, you have to form the relations using the following rules: The relation 1. Describes one entity. 2. Has no duplicate rows; hence there is always a primary key. 3. Columns are unordered. 4. Rows are unordered. Most definitely yes a single table is relational. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 8:32 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >Have you ever created a one table relational database? (OK, smart alecs >- that remained so.) Of course not, it would not be a relational db if there was not a child table. >Have you ever created a table that didn't have a PK? (when you were >done creating it). Yes, but not often. I almost always add the ANPK whether or not I need one. But any table with no children does not require a PK in order to exist and contain data. In order to select it for editing / deletion is another story but it still does not have to contain a field, marked by the database as being a PK, nor does it have to have a unique index on it. ANY field(s) with unique data (candidate key) can be used in a where clause to pull a specific record or set of records for editing or deletion, and it does NOT have to be marked as the PK to do so. We all know what candidate keys are. They are a field or set of fields which taken together CURRENTLY contains data that is unique within that set of fields in that table. We all know that we can take any candidate key and use it as a FK in a child table. It is not marked in the parent as the PK, but the fact that (the data in) it is unique allows us to use that as the FK in the child table. So in fact by this example we can have a table FULL OF candidate keys DOZENS OF THEM if we can discover that many candidate keys. We can intentionally not designate any one of them as the PK, yet in fact we can use any valid candidate key as the FK (pointer back to the parent) in a child table. You can demonstrate that for yourself simply by doing a join on two such tables, or even by building a where clause on such candidate key. The FUNCTIONALITY of the PK is obtained even though no PK is specified in the parent table. That is why it is important to not get hung up on the model! A PK is an artificial construct from the get go. It is a useful construct but is not required to do many of the things that some people here on the list believe it is required for. Given that it is an artificial construct, and given that a surrogate ANPK can be substituted at the drop of a hat for a natural PK, and given that the ANPK solves many problems that are created by a natural PK, I choose in almost every case to use one. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Wednesday, July 25, 2007 6:27 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices OK now I think YOU'RE talking theoretically :o) What purpose would a one table database serve? And if there is a purpose would it even be considered relational? Sure I created spreadsheets that could be called databases but not by me, because I always mentally preface database with relational. I personally refer to a spreadsheet database as a list to avoid confusion. But all that aside I think we mostly agree on things here - it mostly nitpicky terminology/theory that some of us don't agree on. Yes or No: Have you ever created a one table relational database? (OK, smart alecs - that remained so.) Have you ever created a table that didn't have a PK? (when you were done creating it) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 4:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. -- 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 bbruen at unwired.com.au Thu Jul 26 07:30:03 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Thu, 26 Jul 2007 22:30:03 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> References: <20070725131815.187FDBD8E@smtp-auth.no-ip.com> Message-ID: <200707262230.04619.bbruen@unwired.com.au> On Wednesday 25 July 2007 23:18, jwcolby wrote: > Bruce, > > >Any table that does not have a natural primary key is not a pure dataset, > > ... > > No, Any table that does not have a natural primary key CANDIDATE is not a > pure dataset, ... > &< ..... Let me rephrase myself. 1) I'm not talking about indexes. 2) I'm not talking about Access/SQLServer/... tables I was trying to indicate a "best practice". If a tuple in a dataset cannot be uniquely identified by one (or possibly more) natural keys (made up of one or more "natural data" fields of the table), then the table is "badly formed" and further thought should be given to the schema design before any indexes, based on real or surrogate data should be considered. I just thought the quick statement could be a BP "rule" that the OP could have used. I didn't mean to start DBWarLVI. -- regards Bruce From ssharkins at gmail.com Thu Jul 26 07:39:08 2007 From: ssharkins at gmail.com (Susan Harkins) Date: Thu, 26 Jul 2007 08:39:08 -0400 Subject: [AccessD] Menu to Ribbon reference Message-ID: <000001c7cf82$04df9c50$5f32fad1@SusanOne> http://office.microsoft.com/en-au/word/HA100744321033.aspx?pid=CH10048743103 3 The number one complaint I've heard about Office 2007 is the ribbon -- we can't find anything! Well, here's an online reference guide. On dial-up, it took a few minutes to load, but seems to work well enough. Wish I'd found it sooner. ;) If someone's already posted it here, I missed it -- and I apologize for the repeat. Susan H. From jwcolby at colbyconsulting.com Thu Jul 26 07:57:47 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 08:57:47 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <00cd01c7cf78$11c31050$8abea8c0@XPS> Message-ID: <20070726125801.16114BD11@smtp-auth.no-ip.com> >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 jwcolby at colbyconsulting.com Thu Jul 26 08:07:05 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 09:07:05 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707262230.04619.bbruen@unwired.com.au> Message-ID: <20070726130719.A728DBDC6@smtp-auth.no-ip.com> Bruce, While the DATA may in fact be badly formed (the table is not!), in real life there are instances where the data is badly formed (there are duplicates) and yet the data is still usable and still used. And while I admire all the "tuple talk", there are way more people in the world (outside of academia) that understand tables, rows and fields. I have read the books, I understand the concepts, but I do not need to talk the model talk and find it more useful not to. And yes, I understand that there are those that treasure their tuples. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Thursday, July 26, 2007 8:30 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Wednesday 25 July 2007 23:18, jwcolby wrote: > Bruce, > > >Any table that does not have a natural primary key is not a pure > >dataset, > > ... > > No, Any table that does not have a natural primary key CANDIDATE is > not a pure dataset, ... > &< ..... Let me rephrase myself. 1) I'm not talking about indexes. 2) I'm not talking about Access/SQLServer/... tables I was trying to indicate a "best practice". If a tuple in a dataset cannot be uniquely identified by one (or possibly more) natural keys (made up of one or more "natural data" fields of the table), then the table is "badly formed" and further thought should be given to the schema design before any indexes, based on real or surrogate data should be considered. I just thought the quick statement could be a BP "rule" that the OP could have used. I didn't mean to start DBWarLVI. -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From fuller.artful at gmail.com Thu Jul 26 08:12:22 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Thu, 26 Jul 2007 09:12:22 -0400 Subject: [AccessD] Number of 'OR's in queries - what's the limit? In-Reply-To: <20070725191324.A7753BC78@smtp-auth.no-ip.com> References: <29f585dd0707251157o171d8dfdud2b5c0ad4ef99db4@mail.gmail.com> <20070725191324.A7753BC78@smtp-auth.no-ip.com> Message-ID: <29f585dd0707260612i1168ab48x1364e553b82d2f1b@mail.gmail.com> No need on the temp table since presumably it will only contain a relatively small number of records (<100, say). But of course the real table needs an index on the column you're examining with the IN() values. A. On 7/25/07, jwcolby wrote: > > Do you need to create an index on the field in the temp table? > > From jimdettman at verizon.net Thu Jul 26 08:32:42 2007 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 26 Jul 2007 09:32:42 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070726125801.16114BD11@smtp-auth.no-ip.com> References: <00cd01c7cf78$11c31050$8abea8c0@XPS> <20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: <003201c7cf89$71ef8420$8abea8c0@XPS> John, All I can say is once again you entirely missed the point. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 8:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 bbruen at unwired.com.au Thu Jul 26 08:33:27 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Thu, 26 Jul 2007 23:33:27 +1000 Subject: [AccessD] Menu to Ribbon reference In-Reply-To: <000001c7cf82$04df9c50$5f32fad1@SusanOne> References: <000001c7cf82$04df9c50$5f32fad1@SusanOne> Message-ID: <200707262333.27477.bbruen@unwired.com.au> On Thursday 26 July 2007 22:39, Susan Harkins wrote: > http://office.microsoft.com/en-au/word/HA100744321033.aspx?pid=CH1004874310 >3 3 > > The number one complaint I've heard about Office 2007 is the ribbon -- we > can't find anything! Well, here's an online reference guide. On dial-up, > it took a few minutes to load, but seems to work well enough. Wish I'd > found it sooner. ;) > > If someone's already posted it here, I missed it -- and I apologize for the > repeat. > > Susan H. Hey, hey! Yes I have seen this site. Here's my take. The ignition switch is now in the back seat ashtray. (You can access the back seat ashtray by getting the 864 bus to Muskgogy) The gear shift is in the the boot. The boot has been replaced by the new improved LSA (Click on the TLA link to discover the new improved glossary) ... ... ... GRRRRRRRRR ... ... LSA - Luggage stowage area. Microsoft now has an improved mechanism for transporting your luggage to wherever you want to go today. Its called the LSA. LSA offers both home and business users a new and improved way to get their luggage into approximately the same geographic location as their customers. Customers will immediately recognize the advantage of these new techniques. [Related topics] ... ... click ... 404:Not found (Still laughing hysterically) -- regards Bruce From ssharkins at gmail.com Thu Jul 26 08:46:34 2007 From: ssharkins at gmail.com (Susan Harkins) Date: Thu, 26 Jul 2007 09:46:34 -0400 Subject: [AccessD] Menu to Ribbon reference In-Reply-To: <200707262333.27477.bbruen@unwired.com.au> References: <000001c7cf82$04df9c50$5f32fad1@SusanOne> <200707262333.27477.bbruen@unwired.com.au> Message-ID: <001e01c7cf8b$6be2d4e0$7232fad1@SusanOne> click ... 404:Not found (Still laughing hysterically) =======Well, I'm so glad I could add to your entertainment! ;) Seriously, it worked Okay for me even though it took a while to load, but then, I didn't look around for long -- just looked up a few things and left. I was frustrated by a few items that wanted to redirect me to another online document. But, overall, it seems to work better than 2007 Help files -- now that leaves me totally frustrated, reading, reading, reading to find out "how" to actually access a feature -- whoever writes that stuff really doesn't understand what users need, and that's a shame. I keep telling them they need me... Susan H. From Jim.Hale at FleetPride.com Thu Jul 26 08:51:05 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 26 Jul 2007 08:51:05 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070725151912.941B1BCEA@smtp-auth.no-ip.com> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: LOL And how many times have we heard this from clients particularly when they are justifying bad design or databases that "work" but not really well. I think we have to grant Jim the point that the more we understand relational theory and its nuances the better we can make informed decisions in structuring designs. I am not a slave to relational theory but if I'm going to design away from dogma I want my choice to be an informed one weighing the pros and cons. After all, these programs do purport to be relational so the more we understand where they succeeed or fail the better we become as developers. As a power user I began building "databases" long before I ever heard of relational theory. As I began learning the theory I understood how flawed and unscalable many of my constructs were. Today the databases I build don't religiously follow the gospel according to Codd but are better as I more closely understand and follow the relational model. Assuming that relational theory, at least in the abstract, is a logical internally consistent theory that works and is worth using, it is a "best practice" to implement the theory SUBJECT TO the constraints imposed by the hardware and software platforms being used. Jim Hale *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From mmattys at rochester.rr.com Thu Jul 26 09:04:13 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Thu, 26 Jul 2007 10:04:13 -0400 Subject: [AccessD] Primary Key Best Practices References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: <008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop> >2. Has no duplicate rows; hence there is always a primary key. So then, I should conclude that if there is no PK then I should add one to make the table 'relational' and -in practice- the fastest, most reliable way to do that is to add an AUTONUMBER? LOL!!! Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: "Hale, Jim" To: "Access Developers discussion and problem solving" Sent: Thursday, July 26, 2007 9:51 AM Subject: Re: [AccessD] Primary Key Best Practices > > > what works.> > > LOL And how many times have we heard this from clients particularly when > they are justifying bad design or databases that "work" but not really > well. I think we have to grant Jim the point that the more we understand > relational theory and its nuances the better we can make informed > decisions in structuring designs. I am not a slave to relational theory > but if I'm going to design away from dogma I want my choice to be an > informed one weighing the pros and cons. After all, these programs do > purport to be relational so the more we understand where they succeeed > or fail the better we become as developers. As a power user I began > building "databases" long before I ever heard of relational theory. As I > began learning the theory I understood how flawed and unscalable many of > my constructs were. Today the databases I build don't religiously follow > the gospel according to Codd but are better as I more closely understand > and follow the relational model. Assuming that relational theory, at > least in the abstract, is a logical internally consistent theory that > works and is worth using, it is a "best practice" to implement the > theory SUBJECT TO the constraints imposed by the hardware and software > platforms being used. > > Jim Hale > > > *********************************************************************** > The information transmitted is intended solely for the individual or > entity to which it is addressed and may contain confidential and/or > privileged material. Any review, retransmission, dissemination or > other use of or taking action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. > If you have received this email in error please contact the sender and > delete the material from any computer. As a recipient of this email, > you are responsible for screening its contents and the contents of any > attachments for the presence of viruses. No liability is accepted for > any damages caused by any virus transmitted by this email. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From bbruen at unwired.com.au Thu Jul 26 09:29:17 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Fri, 27 Jul 2007 00:29:17 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: <200707270029.17570.bbruen@unwired.com.au> On Thursday 26 July 2007 23:51, Hale, Jim wrote: 8< > it is a "best practice" to implement the > theory SUBJECT TO the constraints imposed by the hardware and software > platforms being used > 8< and may I permissably add: and communicate those constraints so imposed, in such a way that subsequent enquiring monkeys have at least half a chance -- regards Bruce From jwcolby at colbyconsulting.com Thu Jul 26 09:41:16 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 10:41:16 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707270029.17570.bbruen@unwired.com.au> Message-ID: <20070726144130.BB22CBD43@smtp-auth.no-ip.com> ROTFL. If only! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Thursday, July 26, 2007 10:29 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Thursday 26 July 2007 23:51, Hale, Jim wrote: 8< > it is a "best practice" to implement the theory SUBJECT TO the > constraints imposed by the hardware and software platforms being used > 8< and may I permissably add: and communicate those constraints so imposed, in such a way that subsequent enquiring monkeys have at least half a chance -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bbruen at unwired.com.au Thu Jul 26 09:43:11 2007 From: bbruen at unwired.com.au (Bruce Bruen) Date: Fri, 27 Jul 2007 00:43:11 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop> Message-ID: <200707270043.11462.bbruen@unwired.com.au> To get banal, lets consider a dataset that consists of one and only one column "NumberOfItemsOrdered". It has, as of this moments snapshot, 234867 rows: 1 4 87 8734 (null) 1 34 six 224 ... 1 Of what possible use it this? Where are the problems? Why are we debating this? -- regards Bruce From markamatte at hotmail.com Thu Jul 26 10:04:40 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 26 Jul 2007 15:04:40 +0000 Subject: [AccessD] check for file in ftp site In-Reply-To: <007601c7cf2d$fb5e55d0$0200a8c0@ULTRADNT> Message-ID: Steve, I am using API calls. I'll send out something later tonight. Thanks, Mark >From: "Steve Conklin" >Reply-To: Access Developers discussion and problem >solving >To: "'Access Developers discussion and problem >solving'" >Subject: Re: [AccessD] check for file in ftp site >Date: Wed, 25 Jul 2007 22:37:54 -0400 > >I don't necessarily want your file, but would rather see here a discussion >of technique and maybe a couple lines of the most relevant code. I think >more of us benefit that way. There are so many ways to do this - Are you >using an API? A 3rd party client? Generating a script to use with the >built-in FTP.exe (which is what I normally do) ? > >Tia, >Steve > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark A Matte >Sent: Tuesday, July 24, 2007 11:25 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] check for file in ftp site > >Hello All, > >I am more than happy to send almost anything to almost anyone...but as we >are getting back into some of our Netiquette Practices...please send any >other "Me Too"'s to me directly...to lessen the List traffic. > >Thanks, > >Mark A. Matte > >P.S...Doug, I sent you a copy already...good luck...its just an ugly >scrapped together example. > > > >From: "Doug Barnes" > >Reply-To: Access Developers discussion and problem > >solving > >To: "Access Developers discussion and problem > >solving" > >Subject: Re: [AccessD] check for file in ftp site > >Date: Tue, 24 Jul 2007 10:49:10 -0400 > > > >Would love to see a copy, as well > > > > > >Douglas Barnes > > > >Starn Technical Services > >P.O. Box 1172 > >15957 Conneaut Lake Road, Suite 7 > >Meadville, PA 16335 > > > >doug at starntech.com > >P: 814.724.1045 > >F: 814.337.3460 > > > > > >-----Original Message----- > >From: accessd-bounces at databaseadvisors.com > >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte > >Sent: Monday, July 23, 2007 4:25 PM > >To: accessd at databaseadvisors.com > >Subject: Re: [AccessD] check for file in ftp site > > > > > >Sending You a zip file offline. > > > > > > >From: "Reuben Cummings" > > >Reply-To: Access Developers discussion and problem > > >solving > > >To: "AccessD" > > >Subject: [AccessD] check for file in ftp site > > >Date: Mon, 23 Jul 2007 15:35:56 -0400 > > > > > >I am wanting to log into an ftp site, look thru all the txt files (only > >txt > > >files), and download all files that are new since the last check. > > > > > >The files are all numbered sequentially so I can parse out the numbers >to > > >determine what files are new. > > > > > >However, I could use some assistance in looping thru the txt file >names. > > > > > >Thanks. > > > > > >Reuben Cummings > > >GFC, LLC > > >812.523.1017 > > > > > > > > > > > >-- > > >AccessD mailing list > > >AccessD at databaseadvisors.com > > >http://databaseadvisors.com/mailman/listinfo/accessd > > >Website: http://www.databaseadvisors.com > > > >_________________________________________________________________ > >http://newlivehotmail.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 > >_________________________________________________________________ >Need a brain boost? Recharge with a stimulating game. Play now! >http://club.live.com/home.aspx?icid=club_hotmailtextlink1 > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Need a brain boost? Recharge with a stimulating game. Play now!? http://club.live.com/home.aspx?icid=club_hotmailtextlink1 From mmattys at rochester.rr.com Thu Jul 26 10:17:23 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Thu, 26 Jul 2007 11:17:23 -0400 Subject: [AccessD] Primary Key Best Practices References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop> <200707270043.11462.bbruen@unwired.com.au> Message-ID: <011a01c7cf98$12359ab0$0202a8c0@Laptop> Is this OT yet? These could possibly be used for: names of pushpins on a map - (all have latitude and longitude) filenames, including Null - (all have a timestamp based upon the vibration of an atom or crystal) [Duplicate timestamps occur after several billion years, but who cares?] Problem: I wouldn't have a problem as long as records are kept of where or when. Otherwise, I can't reliably locate the record by it's name in this column. We are debating this because the records of where or when are not always kept or communicated, as far as we know. Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: "Bruce Bruen" To: "Access Developers discussion and problem solving" Sent: Thursday, July 26, 2007 10:43 AM Subject: Re: [AccessD] Primary Key Best Practices > To get banal, lets consider a dataset that consists of one and only one > column "NumberOfItemsOrdered". It has, as of this moments snapshot, 234867 > rows: > 1 > 4 > 87 > 8734 > (null) > 1 > 34 > six > 224 > ... > 1 > > Of what possible use it this? Where are the problems? Why are we debating > this? > > -- > regards > > Bruce From iggy at nanaimo.ark.com Thu Jul 26 11:06:43 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Thu, 26 Jul 2007 09:06:43 -0700 Subject: [AccessD] Page Orientation 2003 Message-ID: <46A8C693.6040805@nanaimo.ark.com> Hey All Finally made the move to Access2003. I am in the process of converting an Access97 application to Access2003. Code that I have used for years to change the page orientation on a preview report in Access97 no longer seems to work. I have a little freebie DELL printer that came with the machine. If I set the printer default to Landscape then I cannot change it to Portrait when previewing a report and vica versa. I have downloaded examples from Microsoft, I can change the page size but not the orientation. Before I start moving printers around I just thought I would ask, could this be a printer specific problem I am running into here? Thank you. From cfoust at infostatsystems.com Thu Jul 26 11:05:19 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 09:05:19 -0700 Subject: [AccessD] Menu to Ribbon reference In-Reply-To: <001e01c7cf8b$6be2d4e0$7232fad1@SusanOne> References: <000001c7cf82$04df9c50$5f32fad1@SusanOne><200707262333.27477.bbruen@unwired.com.au> <001e01c7cf8b$6be2d4e0$7232fad1@SusanOne> Message-ID: The word wrap must have bitten somebody who wasn't paying attention .... Works just fine for me. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Thursday, July 26, 2007 6:47 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Menu to Ribbon reference click ... 404:Not found (Still laughing hysterically) =======Well, I'm so glad I could add to your entertainment! ;) Seriously, it worked Okay for me even though it took a while to load, but then, I didn't look around for long -- just looked up a few things and left. I was frustrated by a few items that wanted to redirect me to another online document. But, overall, it seems to work better than 2007 Help files -- now that leaves me totally frustrated, reading, reading, reading to find out "how" to actually access a feature -- whoever writes that stuff really doesn't understand what users need, and that's a shame. I keep telling them they need me... Susan H. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Thu Jul 26 11:28:05 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 09:28:05 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070726125801.16114BD11@smtp-auth.no-ip.com> References: <00cd01c7cf78$11c31050$8abea8c0@XPS> <20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 DWUTKA at Marlow.com Thu Jul 26 11:38:02 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 26 Jul 2007 11:38:02 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: It's no wonder JWC and I get along so well! ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:28 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From Jim.Hale at FleetPride.com Thu Jul 26 11:45:21 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 26 Jul 2007 11:45:21 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707270029.17570.bbruen@unwired.com.au> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS><20070725151912.941B1BCEA@sm tp-auth.no-ip.com> <200707270029.17570.bbruen@unwired.com.au> Message-ID: LOL, Nah I think it's more fun to figure out the dimensions of a room by running full speed into each wall. At least master Gates seems to think so......... Jim Hale -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bruce Bruen Sent: Thursday, July 26, 2007 9:29 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On Thursday 26 July 2007 23:51, Hale, Jim wrote: 8< > it is a "best practice" to implement the > theory SUBJECT TO the constraints imposed by the hardware and software > platforms being used > 8< and may I permissably add: and communicate those constraints so imposed, in such a way that subsequent enquiring monkeys have at least half a chance -- regards Bruce -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From jwcolby at colbyconsulting.com Thu Jul 26 11:45:43 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 12:45:43 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726164558.01C08BC72@smtp-auth.no-ip.com> Charlotte, c'mon. I am not willfully misrepresenting anything. You said it could not be done, I showed that it can. Perhaps you are willfully not being specific in what you are saying? Someone states you HAVE TO HAVE A PK to edit a table in SQL Server. That is just plain FALSE. I DEMONSTRATED how it was false. If you don't like that answer then demonstrate HOW IT IS TRUE, do not attempt to claim that I am "willfully misrepresenting" something. I do not see you or anyone else disputing what I said, other than a whimpering "you just misinterpreted" or "you obviously missed the point again". Whimper all you want but don't expect me to sympathize when you do not come up with how my examples are wrong. I learn from this list all the time, but to be honest there is not much to learn from "you misrepresented" or "you obviously missed the point". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 jwcolby at colbyconsulting.com Thu Jul 26 11:46:44 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 12:46:44 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726164658.2690DBD34@smtp-auth.no-ip.com> OMG! DON'T SAY THAT! ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 26, 2007 12:38 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices It's no wonder JWC and I get along so well! ;) Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:28 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Thu Jul 26 11:50:38 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 11:50:38 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00cd01c7cf78$11c31050$8abea8c0@XPS><20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: <024a01c7cfa5$19030410$6402a8c0@ScuzzPaq> LOL! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL From john at winhaven.net Thu Jul 26 11:50:38 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 11:50:38 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <011a01c7cf98$12359ab0$0202a8c0@Laptop> References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS><008c01c7cf8d$d9f4dcb0$0202a8c0@Laptop><200707270043.11462.bbruen@unwired.com.au> <011a01c7cf98$12359ab0$0202a8c0@Laptop> Message-ID: <024e01c7cfa5$1b67a800$6402a8c0@ScuzzPaq> LOL! NOW the mapping guy gets into it! ;o) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Michael R Mattys Sent: Thursday, July 26, 2007 10:17 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Is this OT yet? These could possibly be used for: names of pushpins on a map - (all have latitude and longitude) From cfoust at infostatsystems.com Thu Jul 26 11:55:12 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 09:55:12 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070726164558.01C08BC72@smtp-auth.no-ip.com> References: <20070726164558.01C08BC72@smtp-auth.no-ip.com> Message-ID: John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, c'mon. I am not willfully misrepresenting anything. You said it could not be done, I showed that it can. Perhaps you are willfully not being specific in what you are saying? Someone states you HAVE TO HAVE A PK to edit a table in SQL Server. That is just plain FALSE. I DEMONSTRATED how it was false. If you don't like that answer then demonstrate HOW IT IS TRUE, do not attempt to claim that I am "willfully misrepresenting" something. I do not see you or anyone else disputing what I said, other than a whimpering "you just misinterpreted" or "you obviously missed the point again". Whimper all you want but don't expect me to sympathize when you do not come up with how my examples are wrong. I learn from this list all the time, but to be honest there is not much to learn from "you misrepresented" or "you obviously missed the point". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 john at winhaven.net Thu Jul 26 11:55:42 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 11:55:42 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00ff01c7cec9$f605ebc0$8abea8c0@XPS> <20070725151912.941B1BCEA@smtp-auth.no-ip.com> Message-ID: <025501c7cfa5$cfe2cfd0$6402a8c0@ScuzzPaq> Hence the value of these "discussions" once in awhile. There are many nuances to designing an appropriate application/data structure to best meet the demands of its intended use. I doubt any one here adheres 100% to the Book of Codd. Knowing what experts like you and some of the others involved in this thread have done in addition (or in lieu off) relational theory is of great benefit to many others lurking about (or poking and prodding with questions). I have certainly picked at least one good tip! Thank you all for your input! John B. Now, let's all wipe the foam off and get back to work ;o) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim LOL And how many times have we heard this from clients particularly when they are justifying bad design or databases that "work" but not really well. I think we have to grant Jim the point that the more we understand relational theory and its nuances the better we can make informed decisions in structuring designs. I am not a slave to relational theory but if I'm going to design away from dogma I want my choice to be an informed one weighing the pros and cons. After all, these programs do purport to be relational so the more we understand where they succeeed or fail the better we become as developers. As a power user I began building "databases" long before I ever heard of relational theory. As I began learning the theory I understood how flawed and unscalable many of my constructs were. Today the databases I build don't religiously follow the gospel according to Codd but are better as I more closely understand and follow the relational model. Assuming that relational theory, at least in the abstract, is a logical internally consistent theory that works and is worth using, it is a "best practice" to implement the theory SUBJECT TO the constraints imposed by the hardware and software platforms being used. From DWUTKA at Marlow.com Thu Jul 26 12:09:30 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 26 Jul 2007 12:09:30 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: I have to agree with JWC on this (which means either this thread is done, or the world is going to stop spinning soon....either/or). How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective? A statement was made, JWC showed it was a false statement, and instead of admitting that the statement is false, you are saying it's true because it's true for a user? Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:55 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From ewaldt at gdls.com Thu Jul 26 12:22:03 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 26 Jul 2007 13:22:03 -0400 Subject: [AccessD] Importing from Excel In-Reply-To: Message-ID: Importing from Excel is really simple, of course, if there's a single row of titles, followed by rows of data. In my case, users get two workbooks a week, each having two worksheets; one worksheet has data starting on row 4, the other on row 3 . They are consistent, and I can refer to them by their sheet names (say USA for the first, Can for the second). Once I get to the data row, things are fairly consistent, the exception being that sometimes the data rows stop, a line of information is inserted, and then the data rows start again. Even then, the data columns continue where they left off. If I were to get the workbooks at my desk, I'd use VBA within Excel to combine them into a 3rd sheet, clean them up, and then have Access import the new sheet. However, the people wanting to move the data into Access won't want to do this. I'm looking for favorite methods here. How would you go about doing this strictly from Access? TIA. Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From jwcolby at colbyconsulting.com Thu Jul 26 12:27:40 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 13:27:40 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726172754.275C9BEDD@smtp-auth.no-ip.com> Charlotte, SQL Server cheerfully passes it's abilities along to the outside world. Have you even tried the things I discussed "from the outside"? I suggest that you will be surprised by the answers. I just recreated my simple test table, two fields, char(1). I DID NOT create a PK, nor an index on the table. I went into ACCESS and created a DSN to that database, and linked that table. I just entered data into the table. Do it yourself for crying out loud. It works. NO PK. NO INDEX. Yes, I lied to SQL Server (or more correctly the DSN building wizard) and told it that there was a PK but in actual fact there is not one. I told it that the first field was the PK. Access put a PK symbol on that field. It now tells me (in design view) that there is a "yes, no duplicates" index on that field. I placed this data in the fields A b C d A b C d Access allowed me to enter this data, it stored in SQL Server. I can edit those records where the data is unique, I cannot where the data is not unique. When I attempt to delete one of the duplicate records, BOTH delete. We know why. But in any case, there is no PK (in the data store, SQL Server). I have checked, I did not create any, nor did sql server on Access' request. There are no indexes in SQL Server. And yet Access CAN ADD RECORDS, Access CAN EDIT RECORDS, and Access CAN DELETE RECORDS, Access can even delete the duplicates (both at once). I would like to reiterate that I have tried this stuff, I have PROVEN that your statement is FALSE, SQL Server CAN create tables without a PK, it can accept data into that table, it can update data in that table, and it can delete data in that table, ALL FROM A USER INTERFACE (ACCESS). You (and others as well) make blanket statements about things you have never even tried. I on the other hand have tried it and stand behind my statements with demonstrable facts! John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, c'mon. I am not willfully misrepresenting anything. You said it could not be done, I showed that it can. Perhaps you are willfully not being specific in what you are saying? Someone states you HAVE TO HAVE A PK to edit a table in SQL Server. That is just plain FALSE. I DEMONSTRATED how it was false. If you don't like that answer then demonstrate HOW IT IS TRUE, do not attempt to claim that I am "willfully misrepresenting" something. I do not see you or anyone else disputing what I said, other than a whimpering "you just misinterpreted" or "you obviously missed the point again". Whimper all you want but don't expect me to sympathize when you do not come up with how my examples are wrong. I learn from this list all the time, but to be honest there is not much to learn from "you misrepresented" or "you obviously missed the point". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 Lambert.Heenan at AIG.com Thu Jul 26 12:29:53 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Thu, 26 Jul 2007 12:29:53 -0500 Subject: [AccessD] Primary Key Best Practices Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> I do whish this thread would come to an end. It seem to be just fodder for the personality contestants. "How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective?" - because this is an ACCESS database development list, and as far as SQL server goes, we are users (unless like John you have a server farm in the back room and are running the whole show single handed). Ok. So Charlotte initially said "you cannot do X", and then John pounced and said "yes you can". Big deal. Charlotte did not explicitly specify "In Access", and John in his rebuttal kinda sorta forgot to explicitly mention he was working inside SQL server. Big deal again. I repeat, this is an Access developer list. We should be talking about what you can and can't do in Access (which is what Charlotte did). Ok. Compare and contrast with other RDBMS, but do we really need dozens of "she said / he said" messages on a somewhat tired topic? Please deep six it. Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 26, 2007 1:10 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices I have to agree with JWC on this (which means either this thread is done, or the world is going to stop spinning soon....either/or). How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective? A statement was made, JWC showed it was a false statement, and instead of admitting that the statement is false, you are saying it's true because it's true for a user? Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:55 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ebarro at verizon.net Thu Jul 26 12:31:16 2007 From: ebarro at verizon.net (Eric Barro) Date: Thu, 26 Jul 2007 10:31:16 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <0JLS000MIRCJL0H0@vms048.mailsrvcs.net> Charlotte, Access developers by default have access to the tables in the database container because by default they are the equivalent of SA in SQL server. Hence when you develop in Access you take the point of view of not only the user but the DBA as well. Both Jim and yourself and many others who use Microsoft Access develop database applications have to deal with tables don't you? Granted, Colby is very passionate about this views and opinions, but he has a valid point and he has provided proof. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 9:55 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, c'mon. I am not willfully misrepresenting anything. You said it could not be done, I showed that it can. Perhaps you are willfully not being specific in what you are saying? Someone states you HAVE TO HAVE A PK to edit a table in SQL Server. That is just plain FALSE. I DEMONSTRATED how it was false. If you don't like that answer then demonstrate HOW IT IS TRUE, do not attempt to claim that I am "willfully misrepresenting" something. I do not see you or anyone else disputing what I said, other than a whimpering "you just misinterpreted" or "you obviously missed the point again". Whimper all you want but don't expect me to sympathize when you do not come up with how my examples are wrong. I learn from this list all the time, but to be honest there is not much to learn from "you misrepresented" or "you obviously missed the point". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.20/919 - Release Date: 7/26/2007 9:56 AM From DWUTKA at Marlow.com Thu Jul 26 12:38:08 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Thu, 26 Jul 2007 12:38:08 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> Message-ID: You have a point. However, SQL Server is no longer a dba or IT Department system. You can get SQL Server Express for free, so anyone with a computer with a few gigs of extra drive space can run their own SQL Server databases. As far as this thread goes, I haven't been participating much, but I have been skimming the posts. Ego issues aside, it is a wonderful exchange of theory and practice in regards to databases in general...I think it should go until it runs it's course. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Thursday, July 26, 2007 12:30 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I do whish this thread would come to an end. It seem to be just fodder for the personality contestants. "How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective?" - because this is an ACCESS database development list, and as far as SQL server goes, we are users (unless like John you have a server farm in the back room and are running the whole show single handed). Ok. So Charlotte initially said "you cannot do X", and then John pounced and said "yes you can". Big deal. Charlotte did not explicitly specify "In Access", and John in his rebuttal kinda sorta forgot to explicitly mention he was working inside SQL server. Big deal again. I repeat, this is an Access developer list. We should be talking about what you can and can't do in Access (which is what Charlotte did). Ok. Compare and contrast with other RDBMS, but do we really need dozens of "she said / he said" messages on a somewhat tired topic? Please deep six it. Lambert The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From jwcolby at colbyconsulting.com Thu Jul 26 12:41:58 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 13:41:58 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070726174212.D575FBEF8@smtp-auth.no-ip.com> And it isn't even true for a user!!! And why do I get in full flaming mode? Because of people making completely unsubstantiated claims. People tend to accept what they have been told and never have occasion to or need to test whether in fact it is true. The problem becomes when they dogmatically insist that what they were told is true without ever actually trying it. It happens that I work all the time in tables of raw data directly imported in to sql server. I know the reality because I see it demonstrated to me. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, July 26, 2007 1:10 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices I have to agree with JWC on this (which means either this thread is done, or the world is going to stop spinning soon....either/or). How can you defend your position by stating on a DATABASE development list that your arguments are from a user prospective? A statement was made, JWC showed it was a false statement, and instead of admitting that the statement is false, you are saying it's true because it's true for a user? Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 11:55 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices John, You tend to be highly selective about what you choose to ignore when you're in full flaming mode. Only dbas and sas are allowed in SQL Server tables, not users. This is a developer's list. We develop database APPLICATIONS. That generally means that someone interacts with the database through an application or from code, not directly in the tables. Both Jim and I are coming from a database application orientation, which you are cheerfully discrediting by pointing out that it doesn't work that way INSIDE SQL SERVER! We are not in the same argument, and I've grown weary of pointing that out. Charlotte The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From listmaster at databaseadvisors.com Thu Jul 26 12:59:31 2007 From: listmaster at databaseadvisors.com (Bryan Carbonnell) Date: Thu, 26 Jul 2007 13:59:31 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> Message-ID: On 7/26/07, Heenan, Lambert wrote: > I do whish this thread would come to an end. It seem to be just fodder for > the personality contestants. > > "How can you defend your position by stating on a DATABASE development list > that your arguments are from a user prospective?" - because this is an > ACCESS database development list, and as far as SQL server goes, we are > users (unless like John you have a server farm in the back room and are > running the whole show single handed). > > Ok. So Charlotte initially said "you cannot do X", and then John pounced and > said "yes you can". > > Big deal. Charlotte did not explicitly specify "In Access", and John in his > rebuttal kinda sorta forgot to explicitly mention he was working inside SQL > server. Big deal again. > > I repeat, this is an Access developer list. We should be talking about what > you can and can't do in Access (which is what Charlotte did). Ok. Compare > and contrast with other RDBMS, but do we really need dozens of "she said / > he said" messages on a somewhat tired topic? > > Please deep six it. These kinds of comments should NEVER go to the list. They should ALWAYS be addressed to one of our moderators. It has been said time and time again, DO NOT TAKE THIS KIND OF REQUEST UPON YOURSELF. That's what we have moderators for. Your friendly neghbourhood (and slightly pissed) Listmaster, Bryan Carbonnell - listmaster at databaseadvisors.com From robert at webedb.com Thu Jul 26 13:04:13 2007 From: robert at webedb.com (Robert L. Stewart) Date: Thu, 26 Jul 2007 13:04:13 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <200707261810.l6QIAQwq006122@databaseadvisors.com> I have watched all the flaming and was surprised at the lack of intelligence and total stubborness in some of it. I do not know if what I do is best practice or not. But, I will go with consistency. In a transactional database, all tables have a surrogate, autonumbering primary key. They also have one or more unique indexes on the candidate key or keys. Also, indexes on all foreign key columns. In a data warehouse or data mart, all dimension tables will have a single column primary key inherited from the source primary table. All fact tables will have multiple columns that make up the primary key. There are no snowflakes. It is a true star schema. Best practice or not, as long as I am consistent in my designs, I will always know how to use it properly. And, I can always explain it to the monkeys that come after. Robert From john at winhaven.net Thu Jul 26 13:14:40 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 13:14:40 -0500 Subject: [AccessD] Primary Key Best Practices - MODERATOR NOTICE In-Reply-To: References: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6CF7@xlivmbx35.aig.com> Message-ID: <028901c7cfb0$d5ff98c0$6402a8c0@ScuzzPaq> Please - let's keep this as civil as possible. It's a good discussion and I pointed that out earlier today but it has been degrading ever since. You're all good people with opinions - let's remember that... Or I'll have to sick the list master on you all! ;o) From jwcolby at colbyconsulting.com Thu Jul 26 13:21:44 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 14:21:44 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707261810.l6QIAQwq006122@databaseadvisors.com> Message-ID: <20070726182158.B2C0CBCDD@smtp-auth.no-ip.com> Robert, I know nothing about data warehouses. Would you define fact table and explain why the PK is a natural key? I assume that it has to do with speed but beyond that could you explain the concepts a little? I am just looking to learn something here about a subject I know nothing about. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Thursday, July 26, 2007 2:04 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices I have watched all the flaming and was surprised at the lack of intelligence and total stubborness in some of it. I do not know if what I do is best practice or not. But, I will go with consistency. In a transactional database, all tables have a surrogate, autonumbering primary key. They also have one or more unique indexes on the candidate key or keys. Also, indexes on all foreign key columns. In a data warehouse or data mart, all dimension tables will have a single column primary key inherited from the source primary table. All fact tables will have multiple columns that make up the primary key. There are no snowflakes. It is a true star schema. Best practice or not, as long as I am consistent in my designs, I will always know how to use it properly. And, I can always explain it to the monkeys that come after. Robert -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Thu Jul 26 13:31:16 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 11:31:16 -0700 Subject: [AccessD] Data Warehouse (Was: Primary Key Best Practices) In-Reply-To: <200707261810.l6QIAQwq006122@databaseadvisors.com> References: <200707261810.l6QIAQwq006122@databaseadvisors.com> Message-ID: Can you give an example of a typical dimension table and what you mean by the source primary table? I've worked primarily with date dimensions using the date as the PK. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Thursday, July 26, 2007 11:04 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices I have watched all the flaming and was surprised at the lack of intelligence and total stubborness in some of it. I do not know if what I do is best practice or not. But, I will go with consistency. In a transactional database, all tables have a surrogate, autonumbering primary key. They also have one or more unique indexes on the candidate key or keys. Also, indexes on all foreign key columns. In a data warehouse or data mart, all dimension tables will have a single column primary key inherited from the source primary table. All fact tables will have multiple columns that make up the primary key. There are no snowflakes. It is a true star schema. Best practice or not, as long as I am consistent in my designs, I will always know how to use it properly. And, I can always explain it to the monkeys that come after. Robert -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Thu Jul 26 13:33:30 2007 From: john at winhaven.net (John Bartow) Date: Thu, 26 Jul 2007 13:33:30 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707261810.l6QIAQwq006122@databaseadvisors.com> References: <200707261810.l6QIAQwq006122@databaseadvisors.com> Message-ID: <029c01c7cfb3$784b60d0$6402a8c0@ScuzzPaq> Great points! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart In a transactional database, all tables have a surrogate, autonumbering primary key. They also have one or more unique indexes on the candidate key or keys. Also, indexes on all foreign key columns. In a data warehouse or data mart, all dimension tables will have a single column primary key inherited from the source primary table. All fact tables will have multiple columns that make up the primary key. There are no snowflakes. It is a true star schema. From martyconnelly at shaw.ca Thu Jul 26 13:40:09 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 26 Jul 2007 11:40:09 -0700 Subject: [AccessD] Menu to Ribbon reference In-Reply-To: <000001c7cf82$04df9c50$5f32fad1@SusanOne> References: <000001c7cf82$04df9c50$5f32fad1@SusanOne> Message-ID: <46A8EA89.5080909@shaw.ca> Here is a $15 cheat for Word 2007 There are a couple of others out there. Addin for Office 2003 menus to Office 2007 http://news.office-watch.com/t/n.aspx?a=502 Here is a download I got from Allen Browne's Links that might help Access Menu/Toolbar to Ribbon Excel workbook from Microsoft, It matches all previous Access 2003 menu and toolbar items to the new ribbon locations. http://office.microsoft.com/search/redir.aspx?AssetID=AM101757761033 Susan Harkins wrote: >http://office.microsoft.com/en-au/word/HA100744321033.aspx?pid=CH10048743103 >3 > >The number one complaint I've heard about Office 2007 is the ribbon -- we >can't find anything! Well, here's an online reference guide. On dial-up, it >took a few minutes to load, but seems to work well enough. Wish I'd found it >sooner. ;) > >If someone's already posted it here, I missed it -- and I apologize for the >repeat. > >Susan H. > > > -- Marty Connelly Victoria, B.C. Canada From ewaldt at gdls.com Thu Jul 26 14:34:51 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 26 Jul 2007 15:34:51 -0400 Subject: [AccessD] Importing from Excel In-Reply-To: Message-ID: I wrote the code below, which works really well and I'm very happy with it. This is code for Excel, though. What I need to do is the following: 1. Have the user find the Excel file (I can do this). 2. Have the code below apply to the Excel file (Don't know how to do this from within Access). 3. Have Access run the import process on the new worksheet (Not sure how to have it do that specific sheet; can it work on a workbook already in memory without saving the Excel file first?). 4. Do more processing of the data (I have this set up). So I really need help with #2 and maybe #3 above. Of course #2 is using the Excel object model, and that has to be taken into consideration. Any help? Thanks. Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems ---------------------------------------------------------- Sub PrepForImport() ' Created 7/26/2007 by ewaldt Dim intLastRow As Integer Dim intCount As Integer Dim intNewRow As Integer Dim oCell As Object Sheets.Add Sheets("Sheet1").Name = "ToImport" Sheets("ToImport").Select 'Copy only rows where column B = "A" intNewRow = 1 For Each oCell In Sheets("GDLS-SHC").Range("B:B") If oCell.Formula = "A" Then oCell.EntireRow.Copy ActiveSheet.Paste Destination:=Worksheets("ToImport").Range("A" & intNewRow) intNewRow = intNewRow + 1 End If Next oCell For Each oCell In Sheets("GDLS-C").Range("B:B") If oCell.Formula = "A" Then oCell.EntireRow.Copy ActiveSheet.Paste Destination:=Worksheets("ToImport").Range("A" & intNewRow) intNewRow = intNewRow + 1 End If Next oCell 'Check for non-numeric in Pounds and Grams For Each oCell In Sheets("ToImport").Range("C1:D" & intNewRow - 1) If Not IsNumeric(oCell.Formula) Then oCell.Formula = 0 End If Next oCell End Sub This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From mmattys at rochester.rr.com Thu Jul 26 14:53:20 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Thu, 26 Jul 2007 15:53:20 -0400 Subject: [AccessD] Importing from Excel References: Message-ID: <022b01c7cfbe$a0923220$0202a8c0@Laptop> It might be easiest to import the file to Access using DoCmd Dim xlApp As Excel.Application Dim xlWB As Excel.Workbook Dim xlWS As Excel.Worksheet Dim MyRange As Excel.Range Set xlApp = New Excel.Application Set xlWB = xlApp.Workbooks.Add("C:\MyTemplate.xlt") Set db = CurrentDb Set xlWS = xlWB.Sheets("ToImport") With xlWS .Select Set rs = db.OpenRecordset("tblFromFile") .Cells(1, 1).CopyFromRecordset rs End With Set xlWS = Nothing Set rs = Nothing Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: To: Sent: Thursday, July 26, 2007 3:34 PM Subject: Re: [AccessD] Importing from Excel >I wrote the code below, which works really well and I'm very happy with > it. This is code for Excel, though. What I need to do is the following: > > 1. Have the user find the Excel file (I can do this). > 2. Have the code below apply to the Excel file (Don't know how to do this > from within Access). > 3. Have Access run the import process on the new worksheet (Not sure how > to have it do that specific sheet; can it work on a workbook already in > memory without saving the Excel file first?). > 4. Do more processing of the data (I have this set up). > > So I really need help with #2 and maybe #3 above. Of course #2 is using > the Excel object model, and that has to be taken into consideration. > > Any help? Thanks. > > Thomas F. Ewald > Stryker Mass Properties > General Dynamics Land Systems > > ---------------------------------------------------------- > Sub PrepForImport() > > ' Created 7/26/2007 by ewaldt > > Dim intLastRow As Integer > Dim intCount As Integer > Dim intNewRow As Integer > Dim oCell As Object > > Sheets.Add > Sheets("Sheet1").Name = "ToImport" > Sheets("ToImport").Select > > 'Copy only rows where column B = "A" > intNewRow = 1 > > For Each oCell In Sheets("GDLS-SHC").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste > Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > > For Each oCell In Sheets("GDLS-C").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste > Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > > 'Check for non-numeric in Pounds and Grams > For Each oCell In Sheets("ToImport").Range("C1:D" & intNewRow - 1) > If Not IsNumeric(oCell.Formula) Then > oCell.Formula = 0 > End If > Next oCell > > End Sub > > > > This is an e-mail from General Dynamics Land Systems. It is for the > intended recipient only and may contain confidential and privileged > information. No one else may read, print, store, copy, forward or act in > reliance on it or its attachments. If you are not the intended recipient, > please return this message to the sender and delete the message and any > attachments from your computer. Your cooperation is appreciated. > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From markamatte at hotmail.com Thu Jul 26 15:18:14 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Thu, 26 Jul 2007 20:18:14 +0000 Subject: [AccessD] Importing from Excel In-Reply-To: Message-ID: I'm not sure exactly what you are asking...but #2 sounds like you want to do some formatting? If so...below is some code I use to format a spreadsheet (from within Access), that is actually created from an exported Access report. If I missed the point...sorry, let me know and I'll try again. Good Luck, Mark A. Matte P.S...the formatting is based on a recordset within the db. With appExcel .Workbooks.Open strpathTemp1, 0 '.Visible = True 'just to watch the sheet .ActiveSheet.Name = strReport .Range("A1:AC1").Select .Selection.Font.Bold = True .Selection.Font.Name = "Arial" .Selection.Font.Size = 12 Do Until MyRst.NoMatch Counter = Counter + 1 .Cells(1, Counter) = MyRst!Reas_cd If MyRst![View] = 0 Then .Cells(1, Counter).Font.Color = 255 MyRst.FindNext strSQL Loop .Columns.AutoFit .Rows.AutoFit .Columns.Borders.Color = vbBlack .ActiveWorkbook.Save End With appExcel.Quit >From: ewaldt at gdls.com >Reply-To: Access Developers discussion and problem >solving >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Importing from Excel >Date: Thu, 26 Jul 2007 15:34:51 -0400 > >I wrote the code below, which works really well and I'm very happy with >it. This is code for Excel, though. What I need to do is the following: > >1. Have the user find the Excel file (I can do this). >2. Have the code below apply to the Excel file (Don't know how to do this >from within Access). >3. Have Access run the import process on the new worksheet (Not sure how >to have it do that specific sheet; can it work on a workbook already in >memory without saving the Excel file first?). >4. Do more processing of the data (I have this set up). > >So I really need help with #2 and maybe #3 above. Of course #2 is using >the Excel object model, and that has to be taken into consideration. > >Any help? Thanks. > >Thomas F. Ewald >Stryker Mass Properties >General Dynamics Land Systems > >---------------------------------------------------------- >Sub PrepForImport() > >' Created 7/26/2007 by ewaldt > >Dim intLastRow As Integer >Dim intCount As Integer >Dim intNewRow As Integer >Dim oCell As Object > > Sheets.Add > Sheets("Sheet1").Name = "ToImport" > Sheets("ToImport").Select > >'Copy only rows where column B = "A" > intNewRow = 1 > > For Each oCell In Sheets("GDLS-SHC").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste >Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > > For Each oCell In Sheets("GDLS-C").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste >Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > >'Check for non-numeric in Pounds and Grams > For Each oCell In Sheets("ToImport").Range("C1:D" & intNewRow - 1) > If Not IsNumeric(oCell.Formula) Then > oCell.Formula = 0 > End If > Next oCell > >End Sub > > > >This is an e-mail from General Dynamics Land Systems. It is for the >intended recipient only and may contain confidential and privileged >information. No one else may read, print, store, copy, forward or act in >reliance on it or its attachments. If you are not the intended recipient, >please return this message to the sender and delete the message and any >attachments from your computer. Your cooperation is appreciated. > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01 From Jim.Hale at FleetPride.com Thu Jul 26 15:22:01 2007 From: Jim.Hale at FleetPride.com (Hale, Jim) Date: Thu, 26 Jul 2007 15:22:01 -0500 Subject: [AccessD] Importing from Excel In-Reply-To: References: Message-ID: Using offset you can "walk" a spreadsheet to create a record applying different tests to the cell as needed: Jim Hale Do While Not IsEmpty(ActiveCell) rstbase.AddNew 'create records in output table For x = 0 To 16 If x < 4 Then rstbase.Fields(x) = .ActiveCell.Offset(0, x) 'change sign on Jan-Dec revenue If x > 3 Then If rstbase.Fields("rptline") = 4100 Then rstbase.Fields(x) = -Round(.ActiveCell.Offset(0, x), 3) ElseIf rstbase.Fields("rptline") = 4110 Then rstbase.Fields(x) = -Round(.ActiveCell.Offset(0, x), 3) ElseIf rstbase.Fields("rptline") = 4120 Then rstbase.Fields(x) = -Round(.ActiveCell.Offset(0, x), 3) ElseIf rstbase.Fields("rptline") = 4130 Then rstbase.Fields(x) = -Round(.ActiveCell.Offset(0, x), 3) ElseIf rstbase.Fields("rptline") = 15000 Then rstbase.Fields(x) = Round(.ActiveCell.Offset(0, x), 3) Else rstbase.Fields(x) = Round(.ActiveCell.Offset(0, x), 3) End If End If Next x If Not rstbase.Fields("rptline") = 0 Then rstbase.Update *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email. From martyconnelly at shaw.ca Thu Jul 26 15:26:06 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 26 Jul 2007 13:26:06 -0700 Subject: [AccessD] Importing from Excel In-Reply-To: References: Message-ID: <46A9035E.6080405@shaw.ca> Couple of other ways avoiding full Excel Application startup You can also open an Excel Spreadsheet using the JET OLE DB Provider to read into a Access table, removing the header record oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _ "Data Source=c:\somepath\mySpreadsheet.xls;" & _ "Extended Properties=""Excel 8.0;HDR=Yes""" Where "HDR=Yes" means that there is a header row in the cell range (or named range), so the provider will not include the first row of the selection into the recordset. If "HDR=No", then the provider will include the first row of the cell range (or named ranged) into the recordset. Sample mbd here http://support.microsoft.com/default.aspx?scid=kb;en-us;278973 or here is some sample VBA code to link a csv text file or optionally a xls file from Access Public Function LinkExternalFileADO(ByVal strTextFileName As String, _ ByVal strLinkTable As String, _ ByVal strLinkSpecRange As String, _ Optional blnXL As Boolean) As Boolean 'Created by Charlotte Foust 'drops and relinks the temp table 'and returns a boolean value for 'the success of the operation 'last modified 7/5/2001 'Sample call: LinkTextFileADO("MyTable.tab","MyTable","MyTable Spec") ' LinkTextFileADO("MySheet.xls","MySheet","MyRange",True) On Error GoTo Proc_err Dim cat As ADOX.Catalog Dim cnn As ADODB.Connection Dim errsCnn As ADODB.Errors Dim errCurr As ADODB.Error 'initialize the return value LinkExternalFileADO = True 'initialize the object variables Set cnn = CurrentProject.Connection Set cat = New ADOX.Catalog cat.ActiveConnection = cnn Set errsCnn = cnn.Errors errsCnn.Clear 'if the file exists, try to link it If strLinkTable <> "" Then 'If no path was included, use the current path If InStr(strTextFileName, "\") = 0 Then strTextFileName = CurrentProject.Path & "\" & strTextFileName End If 'InStr(strTextFileName, "\") = 0 'if the file exists then ... If Dir(strTextFileName) <> "" Then On Error Resume Next 'delete the existing table link cat.Tables.Delete strLinkTable On Error GoTo Proc_err 'link either a text file or an Excel spreadsheet If Not blnXL Then 'create a new link to the text file DoCmd.TransferText acLinkDelim, strLinkSpecRange, _ strLinkTable, strTextFileName Else 'If Not blnXL 'create a new link to the Excel file DoCmd.TransferSpreadsheet acLink, acSpreadsheetTypeExcel9, _ strLinkTable, strTextFileName, True, strLinkSpecRange End If 'Not blnXL Else 'If Dir(strTextFileName) <> "" 'not a valid filename or path LinkExternalFileADO = False End If 'Dir(strTextFileName) <> "" End If Proc_exit: 'cleanup and exit On Error Resume Next Set cat = Nothing Set errsCnn = Nothing Set errCurr = Nothing Set cnn = Nothing Exit Function Proc_err: If errsCnn.Count > 0 Then For Each errCurr In errsCnn MsgBox "Error #" & errCurr.Number & "--" & errCurr.Description _ & vbCrLf & CurrentProject.Name & ".LinkTextFileADO" Next errCurr errsCnn.Clear End If If Err <> 0 Then MsgBox Err.Number & "--" & Err.Description & vbCr _ & " in LinkTextFileADO", vbOKOnly End If LinkExternalFileADO = False Resume Proc_exit End Function 'LinkExternalFileADO(ByVal strTextFileName As String, _ ByVal strLinkTable As String, _ ByVal strLinkSpecRange As String, _ Optional blnXL As Boolean) As Boolean ewaldt at gdls.com wrote: >I wrote the code below, which works really well and I'm very happy with >it. This is code for Excel, though. What I need to do is the following: > >1. Have the user find the Excel file (I can do this). >2. Have the code below apply to the Excel file (Don't know how to do this >from within Access). >3. Have Access run the import process on the new worksheet (Not sure how >to have it do that specific sheet; can it work on a workbook already in >memory without saving the Excel file first?). >4. Do more processing of the data (I have this set up). > >So I really need help with #2 and maybe #3 above. Of course #2 is using >the Excel object model, and that has to be taken into consideration. > >Any help? Thanks. > >Thomas F. Ewald >Stryker Mass Properties >General Dynamics Land Systems > >---------------------------------------------------------- >Sub PrepForImport() > >' Created 7/26/2007 by ewaldt > >Dim intLastRow As Integer >Dim intCount As Integer >Dim intNewRow As Integer >Dim oCell As Object > > Sheets.Add > Sheets("Sheet1").Name = "ToImport" > Sheets("ToImport").Select > >'Copy only rows where column B = "A" > intNewRow = 1 > > For Each oCell In Sheets("GDLS-SHC").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste >Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > > For Each oCell In Sheets("GDLS-C").Range("B:B") > If oCell.Formula = "A" Then > oCell.EntireRow.Copy > ActiveSheet.Paste >Destination:=Worksheets("ToImport").Range("A" & intNewRow) > intNewRow = intNewRow + 1 > End If > Next oCell > >'Check for non-numeric in Pounds and Grams > For Each oCell In Sheets("ToImport").Range("C1:D" & intNewRow - 1) > If Not IsNumeric(oCell.Formula) Then > oCell.Formula = 0 > End If > Next oCell > >End Sub > > > -- Marty Connelly Victoria, B.C. Canada From robert at webedb.com Thu Jul 26 15:38:53 2007 From: robert at webedb.com (Robert L. Stewart) Date: Thu, 26 Jul 2007 15:38:53 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <200707262040.l6QKeNDF018504@databaseadvisors.com> Sure... A fact table is, 99.9% of the time, something that is additive. In other words, math of some type will or has been done to it. For example sales of products by customer. The PK would be the sales date, customer key and product key. The dimensions would be the date dimension, customers, and products. A dimension table is totally denormalized. all the data math has already been done on the date in a date dimension table. The day, year, month, etc. are all separate columns. In the customer, all of the addresses, phones, email, etc are included. In the products, all of the vendor information would be included. No joins past the dimension itself. If there are, they are called snowflakes and they usually severely affect the performance of teh mart/warehouse. Robert At 03:18 PM 7/26/2007, you wrote: >Date: Thu, 26 Jul 2007 14:21:44 -0400 >From: "jwcolby" >Subject: Re: [AccessD] Primary Key Best Practices >To: "'Access Developers discussion and problem solving'" > >Message-ID: <20070726182158.B2C0CBCDD at smtp-auth.no-ip.com> >Content-Type: text/plain; charset="us-ascii" > >Robert, > >I know nothing about data warehouses. Would you define fact table and >explain why the PK is a natural key? I assume that it has to do with speed >but beyond that could you explain the concepts a little? > >I am just looking to learn something here about a subject I know nothing >about. > >John W. Colby >Colby Consulting >www.ColbyConsulting.com From martyconnelly at shaw.ca Thu Jul 26 15:51:25 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Thu, 26 Jul 2007 13:51:25 -0700 Subject: [AccessD] Data Warehouse (Was: Primary Key Best Practices) In-Reply-To: References: <200707261810.l6QIAQwq006122@databaseadvisors.com> Message-ID: <46A9094D.2080000@shaw.ca> Here is a quick overview, think cubes and hypercubes for storage not 2-D Tables http://en.wikipedia.org/wiki/OLAP_cube Yup Codd got into this too. Charlotte Foust wrote: > Can you give an example of a typical dimension table and what you mean >by the source primary table? I've worked primarily with date dimensions >using the date as the PK. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. >Stewart >Sent: Thursday, July 26, 2007 11:04 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Primary Key Best Practices > >I have watched all the flaming and was surprised at the lack of >intelligence and total stubborness in some of it. > >I do not know if what I do is best practice or not. But, I will go with >consistency. > >In a transactional database, all tables have a surrogate, autonumbering >primary key. They also have one or more unique indexes on the candidate >key or keys. Also, indexes on all foreign key columns. > >In a data warehouse or data mart, all dimension tables will have a >single column primary key inherited from the source primary table. >All fact tables will have multiple columns that make up the primary key. >There are no snowflakes. It is a true star schema. > >Best practice or not, as long as I am consistent in my designs, I will >always know how to use it properly. And, I can always explain it to the >monkeys that come after. > >Robert > > -- Marty Connelly Victoria, B.C. Canada From ewaldt at gdls.com Thu Jul 26 15:58:28 2007 From: ewaldt at gdls.com (ewaldt at gdls.com) Date: Thu, 26 Jul 2007 16:58:28 -0400 Subject: [AccessD] Importing from Excel In-Reply-To: Message-ID: Thanks, Mark (and others). That's close. What I want to know is how to apply Excel-oriented code to Excel from within Access. Is that what your code does? It looks like it does, since it references Excel objects like workbooks, cells, etc. I'll try putting my code into your context. Thanks, again. Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems Message: 17 Date: Thu, 26 Jul 2007 20:18:14 +0000 From: "Mark A Matte" Subject: Re: [AccessD] Importing from Excel To: accessd at databaseadvisors.com Message-ID: Content-Type: text/plain; format=flowed I'm not sure exactly what you are asking...but #2 sounds like you want to do some formatting? If so...below is some code I use to format a spreadsheet (from within Access), that is actually created from an exported Access report. If I missed the point...sorry, let me know and I'll try again. Good Luck, Mark A. Matte P.S...the formatting is based on a recordset within the db. [Code here] This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. From cfoust at infostatsystems.com Thu Jul 26 15:59:09 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Thu, 26 Jul 2007 13:59:09 -0700 Subject: [AccessD] Data Warehouse (Was: Primary Key Best Practices) In-Reply-To: <46A9094D.2080000@shaw.ca> References: <200707261810.l6QIAQwq006122@databaseadvisors.com> <46A9094D.2080000@shaw.ca> Message-ID: Yes, and I have several of Ralph Kimball's books on Data Warehouse design and I've built a few, but what I was looking for was an explanation of how a dimension table inherits a single column PK "from the source primary table." I assume it means that all the distinct values for that column that exist in the primary table have a matching PK in the dimension table, but it took me a while to sort it out to that, and I've *worked* with the things! Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly Sent: Thursday, July 26, 2007 1:51 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Data Warehouse (Was: Primary Key Best Practices) Here is a quick overview, think cubes and hypercubes for storage not 2-D Tables http://en.wikipedia.org/wiki/OLAP_cube Yup Codd got into this too. Charlotte Foust wrote: > Can you give an example of a typical dimension table and what you mean >by the source primary table? I've worked primarily with date >dimensions using the date as the PK. > >Charlotte Foust > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. >Stewart >Sent: Thursday, July 26, 2007 11:04 AM >To: accessd at databaseadvisors.com >Subject: Re: [AccessD] Primary Key Best Practices > >I have watched all the flaming and was surprised at the lack of >intelligence and total stubborness in some of it. > >I do not know if what I do is best practice or not. But, I will go with >consistency. > >In a transactional database, all tables have a surrogate, autonumbering >primary key. They also have one or more unique indexes on the candidate >key or keys. Also, indexes on all foreign key columns. > >In a data warehouse or data mart, all dimension tables will have a >single column primary key inherited from the source primary table. >All fact tables will have multiple columns that make up the primary key. >There are no snowflakes. It is a true star schema. > >Best practice or not, as long as I am consistent in my designs, I will >always know how to use it properly. And, I can always explain it to the >monkeys that come after. > >Robert > > -- Marty Connelly Victoria, B.C. Canada -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From anitatiedemann at gmail.com Thu Jul 26 21:26:51 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Fri, 27 Jul 2007 12:26:51 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00cd01c7cf78$11c31050$8abea8c0@XPS> <20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: Charlotte, You rock. On 7/27/07, Charlotte Foust wrote: > > Ah, yes, the classic AccessD method for conquering opposition: > willfully misinterpret the responses, deny them any validity, and > declare yourself the winner! Widely used by Colby and by Drew on > occasion. It amounts to "never mind if we're saying much the same > thing, you're WRONG!!" LOL > > Charlotte Foust > > From nd500_lo at charter.net Thu Jul 26 21:43:57 2007 From: nd500_lo at charter.net (Dian) Date: Thu, 26 Jul 2007 19:43:57 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: <00cd01c7cf78$11c31050$8abea8c0@XPS><20070726125801.16114BD11@smtp-auth.no-ip.com> Message-ID: <000001c7cff7$fb2a8cd0$6400a8c0@dsunit1> I'll drink to that... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 26, 2007 7:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Charlotte, You rock. On 7/27/07, Charlotte Foust wrote: > > Ah, yes, the classic AccessD method for conquering opposition: > willfully misinterpret the responses, deny them any validity, and > declare yourself the winner! Widely used by Colby and by Drew on > occasion. It amounts to "never mind if we're saying much the same > thing, you're WRONG!!" LOL > > Charlotte Foust > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From mmattys at rochester.rr.com Thu Jul 26 22:06:04 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Thu, 26 Jul 2007 23:06:04 -0400 Subject: [AccessD] Page Orientation 2003 References: <46A8C693.6040805@nanaimo.ark.com> Message-ID: <001001c7cffb$14595c10$0202a8c0@Laptop> Tony, What error are you getting? What happens when you set the printing prefs before opening Access? What size page are you using? Printer capabilities? Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: "Tony Septav" To: "Access Developers discussion and problem solving" Sent: Thursday, July 26, 2007 12:06 PM Subject: [AccessD] Page Orientation 2003 > Hey All > Finally made the move to Access2003. > I am in the process of converting an Access97 application to Access2003. > Code that I have used for years to change the page orientation on a > preview report in Access97 no longer seems to work. I have a little > freebie DELL printer that came with the machine. If I set the printer > default to Landscape then I cannot change it to Portrait when previewing > a report and vica versa. I have downloaded examples from Microsoft, I > can change the page size but not the orientation. Before I start moving > printers around I just thought I would ask, could this be a printer > specific problem I am running into here? > Thank you. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From jwcolby at colbyconsulting.com Thu Jul 26 22:19:21 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 26 Jul 2007 23:19:21 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <000001c7cff7$fb2a8cd0$6400a8c0@dsunit1> Message-ID: <20070727031936.09CF7BCE5@smtp-auth.no-ip.com> LOL. OK ok, I give in. Charlotte rocks, and is quite correct on all counts. I hereby swear to never again willfully misrepresent her responses. ;-) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian Sent: Thursday, July 26, 2007 10:44 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices I'll drink to that... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Thursday, July 26, 2007 7:27 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Charlotte, You rock. On 7/27/07, Charlotte Foust wrote: > > Ah, yes, the classic AccessD method for conquering opposition: > willfully misinterpret the responses, deny them any validity, and > declare yourself the winner! Widely used by Colby and by Drew on > occasion. It amounts to "never mind if we're saying much the same > thing, you're WRONG!!" LOL > > Charlotte Foust > > -- 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 anitatiedemann at gmail.com Fri Jul 27 00:09:19 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Fri, 27 Jul 2007 15:09:19 +1000 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070727031936.09CF7BCE5@smtp-auth.no-ip.com> References: <000001c7cff7$fb2a8cd0$6400a8c0@dsunit1> <20070727031936.09CF7BCE5@smtp-auth.no-ip.com> Message-ID: On a totally off-topic note - after all it is Friday. Congratulations on becoming a father John. I checked out your website. Your kids look adorable. Anita On 7/27/07, jwcolby wrote: > > LOL. > > OK ok, I give in. Charlotte rocks, and is quite correct on all counts. I > hereby swear to never again willfully misrepresent her responses. > > ;-) > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian > Sent: Thursday, July 26, 2007 10:44 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Primary Key Best Practices > > I'll drink to that... > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith > Sent: Thursday, July 26, 2007 7:27 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Primary Key Best Practices > > Charlotte, > You rock. > > > On 7/27/07, Charlotte Foust wrote: > > > > Ah, yes, the classic AccessD method for conquering opposition: > > willfully misinterpret the responses, deny them any validity, and > > declare yourself the winner! Widely used by Colby and by Drew on > > occasion. It amounts to "never mind if we're saying much the same > > thing, you're WRONG!!" LOL > > > > Charlotte Foust > > > > > -- > 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 jwcolby at colbyconsulting.com Fri Jul 27 00:30:12 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 27 Jul 2007 01:30:12 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <20070727053027.AF074BBF6@smtp-auth.no-ip.com> LOL. They don't look like that at all any more. Robbie is a skinny handsome little guy of 6 years old and Allie is now 4. I really should get some updated photos up there. And thanks, being their father is a gift like no other. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith Sent: Friday, July 27, 2007 1:09 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices On a totally off-topic note - after all it is Friday. Congratulations on becoming a father John. I checked out your website. Your kids look adorable. Anita On 7/27/07, jwcolby wrote: > > LOL. > > OK ok, I give in. Charlotte rocks, and is quite correct on all > counts. I hereby swear to never again willfully misrepresent her responses. > > ;-) > > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dian > Sent: Thursday, July 26, 2007 10:44 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Primary Key Best Practices > > I'll drink to that... > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Anita Smith > Sent: Thursday, July 26, 2007 7:27 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Primary Key Best Practices > > Charlotte, > You rock. > > > On 7/27/07, Charlotte Foust wrote: > > > > Ah, yes, the classic AccessD method for conquering opposition: > > willfully misinterpret the responses, deny them any validity, and > > declare yourself the winner! Widely used by Colby and by Drew on > > occasion. It amounts to "never mind if we're saying much the same > > thing, you're WRONG!!" LOL > > > > Charlotte Foust > > > > > -- > 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 shamil at users.mns.ru Fri Jul 27 03:28:33 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Fri, 27 Jul 2007 12:28:33 +0400 Subject: [AccessD] Urgent request for a quick tip: How to switch off "View or function is not updatable because the modification affects multiple base tables" Message-ID: <000001c7d028$1ecc8e60$6401a8c0@nant> Hi All, I have an issue with MS SQL 2005/Express here: I wanted to create a stored procedure definition for it, which uses insert against non updatable query. When I'm trying to create such a stored procedure I (obviously) get "View or function 'xxxx' is not updatable because the modification affects multiple base tables" MS SQL 2000 doesn't give me this message and quietly creates my stored procedure. I currently to not care that the stored procedure I wanted to create in MS SQL 2005/Express uses non-updatable query - IOW I just need to save my SP in MS SQL 2005 and proceed with the next tasks... I guess there should be a way to suppress the message mentioned above but I do not know currently how. Could you please give me some hints? (I'm looking in parallel in docs/google)... Of course I can just comment inserts/updates used in my SP against non-updatable queries but I do not want to go this (easy) way.... Thanks. -- Shamil From Gustav at cactus.dk Fri Jul 27 06:12:35 2007 From: Gustav at cactus.dk (Gustav Brock) Date: Fri, 27 Jul 2007 13:12:35 +0200 Subject: [AccessD] Importing from Excel Message-ID: Hi Thomas You can open Excel from Access and run a series of Excel "macros" (VBA functions in Excel). Look up an intro here: http://databaseadvisors.com/mailman/htdig/accessd/2003-March/002956.html /gustav >>> ewaldt at gdls.com 26-07-2007 22:58 >>> Thanks, Mark (and others). That's close. What I want to know is how to apply Excel-oriented code to Excel from within Access. Is that what your code does? It looks like it does, since it references Excel objects like workbooks, cells, etc. I'll try putting my code into your context. Thanks, again. Thomas F. Ewald Stryker Mass Properties General Dynamics Land Systems From iggy at nanaimo.ark.com Fri Jul 27 08:15:09 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Fri, 27 Jul 2007 06:15:09 -0700 Subject: [AccessD] Page Orientation 2003 Message-ID: <46A9EFDD.80004@nanaimo.ark.com> Hey Michael Thanks No error messages. I think it has to be a printer problem or I am missing a turn off/turn on setting in Access2003. If I set the printer (Dell Photo Printer 720) preferences, to letter 8 1/2 by 11, portrait. Then go into the design mode for a report (in Access98) that was set to letter and landscape, select page setup the orientaion is set to portrait and if I click landscape then exit (and don't do anything) and go back in, it is back to portrait and vice a versa if I set preferences to landscape and open a report that was set to portrait. I tried the code below for 2003, I downloaded from Microsoft, but it doesn't fire off the orientation setting still stays as portrait. Dim rpt As Access.Report Dim prtr As Access.Printer Set Application.Printer = Nothing Set prtr = Application.Printer 'Set the default printer's orientation to landscape prtr.Orientation = acPRORLandscape 'Set the default printer's paper size to legal prtr.PaperSize = acPRPSLegal 'Print Preview the Client Report DoCmd.OpenReport "client", acPreview Set rpt = Reports("client") 'Set the Printer property of the report to the 'Application.Printer object Set rpt.Printer = prtr 'Uncomment the following line if you wish to save the object 'with the current settings 'DoCmd.Save acReport, "Client" I hope I have not pulled off a "bonehead" manuever in my upgrading. Thanks Again From fuller.artful at gmail.com Fri Jul 27 08:46:10 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 27 Jul 2007 09:46:10 -0400 Subject: [AccessD] Page Orientation 2003 In-Reply-To: <46A9EFDD.80004@nanaimo.ark.com> References: <46A9EFDD.80004@nanaimo.ark.com> Message-ID: <29f585dd0707270646i59cf7032r4a8d874fe478ab05@mail.gmail.com> Isn't this the famous bug that concerns the setting of the AutoCorrect Spellcheck thing? On 7/27/07, Tony Septav wrote: > > Hey Michael > Thanks > No error messages. > I think it has to be a printer problem or > I am missing a turn off/turn on setting in Access2003. > > If I set the printer (Dell Photo Printer 720) preferences, to letter 8 > 1/2 by 11, portrait. > Then go into the design mode for a report (in Access98) that was set to > letter and landscape, select page setup the orientaion is set to > portrait and if I click landscape then exit (and don't do anything) and > go back in, it is back to portrait and vice a versa if I set > preferences to landscape and open a report that was set to portrait. > > I tried the code below for 2003, I downloaded from Microsoft, but it > doesn't fire off the orientation setting still stays as portrait. > > Dim rpt As Access.Report > Dim prtr As Access.Printer > > Set Application.Printer = Nothing > Set prtr = Application.Printer > > 'Set the default printer's orientation to landscape > prtr.Orientation = acPRORLandscape > > 'Set the default printer's paper size to legal > prtr.PaperSize = acPRPSLegal > > 'Print Preview the Client Report > DoCmd.OpenReport "client", acPreview > Set rpt = Reports("client") > > 'Set the Printer property of the report to the > 'Application.Printer object > Set rpt.Printer = prtr > > 'Uncomment the following line if you wish to save the object > 'with the current settings > 'DoCmd.Save acReport, "Client" > > I hope I have not pulled off a "bonehead" manuever in my upgrading. > > Thanks Again > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From iggy at nanaimo.ark.com Fri Jul 27 08:46:30 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Fri, 27 Jul 2007 06:46:30 -0700 Subject: [AccessD] Page Orientation Solved Message-ID: <46A9F736.9010206@nanaimo.ark.com> Hey All Looks like it is the printer. Tried creating new reports same problem. Then the "Duh light" came on switched the default printer to the Fax printer and set preferences to 8 1/2 by 11 and portrait. Was able to preview reports in landscape and portrait, changed paper sizes etc. Glad it was this simple, thought I was going to have to redo all the reports. Thanks. From cfoust at infostatsystems.com Fri Jul 27 10:01:22 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Fri, 27 Jul 2007 08:01:22 -0700 Subject: [AccessD] Page Orientation Solved In-Reply-To: <46A9F736.9010206@nanaimo.ark.com> References: <46A9F736.9010206@nanaimo.ark.com> Message-ID: It's a well-known issue that printer settings don't get saved appropriately when no specific printer is the selected. That's the reason we built code in our applications to set the page orientation and paper size when we formatted the report for print. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Tony Septav Sent: Friday, July 27, 2007 6:46 AM To: Access Developers discussion and problem solving Subject: [AccessD] Page Orientation Solved Hey All Looks like it is the printer. Tried creating new reports same problem. Then the "Duh light" came on switched the default printer to the Fax printer and set preferences to 8 1/2 by 11 and portrait. Was able to preview reports in landscape and portrait, changed paper sizes etc. Glad it was this simple, thought I was going to have to redo all the reports. Thanks. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From markamatte at hotmail.com Fri Jul 27 10:11:49 2007 From: markamatte at hotmail.com (Mark A Matte) Date: Fri, 27 Jul 2007 15:11:49 +0000 Subject: [AccessD] Page Orientation 2003 In-Reply-To: <46A9EFDD.80004@nanaimo.ark.com> Message-ID: Sounds like an issue we had here...except minus Access. Are you having the same problem printing from IE...or from word...if so...you might have the wrong drivers loaded fro the printer... Good Luck, Mark >From: Tony Septav >Reply-To: Access Developers discussion and problem >solving >To: Access Developers discussion and problem >solving >Subject: [AccessD] Page Orientation 2003 >Date: Fri, 27 Jul 2007 06:15:09 -0700 > >Hey Michael >Thanks >No error messages. >I think it has to be a printer problem or >I am missing a turn off/turn on setting in Access2003. > >If I set the printer (Dell Photo Printer 720) preferences, to letter 8 >1/2 by 11, portrait. >Then go into the design mode for a report (in Access98) that was set to >letter and landscape, select page setup the orientaion is set to >portrait and if I click landscape then exit (and don't do anything) and >go back in, it is back to portrait and vice a versa if I set >preferences to landscape and open a report that was set to portrait. > >I tried the code below for 2003, I downloaded from Microsoft, but it >doesn't fire off the orientation setting still stays as portrait. > > Dim rpt As Access.Report > Dim prtr As Access.Printer > > Set Application.Printer = Nothing > Set prtr = Application.Printer > > 'Set the default printer's orientation to landscape > prtr.Orientation = acPRORLandscape > > 'Set the default printer's paper size to legal > prtr.PaperSize = acPRPSLegal > > 'Print Preview the Client Report > DoCmd.OpenReport "client", acPreview > Set rpt = Reports("client") > > 'Set the Printer property of the report to the > 'Application.Printer object > Set rpt.Printer = prtr > > 'Uncomment the following line if you wish to save the object > 'with the current settings > 'DoCmd.Save acReport, "Client" > >I hope I have not pulled off a "bonehead" manuever in my upgrading. > >Thanks Again > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com _________________________________________________________________ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01 From rockysmolin at bchacc.com Fri Jul 27 10:39:21 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 27 Jul 2007 08:39:21 -0700 Subject: [AccessD] Turning off A2007 Menus Message-ID: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> I am developing an app for a client in A2003 but he is using A2007. And (it's a legacy app) there are custom menus. Even when he turns off the toolbars, the menu is like an inch high. Take up a lot of real estate. Is there a way to reduce the vertical height of this menu? Or turn it off - he's OK with losing the custom menus because you can get to all the functions in the app through command buttons anyway. MTIA Rocky From iggy at nanaimo.ark.com Fri Jul 27 11:56:15 2007 From: iggy at nanaimo.ark.com (Tony Septav) Date: Fri, 27 Jul 2007 09:56:15 -0700 Subject: [AccessD] Page Orientation 2003 Message-ID: <46AA23AF.304@nanaimo.ark.com> Thanks All Wasn't satisified with using the FAX printer so I re-installed the Dell printer and put back in my old Access97 printer setup code, and I am back up and running. I know I know, "Well why didn't you think of doing that in the first place you dummy?, stop wasting bandwidth!". Guess I can blame it on getting old and panicking to meet a Monday deadline. From robert at webedb.com Fri Jul 27 13:12:42 2007 From: robert at webedb.com (Robert L. Stewart) Date: Fri, 27 Jul 2007 13:12:42 -0500 Subject: [AccessD] Data Warehouse In-Reply-To: References: Message-ID: <200707271816.l6RIGOLF009816@databaseadvisors.com> Charlotte, In the case of a customer dimension, it would be the customer primary key from the customer table in the source. The problem comes from having multiple sources. Then you have to use a surrogate key and store the source primary key in a column along with the source name. Sorry, I have been doing it for so long, it is second nature. So, I do not really think about it. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Thu, 26 Jul 2007 13:59:09 -0700 >From: "Charlotte Foust" >Subject: Re: [AccessD] Data Warehouse (Was: Primary Key Best > Practices) >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >Yes, and I have several of Ralph Kimball's books on Data Warehouse >design and I've built a few, but what I was looking for was an >explanation of how a dimension table inherits a single column PK "from >the source primary table." I assume it means that all the distinct >values for that column that exist in the primary table have a matching >PK in the dimension table, but it took me a while to sort it out to >that, and I've *worked* with the things! > >Charlotte Foust From robert at webedb.com Fri Jul 27 13:18:53 2007 From: robert at webedb.com (Robert L. Stewart) Date: Fri, 27 Jul 2007 13:18:53 -0500 Subject: [AccessD] Primary Key Best Practices In-Reply-To: References: Message-ID: <200707271821.l6RILNHP010961@databaseadvisors.com> Continuing off topic... My youngest son called me last night and told me that I am going to to be a grandfather. I called my fiance and told her that she was going to be a grandmother. It was the first time I have heard her speechless. She said she was too young to be a grandmother. :-) She will finally be here after all the waiting and government bull on August 14 from Yoshkar-Ola, Russia. She has a 7 year old daughter. My first. I have 3 sons 27, 22, and 22 from my first marriage. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 15:09:19 +1000 >From: "Anita Smith" >Subject: Re: [AccessD] Primary Key Best Practices >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >On a totally off-topic note - after all it is Friday. >Congratulations on becoming a father John. I checked out your website. Your >kids look adorable. From robert at webedb.com Fri Jul 27 13:21:08 2007 From: robert at webedb.com (Robert L. Stewart) Date: Fri, 27 Jul 2007 13:21:08 -0500 Subject: [AccessD] Urgent request for a quick tip In-Reply-To: References: Message-ID: <200707271823.l6RINTTx011667@databaseadvisors.com> Sorry Shamil, but commenting it out is the best you can do. They fixed the bug that allowed you to do it in 2000. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 12:28:33 +0400 >From: "Shamil Salakhetdinov" >Subject: [AccessD] Urgent request for a quick tip: How to switch off > "View or function is not updatable because the modification affects > multiple base tables" >To: "'Access-D'" >Message-ID: <000001c7d028$1ecc8e60$6401a8c0 at nant> >Content-Type: text/plain; charset="iso-8859-1" > >Hi All, > >I have an issue with MS SQL 2005/Express here: I wanted to create a stored >procedure definition for it, which uses insert against non updatable query. >When I'm trying to create such a stored procedure I (obviously) get > >"View or function 'xxxx' is not updatable because the modification affects >multiple base tables" > >MS SQL 2000 doesn't give me this message and quietly creates my stored >procedure. > >I currently to not care that the stored procedure I wanted to create in MS >SQL 2005/Express uses non-updatable query - IOW I just need to save my SP in >MS SQL 2005 and proceed with the next tasks... > >I guess there should be a way to suppress the message mentioned above but I >do not know currently how. > >Could you please give me some hints? (I'm looking in parallel in >docs/google)... > >Of course I can just comment inserts/updates used in my SP against >non-updatable queries but I do not want to go this (easy) way.... > >Thanks. > >-- >Shamil From jwcolby at colbyconsulting.com Fri Jul 27 13:40:04 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 27 Jul 2007 14:40:04 -0400 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707271821.l6RILNHP010961@databaseadvisors.com> Message-ID: <20070727184005.371B7BD3D@smtp-auth.no-ip.com> Congrats on the grandchild and congrats on you fianc?e finally getting here. Write us when she finally gets through immigration and it is all over. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Friday, July 27, 2007 2:19 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Continuing off topic... My youngest son called me last night and told me that I am going to to be a grandfather. I called my fiance and told her that she was going to be a grandmother. It was the first time I have heard her speechless. She said she was too young to be a grandmother. :-) She will finally be here after all the waiting and government bull on August 14 from Yoshkar-Ola, Russia. She has a 7 year old daughter. My first. I have 3 sons 27, 22, and 22 from my first marriage. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 15:09:19 +1000 >From: "Anita Smith" >Subject: Re: [AccessD] Primary Key Best Practices >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >On a totally off-topic note - after all it is Friday. >Congratulations on becoming a father John. I checked out your website. >Your kids look adorable. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From martyconnelly at shaw.ca Fri Jul 27 13:47:39 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Fri, 27 Jul 2007 11:47:39 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> Message-ID: <46AA3DCB.5000501@shaw.ca> If the "ribbon" takes up too much room, it's easy to hide. Just right-click on one of the ribbon tabs and choose: "Minimize the Ribbon." If you want quick access to a button found on one of the ribbons, just right-click on the button and choose: "Add to Quick Access Toolbar." Alternatively, you can get a list of all options and customize the "Quick Access Toolbar." You can easily add dozens of buttons to the toolbar. Rocky Smolin at Beach Access Software wrote: >I am developing an app for a client in A2003 but he is using A2007. And >(it's a legacy app) there are custom menus. Even when he turns off the >toolbars, the menu is like an inch high. Take up a lot of real estate. Is >there a way to reduce the vertical height of this menu? Or turn it off - >he's OK with losing the custom menus because you can get to all the >functions in the app through command buttons anyway. > >MTIA > >Rocky > > > > > > > > -- Marty Connelly Victoria, B.C. Canada From rockysmolin at bchacc.com Fri Jul 27 13:55:17 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 27 Jul 2007 11:55:17 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <20070727184005.371B7BD3D@smtp-auth.no-ip.com> Message-ID: <009501c7d07f$ac8c5350$0301a8c0@HAL9005> Pictures! WE WANT PICTURES!!! Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 27, 2007 11:40 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Congrats on the grandchild and congrats on you fianc?e finally getting here. Write us when she finally gets through immigration and it is all over. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Friday, July 27, 2007 2:19 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Continuing off topic... My youngest son called me last night and told me that I am going to to be a grandfather. I called my fiance and told her that she was going to be a grandmother. It was the first time I have heard her speechless. She said she was too young to be a grandmother. :-) She will finally be here after all the waiting and government bull on August 14 from Yoshkar-Ola, Russia. She has a 7 year old daughter. My first. I have 3 sons 27, 22, and 22 from my first marriage. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 15:09:19 +1000 >From: "Anita Smith" >Subject: Re: [AccessD] Primary Key Best Practices >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >On a totally off-topic note - after all it is Friday. >Congratulations on becoming a father John. I checked out your website. >Your kids look adorable. -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/921 - Release Date: 7/26/2007 11:16 PM From rockysmolin at bchacc.com Fri Jul 27 14:09:38 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 27 Jul 2007 12:09:38 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA3DCB.5000501@shaw.ca> Message-ID: <009a01c7d081$adc33ac0$0301a8c0@HAL9005> Thanks. Will forward. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly Sent: Friday, July 27, 2007 11:48 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Turning off A2007 Menus If the "ribbon" takes up too much room, it's easy to hide. Just right-click on one of the ribbon tabs and choose: "Minimize the Ribbon." If you want quick access to a button found on one of the ribbons, just right-click on the button and choose: "Add to Quick Access Toolbar." Alternatively, you can get a list of all options and customize the "Quick Access Toolbar." You can easily add dozens of buttons to the toolbar. Rocky Smolin at Beach Access Software wrote: >I am developing an app for a client in A2003 but he is using A2007. >And (it's a legacy app) there are custom menus. Even when he turns off >the toolbars, the menu is like an inch high. Take up a lot of real >estate. Is there a way to reduce the vertical height of this menu? Or >turn it off - he's OK with losing the custom menus because you can get >to all the functions in the app through command buttons anyway. > >MTIA > >Rocky > > > > > > > > -- Marty Connelly Victoria, B.C. Canada -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/921 - Release Date: 7/26/2007 11:16 PM From fuller.artful at gmail.com Fri Jul 27 14:40:15 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 27 Jul 2007 15:40:15 -0400 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA3DCB.5000501@shaw.ca> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> <46AA3DCB.5000501@shaw.ca> Message-ID: <29f585dd0707271240w6d43fbet80ef9043e7b434d4@mail.gmail.com> You may just have persuaded me to re-install Access 2007. On 7/27/07, MartyConnelly wrote: > > If the "ribbon" takes up too much room, it's easy to hide. > Just right-click on one of the ribbon tabs and choose: > "Minimize the Ribbon." If you want quick access to a button > found on one of the ribbons, just right-click on the button > and choose: "Add to Quick Access Toolbar." Alternatively, > you can get a list of all options and customize the "Quick > Access Toolbar." You can easily add dozens of buttons to the > toolbar. > From mwp.reid at qub.ac.uk Fri Jul 27 14:53:25 2007 From: mwp.reid at qub.ac.uk (Martin W Reid) Date: Fri, 27 Jul 2007 20:53:25 +0100 Subject: [AccessD] Ribbon X Message-ID: Friend of mine has developed a developer add in. See http://pschmid.net/blog/2006/10/09/58 Its not free. Martin Martin Reid Telephone: 02890974465 ________________________________________ From: accessd-bounces at databaseadvisors.com [accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software [rockysmolin at bchacc.com] Sent: 27 July 2007 20:09 To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Turning off A2007 Menus Thanks. Will forward. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly Sent: Friday, July 27, 2007 11:48 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Turning off A2007 Menus If the "ribbon" takes up too much room, it's easy to hide. Just right-click on one of the ribbon tabs and choose: "Minimize the Ribbon." If you want quick access to a button found on one of the ribbons, just right-click on the button and choose: "Add to Quick Access Toolbar." Alternatively, you can get a list of all options and customize the "Quick Access Toolbar." You can easily add dozens of buttons to the toolbar. Rocky Smolin at Beach Access Software wrote: >I am developing an app for a client in A2003 but he is using A2007. >And (it's a legacy app) there are custom menus. Even when he turns off >the toolbars, the menu is like an inch high. Take up a lot of real >estate. Is there a way to reduce the vertical height of this menu? Or >turn it off - he's OK with losing the custom menus because you can get >to all the functions in the app through command buttons anyway. > >MTIA > >Rocky > > > > > > > > -- Marty Connelly Victoria, B.C. Canada -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/921 - Release Date: 7/26/2007 11:16 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Fri Jul 27 15:27:55 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 28 Jul 2007 08:27:55 +1200 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> Message-ID: <46AA554B.6020908@mvps.org> Rocky, It is very easy to hide the Ribbon and use your custom menus in Access 2007. Some instructions about this here: http://blog.datamanagementsolutions.biz/2007/07/custom-toolbars-2007.html Regards Steve Rocky Smolin at Beach Access Software wrote: > I am developing an app for a client in A2003 but he is using A2007. And > (it's a legacy app) there are custom menus. Even when he turns off the > toolbars, the menu is like an inch high. Take up a lot of real estate. Is > there a way to reduce the vertical height of this menu? Or turn it off - > he's OK with losing the custom menus because you can get to all the > functions in the app through command buttons anyway. From miscellany at mvps.org Fri Jul 27 16:03:45 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 28 Jul 2007 09:03:45 +1200 Subject: [AccessD] Creating HTML file Message-ID: <46AA5DB1.1010000@mvps.org> Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve From ebarro at verizon.net Fri Jul 27 16:17:18 2007 From: ebarro at verizon.net (Eric Barro) Date: Fri, 27 Jul 2007 14:17:18 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> Message-ID: <0JLU00BORWHWHFH5@vms044.mailsrvcs.net> Steve, Grab any HTML editor that generates HTML (preferably drag and drop) and design your page and save it as an HTML file. And then you can open it with Notepad and use the generated HTML source code. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Fri Jul 27 16:20:31 2007 From: john at winhaven.net (John Bartow) Date: Fri, 27 Jul 2007 16:20:31 -0500 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> References: <46AA5DB1.1010000@mvps.org> Message-ID: <055b01c7d093$f76b4200$6402a8c0@ScuzzPaq> I've tried without success. So essentially I'm replying to add full to the fire. I still want to do this. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From john at winhaven.net Fri Jul 27 16:40:44 2007 From: john at winhaven.net (John Bartow) Date: Fri, 27 Jul 2007 16:40:44 -0500 Subject: [AccessD] HTML from Access Report (was mistakenly stolen from: Creating HTML file) In-Reply-To: <0JLU00BORWHWHFH5@vms044.mailsrvcs.net> References: <46AA5DB1.1010000@mvps.org> <0JLU00BORWHWHFH5@vms044.mailsrvcs.net> Message-ID: <056501c7d096$ca011990$6402a8c0@ScuzzPaq> Hi Eric, I guess I'm not after quite the same thing as Steve (so sorry I chimed in on your thread Steve, I'll rename mine). I had tried something of this sort with A97 and it didn't work. Now obviously things have changed a lot since then but could you please elaborate a bit on this. What I wish to do is to run a process that creates static html pages from data stored in the database and places them into a folder (which is used by FrontPage). There two approaches I have considered: Write out a text file and use FP VBA to manipulate it into using the default css theme. Or (since I know the css tags) embed the tags directly into the data output from Access. (I would prefer this as I have no desire to learn FP's object model, as it is a dead horse now). I was thinking (hoping, really) that I could do this with a report and use labels (or eventually a lookup table and text fields) to embed the html/css code. I would then output these reports to the folder of choice using the windows generic text only printer. Any thoughts on this? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Friday, July 27, 2007 4:17 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Creating HTML file Steve, Grab any HTML editor that generates HTML (preferably drag and drop) and design your page and save it as an HTML file. And then you can open it with Notepad and use the generated HTML source code. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. 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 rockysmolin at bchacc.com Fri Jul 27 16:43:22 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Fri, 27 Jul 2007 14:43:22 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA554B.6020908@mvps.org> Message-ID: <00c201c7d097$27aae9e0$0301a8c0@HAL9005> Thanks Steve. I'll forward to the client. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 1:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Turning off A2007 Menus Rocky, It is very easy to hide the Ribbon and use your custom menus in Access 2007. Some instructions about this here: http://blog.datamanagementsolutions.biz/2007/07/custom-toolbars-2007.html Regards Steve Rocky Smolin at Beach Access Software wrote: > I am developing an app for a client in A2003 but he is using A2007. > And (it's a legacy app) there are custom menus. Even when he turns > off the toolbars, the menu is like an inch high. Take up a lot of > real estate. Is there a way to reduce the vertical height of this > menu? Or turn it off - he's OK with losing the custom menus because > you can get to all the functions in the app through command buttons anyway. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/921 - Release Date: 7/26/2007 11:16 PM From krosenstiel at comcast.net Fri Jul 27 16:45:42 2007 From: krosenstiel at comcast.net (Karen Rosenstiel) Date: Fri, 27 Jul 2007 14:45:42 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> Message-ID: <200707272145.l6RLjYgq003194@databaseadvisors.com> I've done lots of work in (X)HTML, but never in this way. Why can't you design a template that can then be filled by a database? (AKA ASP or PHP) You need a lot of header information to make a good web page and a touch of JavaScript to add some class. Regards, Karen Rosenstiel Seattle WA USA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From martyconnelly at shaw.ca Fri Jul 27 17:11:04 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Fri, 27 Jul 2007 15:11:04 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA554B.6020908@mvps.org> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> <46AA554B.6020908@mvps.org> Message-ID: <46AA6D78.2040609@shaw.ca> This method applies to the particular database opened as opposed to method for Access platform overall that I stated. So choose your poison. There must be a way to do in VBA code. Steve Schapel wrote: >Rocky, > >It is very easy to hide the Ribbon and use your custom menus in Access >2007. Some instructions about this here: >http://blog.datamanagementsolutions.biz/2007/07/custom-toolbars-2007.html > >Regards >Steve > > >Rocky Smolin at Beach Access Software wrote: > > >>I am developing an app for a client in A2003 but he is using A2007. And >>(it's a legacy app) there are custom menus. Even when he turns off the >>toolbars, the menu is like an inch high. Take up a lot of real estate. Is >>there a way to reduce the vertical height of this menu? Or turn it off - >>he's OK with losing the custom menus because you can get to all the >>functions in the app through command buttons anyway. >> >> -- Marty Connelly Victoria, B.C. Canada From nd500_lo at charter.net Fri Jul 27 17:19:51 2007 From: nd500_lo at charter.net (Dian) Date: Fri, 27 Jul 2007 15:19:51 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: <200707271821.l6RILNHP010961@databaseadvisors.com> References: <200707271821.l6RILNHP010961@databaseadvisors.com> Message-ID: <000301c7d09c$407a7030$6400a8c0@dsunit1> Congratulations on all of the exciting new experiences on your horizon! -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Friday, July 27, 2007 11:19 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Primary Key Best Practices Continuing off topic... My youngest son called me last night and told me that I am going to to be a grandfather. I called my fiance and told her that she was going to be a grandmother. It was the first time I have heard her speechless. She said she was too young to be a grandmother. :-) She will finally be here after all the waiting and government bull on August 14 from Yoshkar-Ola, Russia. She has a 7 year old daughter. My first. I have 3 sons 27, 22, and 22 from my first marriage. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Fri, 27 Jul 2007 15:09:19 +1000 >From: "Anita Smith" >Subject: Re: [AccessD] Primary Key Best Practices >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >On a totally off-topic note - after all it is Friday. >Congratulations on becoming a father John. I checked out your website. >Your kids look adorable. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From ebarro at verizon.net Fri Jul 27 17:48:47 2007 From: ebarro at verizon.net (Eric Barro) Date: Fri, 27 Jul 2007 15:48:47 -0700 Subject: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) In-Reply-To: <056501c7d096$ca011990$6402a8c0@ScuzzPaq> Message-ID: <0JLV00MHY0QGZ6AE@vms040.mailsrvcs.net> John/Steve, Here's the code I used a while back when I was still developing in Access 97. If I was doing this today I'd probably re-write the code and make it more modular and use cascading style sheets for formatting. The basic format for any HTML file is... Page Title I would not hard-code any javascript or css but instead link to them at runtime as I've shown above in the section. Pay special attention to the construct """. In most cases you can use "'" instead. ---------------------------------------------------------------------------- ------------------------ Private Sub CreateHTMLFile(strHTMLFileName As String, strImage1 As String, strImage2 As String, strDesc1 As String, strDesc2 As String, strInsured As String, strPolicy As String) Open strHTMLFileName For Output As #1 Print #1, "" Print #1, "" Print #1, "" Print #1, "Photo Template" Print #1, "" Print #1, "" Print #1, "" Print #1, "
" Print #1, "
" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "
" Print #1, "
" & strInsured & "
" Print #1, "
" Print #1, "
" Print #1, "
" & strPolicy & "
" Print #1, "
" Print #1, "
" Print #1, "
" Print #1, "
" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" 'Print #1, "" ' Print #1, "" ' Print #1, "" ' Print #1, "" 'Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "
  
 " & strDesc1 & " 
   
  
 " & strDesc2 & " 
" Print #1, "
" Print #1, "" Print #1, "" Close #1 End Sub ---------------------------------------------------------------------------- ------------------------ Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Friday, July 27, 2007 2:41 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) Hi Eric, I guess I'm not after quite the same thing as Steve (so sorry I chimed in on your thread Steve, I'll rename mine). I had tried something of this sort with A97 and it didn't work. Now obviously things have changed a lot since then but could you please elaborate a bit on this. What I wish to do is to run a process that creates static html pages from data stored in the database and places them into a folder (which is used by FrontPage). There two approaches I have considered: Write out a text file and use FP VBA to manipulate it into using the default css theme. Or (since I know the css tags) embed the tags directly into the data output from Access. (I would prefer this as I have no desire to learn FP's object model, as it is a dead horse now). I was thinking (hoping, really) that I could do this with a report and use labels (or eventually a lookup table and text fields) to embed the html/css code. I would then output these reports to the folder of choice using the windows generic text only printer. Any thoughts on this? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Friday, July 27, 2007 4:17 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Creating HTML file Steve, Grab any HTML editor that generates HTML (preferably drag and drop) and design your page and save it as an HTML file. And then you can open it with Notepad and use the generated HTML source code. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/922 - Release Date: 7/27/2007 6:08 AM From martyconnelly at shaw.ca Fri Jul 27 18:02:35 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Fri, 27 Jul 2007 16:02:35 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> References: <46AA5DB1.1010000@mvps.org> Message-ID: <46AA798B.1060706@shaw.ca> Here is how I write out an HTML file with contained javascript (so ignore it ) To put a basic table into HTML http://www.w3schools.com/html/html_tables.asp You may be able to do easier via Bind Data Island to HTML Elements. http://www.w3schools.com/xml/tryit.asp?filename=cd_catalog_island_thead Function createhtmlroute(strStreetAddressFrom As String, strStreetAddressTo As String, lVersion As Long) As String Dim strHTML As String strHTML = "" strHTML = strHTML & "Route Microsoft To Area 51 Virtual Earth Map" ' strHTML = strHTML & "" 'When your page has referenced the map control, set up the call to display a default map by completing a LoadMap ( ) method call: 'try newer Virtual Earth control 4.0 Beta If lVersion Then strHTML = strHTML & vbCrLf & " " Else strHTML = strHTML & vbCrLf & " " End If ' strHTML = strHTML & vbCrLf & "" strHTML = strHTML & vbCrLf & "" 'Last, you display the map: strHTML = strHTML & vbCrLf & "" strHTML = strHTML & vbCrLf & "
" strHTML = strHTML & vbCrLf & " Delay for Route Info: mouseover way stations " strHTML = strHTML & vbCrLf & "" strHTML = strHTML & vbCrLf & "" WriteFile CurrentDBDir & "route.html", strHTML createhtmlroute = strHTML End Function Sub WriteFile(ByVal sFileName As String, ByVal sContents As String) ' Dump XML or html String to File for debugging Dim fhFile As Integer fhFile = FreeFile ' Debug.Print "Length of string=" & Len(sContents) Open sFileName For Output As #fhFile Print #fhFile, sContents; Close #fhFile Debug.Print "Out File" & sFileName End Sub Steve Schapel wrote: >Hi. I am just about to do something I have never tried before. I need >to create a static web page from Access data. Using OutputTo from a >report has too many problems. Using DoCmd.TransferText acExportHTML >doesn't give me the formatting flexibility that I need. Therefore I've >decided to try to loop through a recordset and build the html file in >code. Main problem being that my html skills are minimal. Has anyone >done this type of thing? Any tips? Thanks. > >Regards >Steve > > -- Marty Connelly Victoria, B.C. Canada From dw-murphy at cox.net Fri Jul 27 18:27:21 2007 From: dw-murphy at cox.net (Doug Murphy) Date: Fri, 27 Jul 2007 16:27:21 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> Message-ID: <002b01c7d0a5$ae586b80$0200a8c0@murphy3234aaf1> Hi Steve, I do this quite a bit. What I do is to create the skeleton of the html page in my html editor, Dream Weaver. I embed tags in the page where I want Access to insert specific current data, like the date the page was updated. The tag I use looks like an html comment, i.e., "" The text part of the tag allows me to insert in that spot. I then use this file as a template. When I want to create a page I open the template file from Access and open a new file to output to. The routine then iterates trough the template file, inserting data where required and then outputting the lines to the output file. For this application the majority of the data goes into a table so I put a tag where the table goes and input data from a record set into the table with the appropriate table, table row and cell tags. I got the basic routine from some one on this list several years ago. The routine I use follows. ---Code follows--- Sub sWriteHTMLReport(strTemplateFile As String, strFinalReportFile As String, rst As DAO.Recordset) Dim intFFIn As Integer Dim intFFOut As Integer Dim strLine As String Dim iCount As Integer Dim sField As String 'Get Free File Handle for working with template.html intFFIn = FreeFile 'Open temp.htm for read only using Free File handle Open strTemplateFile For Input Access Read As #intFFIn 'Get Free File Handle for working with report.html ' report.html is the output file intFFOut = FreeFile 'Open report.html for writing Open strFinalReportFile For Output Access Write As #intFFOut 'Do 'Insert update date Do ' Read Line from template.html Input #intFFIn, strLine ' If Line = then date goes here If strLine = "" Then ' Exit Loop strLine = "(Last Updated: " & Format(Date, "mmmm dd, yyyy") & ")" ' If Line = " Then ' Exit Loop Exit Do ' End If End If ' Write Line to report.html Print #intFFOut, strLine 'Loop While Not EOF ' just to make sure that you don't get errors if you Loop While Not (EOF(intFFIn)) 'forget to add the comment 'open Data recordset 'Recordset passed instead of opening her to make it a bit more generic 'Do Do ' Build OutPutString by iterating through the field collection and adding fields to the string strLine = "" For iCount = 0 To rst.Fields.Count - 1 'Check to see if the field is null and if so put in a Line break If IsNull(rst.Fields(iCount).Value) Then sField = "
" Else sField = rst.Fields(iCount).Value End If strLine = strLine & "" & sField & "" Next iCount 'Trim off the last strLine = Mid(strLine, 1, Len(strLine) - 5) 'Add the end of row tag strLine = strLine & "" ' write output string to report.html Print #intFFOut, strLine ' Move to Next Record rst.MoveNext 'loop while there are still records in the recordset Loop While Not (rst.EOF) 'do while not End Of template.html (the condition needs to go at the top in case you forgot to add the comment) Do While Not (EOF(intFFIn)) ' Read Line from template.html Input #intFFIn, strLine ' Write Line to report.html Print #intFFOut, strLine 'Loop Loop ' 'Close Report.html 'Close template.html Close End Sub ----End code---------- If you just want to insert a few pieces of data in specific locations you could just copy the template file into a string and use replace to locate the tags and insert the values. After inserting all data you would save the string to a new file. Hope this helps. I don't remember who helped me out, but am glad to share. Doug -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From miscellany at mvps.org Fri Jul 27 19:41:28 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 28 Jul 2007 12:41:28 +1200 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <46AA6D78.2040609@shaw.ca> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> <46AA554B.6020908@mvps.org> <46AA6D78.2040609@shaw.ca> Message-ID: <46AA90B8.4070106@mvps.org> That's right, Marty. I was just relating to the specific case of wanting to use custom menus within a specific application running in Access 2007. Regards Steve MartyConnelly wrote: > This method applies to the particular database opened as opposed to method > for Access platform overall that I stated. So choose your poison. > There must be a way to do in VBA code. From miscellany at mvps.org Sat Jul 28 04:01:57 2007 From: miscellany at mvps.org (Steve Schapel) Date: Sat, 28 Jul 2007 21:01:57 +1200 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> References: <46AA5DB1.1010000@mvps.org> Message-ID: <46AB0605.8060706@mvps.org> My sincere thanks to everyone who contributed to this thread. I pieced together a lot of the information you gave, plus a bit of "trial and error", and I am happy to say that I have now achieved what I wanted. Regards Steve From DWUTKA at Marlow.com Sat Jul 28 19:55:25 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Sat, 28 Jul 2007 19:55:25 -0500 Subject: [AccessD] Creating HTML file In-Reply-To: <46AA5DB1.1010000@mvps.org> Message-ID: I know I'm late to the party on this, but why must it be a static web page. Making dynamic pages with asp is a snap. Create the HTML in any editor you want. Then save it as an ASP page. <% Dim cnn Dim rs Dim strSQL Set cnn=server.createobject("ADODB.Connection") Set rs=server.createobject("ADODB.Connecion") strSQL="Your SQL string to get the data... 'Then connect the cnn, and open the recordset %> You now have a recordset open in asp. To use this, you can just put asp in the middle of the HTML. For example, if you have:

The current value is 1

And you want to make that 1 a value from your recordset:

The current value is <%=rs.fields("NumericValue").value%>

Whalla. You can also do conditional formatting: <% if rs.fields("SomeField").value="SomeValue"%>

Some paragraph in the HTML document

<%else%>

Some other paragraph

<%end if%> You can also loop this way, for example, if you want a table with your data: <%Do until rs.EOF=True%> <%For i=0 to 4 'just assuming 5 fields%> <%next%> <%rs.movenext%> <%loop%>
<%=rs.fields(i).Value%>
You mentioned Frontpage, one of the handy things about Front page is that if you select something in the 'design view', when you switch to the HTML view, the HTML of the selected area will be highlighted too. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From ebarro at verizon.net Sat Jul 28 20:30:02 2007 From: ebarro at verizon.net (Eric Barro) Date: Sat, 28 Jul 2007 18:30:02 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: Message-ID: <0JLX00K962U4VBB5@vms044.mailsrvcs.net> Probably because an ASP page needs a web server in order to process and display the pages whereas a straight HTML page can be displayed directly by the browser without a need for a web server. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Saturday, July 28, 2007 5:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Creating HTML file I know I'm late to the party on this, but why must it be a static web page. Making dynamic pages with asp is a snap. Create the HTML in any editor you want. Then save it as an ASP page. <% Dim cnn Dim rs Dim strSQL Set cnn=server.createobject("ADODB.Connection") Set rs=server.createobject("ADODB.Connecion") strSQL="Your SQL string to get the data... 'Then connect the cnn, and open the recordset %> You now have a recordset open in asp. To use this, you can just put asp in the middle of the HTML. For example, if you have:

The current value is 1

And you want to make that 1 a value from your recordset:

The current value is <%=rs.fields("NumericValue").value%>

Whalla. You can also do conditional formatting: <% if rs.fields("SomeField").value="SomeValue"%>

Some paragraph in the HTML document

<%else%>

Some other paragraph

<%end if%> You can also loop this way, for example, if you want a table with your data: <%Do until rs.EOF=True%> <%For i=0 to 4 'just assuming 5 fields%> <%next%> <%rs.movenext%> <%loop%>
<%=rs.fields(i).Value%>
You mentioned Frontpage, one of the handy things about Front page is that if you select something in the 'design view', when you switch to the HTML view, the HTML of the selected area will be highlighted too. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/923 - Release Date: 7/27/2007 6:01 PM From ebarro at verizon.net Sat Jul 28 20:33:17 2007 From: ebarro at verizon.net (Eric Barro) Date: Sat, 28 Jul 2007 18:33:17 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: Message-ID: <0JLX00MUA2ZFZ65I@vms040.mailsrvcs.net> If you go this route don't forget to clean up with the following code. Otherwise you don't release the allocated memory and resources back to the server. <% rs.Close Set rs = Nothing cnn.Close Set cnn = Nothing %> -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Saturday, July 28, 2007 5:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Creating HTML file I know I'm late to the party on this, but why must it be a static web page. Making dynamic pages with asp is a snap. Create the HTML in any editor you want. Then save it as an ASP page. <% Dim cnn Dim rs Dim strSQL Set cnn=server.createobject("ADODB.Connection") Set rs=server.createobject("ADODB.Connecion") strSQL="Your SQL string to get the data... 'Then connect the cnn, and open the recordset %> You now have a recordset open in asp. To use this, you can just put asp in the middle of the HTML. For example, if you have:

The current value is 1

And you want to make that 1 a value from your recordset:

The current value is <%=rs.fields("NumericValue").value%>

Whalla. You can also do conditional formatting: <% if rs.fields("SomeField").value="SomeValue"%>

Some paragraph in the HTML document

<%else%>

Some other paragraph

<%end if%> You can also loop this way, for example, if you want a table with your data: <%Do until rs.EOF=True%> <%For i=0 to 4 'just assuming 5 fields%> <%next%> <%rs.movenext%> <%loop%>
<%=rs.fields(i).Value%>
You mentioned Frontpage, one of the handy things about Front page is that if you select something in the 'design view', when you switch to the HTML view, the HTML of the selected area will be highlighted too. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/923 - Release Date: 7/27/2007 6:01 PM From BarbaraRyan at cox.net Sun Jul 29 10:31:17 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Sun, 29 Jul 2007 11:31:17 -0400 Subject: [AccessD] Grid Control Message-ID: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> I would like to use a data grid control in Access for data entry. Any suggestions? Free is best :-) Thanks, Barb Ryan From accessd at shaw.ca Sun Jul 29 12:32:12 2007 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 29 Jul 2007 10:32:12 -0700 Subject: [AccessD] Primary Key Best Practices In-Reply-To: Message-ID: <0JLY00KBTB66VOV2@l-daemon> Well said Charlotte. To give ground is dishonorable and it death before dishonor. :-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, July 26, 2007 9:28 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices Ah, yes, the classic AccessD method for conquering opposition: willfully misinterpret the responses, deny them any validity, and declare yourself the winner! Widely used by Colby and by Drew on occasion. It amounts to "never mind if we're saying much the same thing, you're WRONG!!" LOL Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, July 26, 2007 5:58 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices >From Charlotte: >>You'd still need an identity field to edit it in SQL Server. <> > Yes, you do. The true purpose of a primary key is to uniquely > identify a row. No JIM, you DO NOT. Go to SQL Server (I did!) Create a new table - just two rows is fine (I did) Create two fields (I did) DO NOT create any index whatsoever (I did not) Do NOT create a PK (I did not) Open the table (I did) Enter data (I did) Move off the record so that it stores (I did) Do a couple of more (I did) Edit records (I did) DELETE records (I did) LISTEN VERY CAREFULLY JIM. YOU DO !!!!NOT!!!! HAVE TO HAVE A PK TO DO ANY OF THE THINGS YOU MENTIONED. I have actually done this, apparently you have not. You can have duplicate data, you can have unique data (with a caveat in SQL Server - see below), it simply does NOT MATTER. You can add, edit and delete records in a table in SQL Server without having any keys, candidate or otherwise, and without having any indexes. You need to get off it for a minute and admit that while the model is nice in fact NO RDBMS actually IMPLEMENTS the model. I don't know about you but I actually live in reality and it is important to understand what REALLY HAPPENS out here in the real world. By "your" definition - a candidate key or a PK (which has to be a candidate key) is any field or combination of fields where the data stored in the fields is unique within the table and can therefore be used to uniquely identify the row. YOU can create a table (though you may refuse to do so in order to avoiding admitting this, but I HAVE DONE SO) where there is NO candidate key or PK, and in fact the data in those two fields are exactly the same in some records. You CAN still edit data directly from inside of SQL Server. You can still add records (programmatically with a query), you can still delete records (programmatically with a query), you can still edit records (programmatically, with a query). JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to do ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. NOW... Make two rows in the table identical. SQL Server complains (Access does not btw). You CAN move off of the record, storing the data. However you cannot delete OR EDIT either record (in SQL Server you are screwed apparently, you CAN in Access). You CAN still add new records though (even in SQL Server), and you CAN edit those OTHER records as long as those other records are unique, even in SQL Server. What does this prove? SQL Server has a bug, whereas Access does not. Any way you look at it, SQL Server has a bug, either in allowing the identical data to store, or not allowing the data to be edited later. Notice that: 1) The data STORED whether or not it was unique. 2) EVEN with non unique records in place, more data could be added, edited and deleted (even in SQL Server). 3) Access could delete or modify the data, even the records where the data is not unique, SQL could not. Now, scream all you want Jim, but facts is facts and REAL DBMSs do NOT require a candidate key or a PK in order to add, delete or edit the data in a table. BY YOUR OWN DEFINITION, a PK or candidate key is one where ALL THE DATA in a field or set of fields is unique. BOTH Access and SQL Server can add records, wither the data is unique or not. BOTH databases can add new records whether or not there is data in the table that prevents defining a candidate key or a PK. ACCESS can edit data even in records where the data is exactly the same as another record. JIM, I HAVE DONE THIS! You do NOT have to have a PK in order to ADD EDIT OR DELETE rows in a REAL LIFE record in a REAL LIFE TABLE in a REAL LIFE DATABASE, and MODEL BE DAMNED! If the model LIES, then it is time to pay more careful attention to reality. Models MODEL reality, not vice versa. YOU CLAIM that without a PK you cannot edit data in a relational database. YOU CLAIM that a PK is by necessity a field or set of fields where the data is unique throughout the table. I HAVE PROVEN that your claims are not true! Go ahead Jim, sputter away about how reality doesn't correctly implement the model, that is true, and that is irrelevant. Reality is, and NO RDBMS correctly implements the model in all aspects, and you know that. And (to the immense relief of everyone I am sure) I am SOOOOO done with you and your model and this discussion. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, July 26, 2007 7:28 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices <> Yes, you do. The true purpose of a primary key is to uniquely identify a row. You may not have indicated in the RDBMS system a single index or that any field or fields is a "PK" for the relation, but you are still using one anytime you add or edit the data. The question is: If your going to edit a row, how do you as a user identify which row it is that you need to change? You use the data in the fields combined in a certain way to know that you are editing the correct row. It may mean that you might have to use every field (what is sometimes called a super-key), but you do use a key even if you have not defined one in the RDBMS. If you cannot identify a row uniquely, then storing the data is basically meaningless. This goes to the heart of the point that I was making that a "primary key" is much more then a pointer. It relates to the meaning of the data, not how it's stored. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 7:56 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Charlotte, >You'd still need an identity field to edit it in SQL Server. No, in fact you do not! I have all these huge 1 table databases that I am currently using. They are lists of people / addresses / information about the people. They stand alone, at least initially. I always create an ANPK but... I just created a table in SQL server consisting of two fields char(10), text1 and text2. I saved the table, then I opened the table and edited the data, directly in SQL Server. No PK, I could edit the data. I entered new data records, I went back and edited existing data. I deleted rows. I can do any of the things that you are saying cannot be done, with out a PK, or even an index. Just plain old simple char() fields. Not an index in sight, never mind a unique index. No PK. I can add records, I can edit existing records, I can delete records, directly in the table in SQL Server. In fact my client used these huge data tables (lists of addresses) to create name / address lists that they sold to their clients long before I ever hit the scene. Just one table. They did not understand nor care about PKs. There were no child tables so no pointer was needed to get back to the parent. No unique index can be created, because there are in fact duplicates. They create hashes in order to discover and get rid of the duplicates in the output but there is no field, nor combination of fields that uniquely identify a specific record. The client uses (makes a LOT OF MONEY) off of these tables. Is this a database? I can't answer that. It is a standalone (extremely large) table in a big iron database management system. It generates millions of dollars a year for the owners. They do not in fact ever edit it, but they could if they wanted to, at least inside of SQL Server. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Wednesday, July 25, 2007 5:50 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Primary Key Best Practices You're picking nits, John. You'd still need an identity field to edit it in SQL Server. If the unique key exists, you have a functional PK, whether you call it that or not. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, July 25, 2007 2:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Primary Key Best Practices Any database made up of a single table would not require a PK. John W. Colby Colby Consulting www.ColbyConsulting.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 kost36 at otenet.gr Sun Jul 29 12:57:07 2007 From: kost36 at otenet.gr (Kostas Konstantinidis) Date: Sun, 29 Jul 2007 20:57:07 +0300 Subject: [AccessD] Captioning attachments in msaccess 2007.. In-Reply-To: <6C1791BC61725F44A28C24208026A511126301@karta-exc-int.Karta.com> References: <023901c79eae$2fd7abf0$6401a8c0@kost36><000501c79f60$d003df60$03b0d355@minster33c3r25><6C1791BC61725F44A28C24208026A51112629C@karta-exc-int.Karta.com><128ED29B1D0C4920AA783BECC6E0551B@kost36PC> <6C1791BC61725F44A28C24208026A511126301@karta-exc-int.Karta.com> Message-ID: <978550B175D04FA8BCDBBCFA4BB74CCE@kost36PC> is that possible with any way to get different captions for different attachment images? Thank you /kostas From DWUTKA at Marlow.com Sun Jul 29 15:00:13 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Sun, 29 Jul 2007 15:00:13 -0500 Subject: [AccessD] Creating HTML file In-Reply-To: <0JLX00K962U4VBB5@vms044.mailsrvcs.net> Message-ID: That is true, but every Windows OS since 98 has a webserver in it. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Saturday, July 28, 2007 8:30 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Creating HTML file Probably because an ASP page needs a web server in order to process and display the pages whereas a straight HTML page can be displayed directly by the browser without a need for a web server. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Saturday, July 28, 2007 5:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Creating HTML file I know I'm late to the party on this, but why must it be a static web page. Making dynamic pages with asp is a snap. Create the HTML in any editor you want. Then save it as an ASP page. <% Dim cnn Dim rs Dim strSQL Set cnn=server.createobject("ADODB.Connection") Set rs=server.createobject("ADODB.Connecion") strSQL="Your SQL string to get the data... 'Then connect the cnn, and open the recordset %> You now have a recordset open in asp. To use this, you can just put asp in the middle of the HTML. For example, if you have:

The current value is 1

And you want to make that 1 a value from your recordset:

The current value is <%=rs.fields("NumericValue").value%>

Whalla. You can also do conditional formatting: <% if rs.fields("SomeField").value="SomeValue"%>

Some paragraph in the HTML document

<%else%>

Some other paragraph

<%end if%> You can also loop this way, for example, if you want a table with your data: <%Do until rs.EOF=True%> <%For i=0 to 4 'just assuming 5 fields%> <%next%> <%rs.movenext%> <%loop%>
<%=rs.fields(i).Value%>
You mentioned Frontpage, one of the handy things about Front page is that if you select something in the 'design view', when you switch to the HTML view, the HTML of the selected area will be highlighted too. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 4:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. Regards Steve -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/923 - Release Date: 7/27/2007 6:01 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From miscellany at mvps.org Sun Jul 29 15:44:49 2007 From: miscellany at mvps.org (Steve Schapel) Date: Mon, 30 Jul 2007 08:44:49 +1200 Subject: [AccessD] Creating HTML file In-Reply-To: References: Message-ID: <46ACFC41.5030305@mvps.org> Drew, I think it is very difficult to generalise, as the specific requirements will vary so much from case to case. In my situation, which prompted my original question in this thread, I am working with a distributed application, the users of which have all sorts of different circumstances. The reports in question contain data which changes very infrequently. For me, the desired outcome was for the users of my application to be able to export on demand, their data from their local desktop application to static html pages, and then to incorporate these pages into their own websites in whichever way they see fit. Therefore, in my case, dynamic pages and ASP don't come into the picture at all. On the other hand, your suggestion may well be very applicable in another scenario. Regards Steve Drew Wutka wrote: > That is true, but every Windows OS since 98 has a webserver in it. > From martyconnelly at shaw.ca Sun Jul 29 16:17:23 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Sun, 29 Jul 2007 14:17:23 -0700 Subject: [AccessD] Creating HTML file In-Reply-To: <46ACFC41.5030305@mvps.org> References: <46ACFC41.5030305@mvps.org> Message-ID: <46AD03E3.9010508@shaw.ca> Windows Home versions doesn't have IIS or webserver available If you do Dynamic SQL queries you will need a lot of vbscript code in your html to protect against SQL Injection attacks. I would also use at least Jet Version 8.0 that allows sandbox protection against illegal functions inside the SQL string Steve Schapel wrote: >Drew, > >I think it is very difficult to generalise, as the specific requirements >will vary so much from case to case. In my situation, which prompted my >original question in this thread, I am working with a distributed >application, the users of which have all sorts of different >circumstances. The reports in question contain data which changes very >infrequently. For me, the desired outcome was for the users of my >application to be able to export on demand, their data from their local >desktop application to static html pages, and then to incorporate these >pages into their own websites in whichever way they see fit. Therefore, >in my case, dynamic pages and ASP don't come into the picture at all. >On the other hand, your suggestion may well be very applicable in >another scenario. > >Regards >Steve > >Drew Wutka wrote: > > >>That is true, but every Windows OS since 98 has a webserver in it. >> >> >> -- Marty Connelly Victoria, B.C. Canada From john at winhaven.net Sun Jul 29 16:52:46 2007 From: john at winhaven.net (John Bartow) Date: Sun, 29 Jul 2007 16:52:46 -0500 Subject: [AccessD] Creating HTML file In-Reply-To: References: <46AA5DB1.1010000@mvps.org> Message-ID: <009901c7d22a$cdc33410$6402a8c0@ScuzzPaq> Drew, Its all a matter of customer scope, needs, focus and budget. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Saturday, July 28, 2007 7:55 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Creating HTML file I know I'm late to the party on this, but why must it be a static web page. From john at winhaven.net Sun Jul 29 16:52:46 2007 From: john at winhaven.net (John Bartow) Date: Sun, 29 Jul 2007 16:52:46 -0500 Subject: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) In-Reply-To: <0JLV00MHY0QGZ6AE@vms040.mailsrvcs.net> References: <056501c7d096$ca011990$6402a8c0@ScuzzPaq> <0JLV00MHY0QGZ6AE@vms040.mailsrvcs.net> Message-ID: <009801c7d22a$cd2853a0$6402a8c0@ScuzzPaq> Eric, Thank You. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Friday, July 27, 2007 5:49 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) John/Steve, Here's the code I used a while back when I was still developing in Access 97. If I was doing this today I'd probably re-write the code and make it more modular and use cascading style sheets for formatting. The basic format for any HTML file is... Page Title I would not hard-code any javascript or css but instead link to them at runtime as I've shown above in the section. Pay special attention to the construct """. In most cases you can use "'" instead. ---------------------------------------------------------------------------- ------------------------ Private Sub CreateHTMLFile(strHTMLFileName As String, strImage1 As String, strImage2 As String, strDesc1 As String, strDesc2 As String, strInsured As String, strPolicy As String) Open strHTMLFileName For Output As #1 Print #1, "" Print #1, "" Print #1, "" Print #1, "Photo Template" Print #1, "" Print #1, "" Print #1, "" Print #1, "
" Print #1, "
" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "
" Print #1, "
" & strInsured & "
" Print #1, "
" Print #1, "
" Print #1, "
" & strPolicy & "
" Print #1, "
" Print #1, "
" Print #1, "
" Print #1, "
" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" 'Print #1, "" ' Print #1, "" ' Print #1, "" ' Print #1, "" 'Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "" Print #1, "
  
 " & strDesc1 & " 
   
  
 " & strDesc2 & " 
" Print #1, "
" Print #1, "" Print #1, "" Close #1 End Sub ---------------------------------------------------------------------------- ------------------------ Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow Sent: Friday, July 27, 2007 2:41 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] HTML from Access Report (was mistakenly stolen from:Creating HTML file) Hi Eric, I guess I'm not after quite the same thing as Steve (so sorry I chimed in on your thread Steve, I'll rename mine). I had tried something of this sort with A97 and it didn't work. Now obviously things have changed a lot since then but could you please elaborate a bit on this. What I wish to do is to run a process that creates static html pages from data stored in the database and places them into a folder (which is used by FrontPage). There two approaches I have considered: Write out a text file and use FP VBA to manipulate it into using the default css theme. Or (since I know the css tags) embed the tags directly into the data output from Access. (I would prefer this as I have no desire to learn FP's object model, as it is a dead horse now). I was thinking (hoping, really) that I could do this with a report and use labels (or eventually a lookup table and text fields) to embed the html/css code. I would then output these reports to the folder of choice using the windows generic text only printer. Any thoughts on this? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro Sent: Friday, July 27, 2007 4:17 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Creating HTML file Steve, Grab any HTML editor that generates HTML (preferably drag and drop) and design your page and save it as an HTML file. And then you can open it with Notepad and use the generated HTML source code. Eric -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Friday, July 27, 2007 2:04 PM To: Access Developers discussion and problem solving Subject: [AccessD] Creating HTML file Hi. I am just about to do something I have never tried before. I need to create a static web page from Access data. Using OutputTo from a report has too many problems. Using DoCmd.TransferText acExportHTML doesn't give me the formatting flexibility that I need. Therefore I've decided to try to loop through a recordset and build the html file in code. Main problem being that my html skills are minimal. Has anyone done this type of thing? Any tips? Thanks. 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.22/922 - Release Date: 7/27/2007 6:08 AM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From darrend at nimble.com.au Sun Jul 29 18:29:33 2007 From: darrend at nimble.com.au (Darren D) Date: Mon, 30 Jul 2007 09:29:33 +1000 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files Message-ID: <200707292358.l6TNwXBk026421@databaseadvisors.com> Hi all I am calling a batch file from my access app The batch file just 'merges' a few files into one big file and then gives it a name This is the batch file - Very basic - 1 liner - copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt mynewcoolcombinedfile.XML Pretty basic - but the combining leaves a small ascii type square as the very very last character - Like this ---> Anyone know how to stop this from happening? Or even better - How to 'build' or merge a few files into one big file - from VBA Or even better still - How to insert Text eg Merge "This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into OneCoolFile.XML Many thanks in advance DD From prodevmg at yahoo.com Sun Jul 29 21:18:32 2007 From: prodevmg at yahoo.com (Lonnie Johnson) Date: Sun, 29 Jul 2007 19:18:32 -0700 (PDT) Subject: [AccessD] Grid Control Message-ID: <500485.19239.qm@web33109.mail.mud.yahoo.com> A subform in datasheet or continuous form view will not do? May God bless you beyond your imagination! Lonnie Johnson ProDev, Professional Development of MS Access Databases Visit me at ==> http://www.prodev.us ----- Original Message ---- From: Barbara Ryan To: Access List Sent: Sunday, July 29, 2007 10:31:17 AM Subject: [AccessD] Grid Control I would like to use a data grid control in Access for data entry. Any suggestions? Free is best :-) Thanks, Barb Ryan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ From shamil at users.mns.ru Mon Jul 30 05:47:25 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Mon, 30 Jul 2007 14:47:25 +0400 Subject: [AccessD] Going CRUD way... Message-ID: <002401c7d297$04913bb0$6401a8c0@nant> Hi All, It looks like we haven't yet have here CRUD vs. (mainly) dynamic manually written SQL vs. metadata-driven application (frameworks) development debate? Or did I miss it? Anyway my question is what do you prefer to use when developing applications against MS SQL backend:? - 1) CRUD SPs based approach to work with base tables + custom SPs(views, UDFs,...) to implement custom functionality - and SPs only "visible to outer world"? - 2) dynamic SQL - DAO, ADO, ADO.NET (mainly) manually written etc. with or without SPs (views, UDFs,...)? - 3) metadata driven (flexible) dynamic SQL approach? - 4) you do not use not the first not the second not the third approach - you do use a "mixture" of them IOW you just write code to implement custom functionality and whatever approach to use in every certain case you usually decide as you go... - 5) something else (please add other useful approached I missed to mention here)... Thank you. -- Shamil From accessd666 at yahoo.com Mon Jul 30 07:05:43 2007 From: accessd666 at yahoo.com (Sad Der) Date: Mon, 30 Jul 2007 05:05:43 -0700 (PDT) Subject: [AccessD] Run Access as a service? Message-ID: <591325.22663.qm@web31604.mail.mud.yahoo.com> Hi, Is it possible to run an access db as a serice? I've created something that creates a HTML report. By pressing a button I send the report by mail. I want to do this every evening by using a timed loop. TIA Regards, Sander ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From fuller.artful at gmail.com Mon Jul 30 08:01:44 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 30 Jul 2007 09:01:44 -0400 Subject: [AccessD] Going CRUD way... In-Reply-To: <002401c7d297$04913bb0$6401a8c0@nant> References: <002401c7d297$04913bb0$6401a8c0@nant> Message-ID: <29f585dd0707300601r5b3e66cbl547e0b4c53c66e18@mail.gmail.com> Since you wrote this to the AccessD list, I'll begin there with my response. I'm currently doing an ADP for a riding stable (which will soon be for sale, so if any listers have any friends with riding stables... LOL). The general approach in it is forms bound to views. (Nobody but me gets to talk directly to tables.) Some of the views use table-UDFs to simplify joins. All of the combo-boxes and list-boxes use named queries (views) to retrieve their contents. This app is simple, so there's not much need for complicated sprocs, except here and there. These fall mainly in the Reports realm; a dialog box opens, requests parameters such as "Horse", Start Date and End Date, then invokes the report which invokes the sproc and passes the parameters, so you end up with a cross-tab report showing the particular horse's activities ( group lesson, private lesson, sem-private lesson, injury day, etc.) during the date range. In the larger scheme of things, I use ERwin. Its code-gen capabilities are totally wonderful. It has a template language built-in which will generate your CRUD code automatically, and even give you a choice between returning a rowset and a set out OUTPUT parameters. I hadn't realized the benefit of the latter strategy until I worked on a large project with my friend Dejan Sunderic (who wrote a great book about SQL 2005). That type of sproc is useful only when you want exactly one record back, but if you're searching millions of rows, it's demonstrably faster than returning a rowset. You don't even need a timer to note the difference. In Access, there are significant advantages to using views as the data source, IMO, not the least of which is how easily subforms behave. Access does the dirty work for you. You just create a subform based on a view, plonk it onto a master form, and Access handles the plumbing. It couldn't be easier, and in addition you insulate the actual tables. Suppose that your app contains a form that only selected people (let's call them Managers) ought to see. So in SQL you create a Managers role and grant access to the view(s) in question. Then even if you forget to program around it in your Access app, it's ok -- no one but managers will be able to run that report. The message they will receive isn't elegant, but the data is safe. I'm not an ERwin expert but I have worked with one or two. At one point, I asked my friend and colleague Andrei Pascal whether we could customize the template to place what ERwin calls a description into the Extended Properties code. It took Andrei about 5 minutes to modify the template so it did this. That's two "hats off" -- one to the template language and one to Andrei. The template language is pretty much beyond my feeble intellect, but Andrei just whipped out a tiny little loop that walked every table and added an extended property to every table for every column that had a Description, and poof! All done. I used to hate ERwin and I much preferred PowerDesigner and Dezign (whose interface is pretty much a clone of PowerDesigner, although it lacks lots of the PD power). I was dragged kicking and screaming into using ERwin, but have since grown into an enthusiast, not least because generating CRUD and even customized CRUD is a one-click operation. Arthur On 7/30/07, Shamil Salakhetdinov wrote: > > Hi All, > > It looks like we haven't yet have here CRUD vs. (mainly) dynamic manually > written SQL vs. metadata-driven application (frameworks) development > debate? > Or did I miss it? > > Anyway my question is what do you prefer to use when developing > applications > against MS SQL backend:? > > - 1) CRUD SPs based approach to work with base tables + custom SPs(views, > UDFs,...) to implement custom functionality - and SPs only "visible to > outer > world"? > > - 2) dynamic SQL - DAO, ADO, ADO.NET (mainly) manually written etc. with > or > without SPs (views, UDFs,...)? > > - 3) metadata driven (flexible) dynamic SQL approach? > > - 4) you do not use not the first not the second not the third approach - > you do use a "mixture" of them IOW you just write code to implement custom > functionality and whatever approach to use in every certain case you > usually > decide as you go... > > - 5) something else (please add other useful approached I missed to > mention > here)... > > Thank you. > > > -- > Shamil > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From delam at netcapnow.com Mon Jul 30 08:44:33 2007 From: delam at netcapnow.com (delam at netcapnow.com) Date: Mon, 30 Jul 2007 13:44:33 +0000 Subject: [AccessD] Run Access as a service? In-Reply-To: <591325.22663.qm@web31604.mail.mud.yahoo.com> References: <591325.22663.qm@web31604.mail.mud.yahoo.com> Message-ID: <853952693-1185803083-cardhu_decombobulator_blackberry.rim.net-1912026571-@bxe111.bisx.prod.on.blackberry> I think to run as a service may be beyond Access. However, under the control panel, there are scheduled tasks you can use. I have used these in the past to run Access databases at scheduled intervals. I used the technique of having a version of the database that did nothing but theone task. I set the autoexec in that database to trigger the task on open and close the database when the task was complete. Debbie Sent via BlackBerry by AT&T -----Original Message----- From: Sad Der Date: Mon, 30 Jul 2007 05:05:43 To:Acces User Group Subject: [AccessD] Run Access as a service? Hi, Is it possible to run an access db as a serice? I've created something that creates a HTML report. By pressing a button I send the report by mail. I want to do this every evening by using a timed loop. TIA Regards, Sander ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd666 at yahoo.com Mon Jul 30 08:55:08 2007 From: accessd666 at yahoo.com (Sad Der) Date: Mon, 30 Jul 2007 06:55:08 -0700 (PDT) Subject: [AccessD] Get all controls on all forms Message-ID: <586905.71583.qm@web31611.mail.mud.yahoo.com> Hi group, Does anybody have piece of code that retrieves all controles on all forms in a database? I need to store these in a database. Thnx! Regards, Sander ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow From prodevmg at yahoo.com Mon Jul 30 09:24:29 2007 From: prodevmg at yahoo.com (Lonnie Johnson) Date: Mon, 30 Jul 2007 07:24:29 -0700 (PDT) Subject: [AccessD] Get all controls on all forms Message-ID: <556945.68190.qm@web33109.mail.mud.yahoo.com> This is a simple as it gets. Maybe you can build on this. Dim ctl As Control For Each ctl In Me.Controls MsgBox "Control Name: " & ctl.Name Next ctl May God bless you beyond your imagination! Lonnie Johnson ProDev, Professional Development of MS Access Databases Visit me at ==> http://www.prodev.us ----- Original Message ---- From: Sad Der To: Acces User Group Sent: Monday, July 30, 2007 8:55:08 AM Subject: [AccessD] Get all controls on all forms Hi group, Does anybody have piece of code that retrieves all controles on all forms in a database? I need to store these in a database. Thnx! Regards, Sander ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 From jwcolby at colbyconsulting.com Mon Jul 30 09:29:55 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Mon, 30 Jul 2007 10:29:55 -0400 Subject: [AccessD] Get all controls on all forms In-Reply-To: <586905.71583.qm@web31611.mail.mud.yahoo.com> Message-ID: <20070730143001.50F2FBCA6@smtp-auth.no-ip.com> I do but I don't have time to go find it. Basically forms which are not open are stored in a documents("forms") collection in the database. You have to get the NAME of each document (which will be the name of each form in the db), then use docmd.openform(ThatFormName) and set a parameter of that DoCmd to open it in design view. Once you have done that, then the form is open in the forms() collection so you can get a pointer to the form. With the form open you can get at the controls collection. I forget what object the documents is a part of. It could be the currentdb object, it could be the application object. Dim doc as document Dim frm as form Dim ctl as control For each doc in documents("forms") docmd.open acform, (doc.name),acDesignView set frm = forms(doc.name) for each ctl in frm.controls() next ctl Docmd.close acform, doc.name Next doc IOW, a form has to be OPEN (either in view mode or design view) to access the controls collection. You want to open it in design view. Once it is opened, get a pointer to it and then access the controls collection The code above is NOT working, but it is close (from memory) John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der Sent: Monday, July 30, 2007 9:55 AM To: Acces User Group Subject: [AccessD] Get all controls on all forms Hi group, Does anybody have piece of code that retrieves all controles on all forms in a database? I need to store these in a database. Thnx! Regards, Sander ____________________________________________________________________________ ________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From DWUTKA at Marlow.com Mon Jul 30 09:33:20 2007 From: DWUTKA at Marlow.com (Drew Wutka) Date: Mon, 30 Jul 2007 09:33:20 -0500 Subject: [AccessD] Run Access as a service? In-Reply-To: <591325.22663.qm@web31604.mail.mud.yahoo.com> Message-ID: Not directly. You can do this with VB or .Net, but probably the simplest way would be to just use the scheduling service to run it at the specified time you want it to run. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Sad Der Sent: Monday, July 30, 2007 7:06 AM To: Acces User Group Subject: [AccessD] Run Access as a service? Hi, Is it possible to run an access db as a serice? I've created something that creates a HTML report. By pressing a button I send the report by mail. I want to do this every evening by using a timed loop. TIA Regards, Sander ________________________________________________________________________ ____________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+ki ds&cs=bz -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. From shamil at users.mns.ru Mon Jul 30 09:47:16 2007 From: shamil at users.mns.ru (Shamil Salakhetdinov) Date: Mon, 30 Jul 2007 18:47:16 +0400 Subject: [AccessD] Going CRUD way... In-Reply-To: <29f585dd0707300601r5b3e66cbl547e0b4c53c66e18@mail.gmail.com> Message-ID: <000701c7d2b8$86cb14e0$6401a8c0@nant> Hello Arthur, Thank you for your prompt feedback. May I say you're a "generated CRUDs fun"? (I'm getting like that here too therefore this "generated CRUDs fun" is a respectful nickname here :) ...) Do you have any samples of small CRUDs, which you use *in production*, which therefore proved themselves as stable and which you can publish here? - just one for every type of CRUD (Insert, Update, Delete SQL) + Select (by Id) SQL... Thank you. I must say that views used with WinForms (.NET 2.0), even when parameters are used but when views are run against large amounts of back-end data - such views are (very) slow comparing to parameterized stored procedures. I do use views but only as a "middle-/abstraction tier" between SPs and base tables... -- Shamil P.S. Here is a sample of Update SP I use made based on what OlyMars originally did generate - writing that stuff manually is a "no-go" obviously: if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[a_Table_Update]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) drop procedure [dbo].[a_Table_Update] GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO CREATE Procedure [a_Table_Update] -- Update an existing record in [a_Table] table ( @rowId [int] = Null -- for [a_Table].[ID] column , @ConsiderNull_iD bit = 0 , at bitField [bit] = Null -- for [a_Table].[bitField] column , @ConsiderNull_bitField bit = 0 , at intField [int] = Null -- for [a_Table].[intField] column , @ConsiderNull_intField bit = 0 , at decimalField [decimal] = Null -- for [a_Table].[decimalField] column , @ConsiderNull_decimalField bit = 0 , at numericField [numeric] = Null -- for [a_Table].[numericField] column , @ConsiderNull_numericField bit = 0 , at floatField [float] = Null -- for [a_Table].[floatField] column , @ConsiderNull_floatField bit = 0 , at smallMoneyField [smallmoney] = Null -- for [a_Table].[smallMoneyField] column , @ConsiderNull_smallMoneyField bit = 0 , at charField [char](10) = Null -- for [a_Table].[charField] column , @ConsiderNull_charField bit = 0 , at varcharField [varchar](50) = Null -- for [a_Table].[varcharField] column , @ConsiderNull_varcharField bit = 0 , at textField [text] = Null -- for [a_Table].[textField] column , @ConsiderNull_textField bit = 0 , at nvarCharField [nvarchar](50) = Null -- for [a_Table].[nvarCharField] column , @ConsiderNull_nvarCharField bit = 0 , at ntextField [ntext] = Null -- for [a_Table].[ntextField] column , @ConsiderNull_ntextField bit = 0 , at dateTimeField [datetime] = Null -- for [a_Table].[dateTimeField] column , @ConsiderNull_dateTimeField bit = 0 , at uniqueidentifierField [uniqueidentifier] = Null -- for [a_Table].[uniqueidentifierField] column , @ConsiderNull_uniqueidentifierField bit = 0 , at imageField [image] = Null -- for [a_Table].[imageField] column , @ConsiderNull_imageField bit = 0 ) As Set NoCount On Declare @retValue int If @ConsiderNull_iD Is Null Set @ConsiderNull_iD = 0 If @ConsiderNull_bitField Is Null Set @ConsiderNull_bitField = 0 If @ConsiderNull_intField Is Null Set @ConsiderNull_intField = 0 If @ConsiderNull_decimalField Is Null Set @ConsiderNull_decimalField = 0 If @ConsiderNull_numericField Is Null Set @ConsiderNull_numericField = 0 If @ConsiderNull_floatField Is Null Set @ConsiderNull_floatField = 0 If @ConsiderNull_smallMoneyField Is Null Set @ConsiderNull_smallMoneyField = 0 If @ConsiderNull_charField Is Null Set @ConsiderNull_charField = 0 If @ConsiderNull_varcharField Is Null Set @ConsiderNull_varcharField = 0 If @ConsiderNull_textField Is Null Set @ConsiderNull_textField = 0 If @ConsiderNull_nvarCharField Is Null Set @ConsiderNull_nvarCharField = 0 If @ConsiderNull_ntextField Is Null Set @ConsiderNull_ntextField = 0 If @ConsiderNull_dateTimeField Is Null Set @ConsiderNull_dateTimeField = 0 If @ConsiderNull_uniqueidentifierField Is Null Set @ConsiderNull_uniqueidentifierField = 0 If @ConsiderNull_imageField Is Null Set @ConsiderNull_imageField = 0 Update [dbo].[a_Table] Set [rowId] = Case @ConsiderNull_iD When 0 Then IsNull(@rowId, [rowId]) When 1 Then @rowId End , [bitField] = Case @ConsiderNull_bitField When 0 Then IsNull(@bitField, [bitField]) When 1 Then @bitField End , [intField] = Case @ConsiderNull_intField When 0 Then IsNull(@intField, [intField]) When 1 Then @intField End , [decimalField] = Case @ConsiderNull_decimalField When 0 Then IsNull(@decimalField, [decimalField]) When 1 Then @decimalField End , [numericField] = Case @ConsiderNull_numericField When 0 Then IsNull(@numericField, [numericField]) When 1 Then @numericField End , [floatField] = Case @ConsiderNull_floatField When 0 Then IsNull(@floatField, [floatField]) When 1 Then @floatField End , [smallMoneyField] = Case @ConsiderNull_smallMoneyField When 0 Then IsNull(@smallMoneyField, [smallMoneyField]) When 1 Then @smallMoneyField End , [charField] = Case @ConsiderNull_charField When 0 Then IsNull(@charField, [charField]) When 1 Then @charField End , [varcharField] = Case @ConsiderNull_varcharField When 0 Then IsNull(@varcharField, [varcharField]) When 1 Then @varcharField End , [textField] = Case @ConsiderNull_textField When 0 Then IsNull(@textField, [textField]) When 1 Then @textField End , [nvarCharField] = Case @ConsiderNull_nvarCharField When 0 Then IsNull(@nvarCharField, [nvarCharField]) When 1 Then @nvarCharField End , [ntextField] = Case @ConsiderNull_ntextField When 0 Then IsNull(@ntextField, [ntextField]) When 1 Then @ntextField End , [dateTimeField] = Case @ConsiderNull_dateTimeField When 0 Then IsNull(@dateTimeField, [dateTimeField]) When 1 Then @dateTimeField End , [uniqueidentifierField] = Case @ConsiderNull_uniqueidentifierField When 0 Then IsNull(@uniqueidentifierField, [uniqueidentifierField]) When 1 Then @uniqueidentifierField End , [imageField] = Case @ConsiderNull_imageField When 0 Then IsNull(@imageField, [imageField]) When 1 Then @imageField End Where ([rowId] = @rowId) select @retValue = @@ERROR Set NoCount Off Return(@retValue) GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 30, 2007 5:02 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Going CRUD way... Since you wrote this to the AccessD list, I'll begin there with my response. I'm currently doing an ADP for a riding stable (which will soon be for sale, so if any listers have any friends with riding stables... LOL). The general approach in it is forms bound to views. (Nobody but me gets to talk directly to tables.) Some of the views use table-UDFs to simplify joins. All of the combo-boxes and list-boxes use named queries (views) to retrieve their contents. This app is simple, so there's not much need for complicated sprocs, except here and there. These fall mainly in the Reports realm; a dialog box opens, requests parameters such as "Horse", Start Date and End Date, then invokes the report which invokes the sproc and passes the parameters, so you end up with a cross-tab report showing the particular horse's activities ( group lesson, private lesson, sem-private lesson, injury day, etc.) during the date range. In the larger scheme of things, I use ERwin. Its code-gen capabilities are totally wonderful. It has a template language built-in which will generate your CRUD code automatically, and even give you a choice between returning a rowset and a set out OUTPUT parameters. I hadn't realized the benefit of the latter strategy until I worked on a large project with my friend Dejan Sunderic (who wrote a great book about SQL 2005). That type of sproc is useful only when you want exactly one record back, but if you're searching millions of rows, it's demonstrably faster than returning a rowset. You don't even need a timer to note the difference. In Access, there are significant advantages to using views as the data source, IMO, not the least of which is how easily subforms behave. Access does the dirty work for you. You just create a subform based on a view, plonk it onto a master form, and Access handles the plumbing. It couldn't be easier, and in addition you insulate the actual tables. Suppose that your app contains a form that only selected people (let's call them Managers) ought to see. So in SQL you create a Managers role and grant access to the view(s) in question. Then even if you forget to program around it in your Access app, it's ok -- no one but managers will be able to run that report. The message they will receive isn't elegant, but the data is safe. I'm not an ERwin expert but I have worked with one or two. At one point, I asked my friend and colleague Andrei Pascal whether we could customize the template to place what ERwin calls a description into the Extended Properties code. It took Andrei about 5 minutes to modify the template so it did this. That's two "hats off" -- one to the template language and one to Andrei. The template language is pretty much beyond my feeble intellect, but Andrei just whipped out a tiny little loop that walked every table and added an extended property to every table for every column that had a Description, and poof! All done. I used to hate ERwin and I much preferred PowerDesigner and Dezign (whose interface is pretty much a clone of PowerDesigner, although it lacks lots of the PD power). I was dragged kicking and screaming into using ERwin, but have since grown into an enthusiast, not least because generating CRUD and even customized CRUD is a one-click operation. Arthur On 7/30/07, Shamil Salakhetdinov wrote: > > Hi All, > > It looks like we haven't yet have here CRUD vs. (mainly) dynamic manually > written SQL vs. metadata-driven application (frameworks) development > debate? > Or did I miss it? > > Anyway my question is what do you prefer to use when developing > applications > against MS SQL backend:? > > - 1) CRUD SPs based approach to work with base tables + custom SPs(views, > UDFs,...) to implement custom functionality - and SPs only "visible to > outer > world"? > > - 2) dynamic SQL - DAO, ADO, ADO.NET (mainly) manually written etc. with > or > without SPs (views, UDFs,...)? > > - 3) metadata driven (flexible) dynamic SQL approach? > > - 4) you do not use not the first not the second not the third approach - > you do use a "mixture" of them IOW you just write code to implement custom > functionality and whatever approach to use in every certain case you > usually > decide as you go... > > - 5) something else (please add other useful approached I missed to > mention > here)... > > Thank you. > > > -- > Shamil > > > > -- > 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 cfoust at infostatsystems.com Mon Jul 30 10:50:21 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 30 Jul 2007 08:50:21 -0700 Subject: [AccessD] Data Warehouse In-Reply-To: <200707271816.l6RIGOLF009816@databaseadvisors.com> References: <200707271816.l6RIGOLF009816@databaseadvisors.com> Message-ID: Ok, thanks for clarifying. Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robert L. Stewart Sent: Friday, July 27, 2007 11:13 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Data Warehouse Charlotte, In the case of a customer dimension, it would be the customer primary key from the customer table in the source. The problem comes from having multiple sources. Then you have to use a surrogate key and store the source primary key in a column along with the source name. Sorry, I have been doing it for so long, it is second nature. So, I do not really think about it. Robert At 12:00 PM 7/27/2007, you wrote: >Date: Thu, 26 Jul 2007 13:59:09 -0700 >From: "Charlotte Foust" >Subject: Re: [AccessD] Data Warehouse (Was: Primary Key Best > Practices) >To: "Access Developers discussion and problem solving" > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >Yes, and I have several of Ralph Kimball's books on Data Warehouse >design and I've built a few, but what I was looking for was an >explanation of how a dimension table inherits a single column PK "from >the source primary table." I assume it means that all the distinct >values for that column that exist in the primary table have a matching >PK in the dimension table, but it took me a while to sort it out to >that, and I've *worked* with the things! > >Charlotte Foust -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon Jul 30 10:52:42 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 30 Jul 2007 08:52:42 -0700 Subject: [AccessD] Turning off A2007 Menus In-Reply-To: <29f585dd0707271240w6d43fbet80ef9043e7b434d4@mail.gmail.com> References: <004e01c7d064$4d9cd7e0$0301a8c0@HAL9005> <46AA3DCB.5000501@shaw.ca> <29f585dd0707271240w6d43fbet80ef9043e7b434d4@mail.gmail.com> Message-ID: Of course, in the documentation, Microsoft advises you not to load up the QAT with all those shortcuts! LOL Charlotte -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, July 27, 2007 12:40 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Turning off A2007 Menus You may just have persuaded me to re-install Access 2007. On 7/27/07, MartyConnelly wrote: > > If the "ribbon" takes up too much room, it's easy to hide. > Just right-click on one of the ribbon tabs and choose: > "Minimize the Ribbon." If you want quick access to a button found on > one of the ribbons, just right-click on the button and choose: "Add to > Quick Access Toolbar." Alternatively, you can get a list of all > options and customize the "Quick Access Toolbar." You can easily add > dozens of buttons to the toolbar. > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From cfoust at infostatsystems.com Mon Jul 30 10:55:51 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 30 Jul 2007 08:55:51 -0700 Subject: [AccessD] Grid Control In-Reply-To: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> Message-ID: Is there some reason you must have a grid? The built in continuous forms and datasheet forms are much, much easier to work with. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan Sent: Sunday, July 29, 2007 8:31 AM To: Access List Subject: [AccessD] Grid Control I would like to use a data grid control in Access for data entry. Any suggestions? Free is best :-) Thanks, Barb Ryan -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From Donald.A.McGillivray at sprint.com Mon Jul 30 11:27:07 2007 From: Donald.A.McGillivray at sprint.com (McGillivray, Don [IT]) Date: Mon, 30 Jul 2007 11:27:07 -0500 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files In-Reply-To: <200707292358.l6TNwXBk026421@databaseadvisors.com> References: <200707292358.l6TNwXBk026421@databaseadvisors.com> Message-ID: Darren, I've done something similar by redirecting the output of the DOS "type" command to a file. I've never had an issue with extraneous characters using this method. Something like this: Type *.fil >> BigFile.txt This concatenates the contents of all files with the extension "fil" into a single file called BigFile.txt. Don't know if the order of concatenation is predictable, if that's important to you. As for inserting text between additions or at either end, I think you can redirect the DOS "echo" command in a similar way. Something like: Echo "Start of file" >> BigFile.txt Type *.fil >> BigFile.txt Echo "End of file" >> BigFile.txt Hope this helps . . . Don -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D Sent: Sunday, July 29, 2007 4:30 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files Hi all I am calling a batch file from my access app The batch file just 'merges' a few files into one big file and then gives it a name This is the batch file - Very basic - 1 liner - copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt mynewcoolcombinedfile.XML Pretty basic - but the combining leaves a small ascii type square as the very very last character - Like this ---> Anyone know how to stop this from happening? Or even better - How to 'build' or merge a few files into one big file - from VBA Or even better still - How to insert Text eg Merge "This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into OneCoolFile.XML Many thanks in advance DD -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From robert at webedb.com Mon Jul 30 12:10:42 2007 From: robert at webedb.com (Robert L. Stewart) Date: Mon, 30 Jul 2007 12:10:42 -0500 Subject: [AccessD] Going CRUD way... In-Reply-To: References: Message-ID: <200707301712.l6UHCAkD005195@databaseadvisors.com> Shamil, I have a stored procedure that I use to generate a single CRUD that uses "modes" for each table. If you (or anyone else) would like to get a copy of it, send me a note off list and I will send a copy of it to you. What it does is creates a mode for each of the parts of the CRUD, Create (I mode), Read(A (All) and S (single record) modes), Update (U mode), Delete, (D mode). Plus, I throw in a few other "standard" ones that we have found useful here. You can also add in "custom" modes at the bottom that can give you additional functionality. You can have up to 36 modes if you use a single character. Robert At 10:54 AM 7/30/2007, you wrote: >Date: Mon, 30 Jul 2007 18:47:16 +0400 >From: "Shamil Salakhetdinov" >Subject: Re: [AccessD] Going CRUD way... >To: "'Access Developers discussion and problem solving'" > >Message-ID: <000701c7d2b8$86cb14e0$6401a8c0 at nant> >Content-Type: text/plain; charset="us-ascii" > >Hello Arthur, > >Thank you for your prompt feedback. > >May I say you're a "generated CRUDs fun"? (I'm getting like that here too >therefore this "generated CRUDs fun" is a respectful nickname here :) ...) > >Do you have any samples of small CRUDs, which you use *in production*, which >therefore proved themselves as stable and which you can publish here? - just >one for every type of CRUD (Insert, Update, Delete SQL) + Select (by Id) >SQL... > >Thank you. > > >I must say that views used with WinForms (.NET 2.0), even when parameters >are used but when views are run against large amounts of back-end data - >such views are (very) slow comparing to parameterized stored procedures. > >I do use views but only as a "middle-/abstraction tier" between SPs and base >tables... > >-- >Shamil > From rockysmolin at bchacc.com Mon Jul 30 12:50:51 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 10:50:51 -0700 Subject: [AccessD] Change Printers Message-ID: <004301c7d2d2$2b7d8540$0301a8c0@HAL9005> Dear List: I have a client who wants to print some labels on a roll printer so when they open the form that prints the labels, I'd like them to have a combo box of installed printers (or alternatively a 'browse for printer' function), save the default printer, change to the selected printer, print the label, and change back to the default printer. I know I've done this but I can't find the module where I did it. Does anyone a code snip that does this? MTIA Rocky From JRojas at tnco-inc.com Mon Jul 30 12:54:41 2007 From: JRojas at tnco-inc.com (Joe Rojas) Date: Mon, 30 Jul 2007 13:54:41 -0400 Subject: [AccessD] Export Metadata or Schema References: <200707301712.l6UHCAkD005195@databaseadvisors.com> Message-ID: <758E92433C4F3740B67BE4DD369AF5775C502B@ex2k3.corp.tnco-inc.com> Hello, Is there a way in Access (I'm using 2007 but DB is 2000 format) to export the information that is displayed when you are working with a table in Design View? I am trying to compare the structure of two tables and I thought it would be user to compare this if I could export or copy and paste into Excel. Thanks in advance! Joe Rojas From mmattys at rochester.rr.com Mon Jul 30 13:08:22 2007 From: mmattys at rochester.rr.com (Michael R Mattys) Date: Mon, 30 Jul 2007 14:08:22 -0400 Subject: [AccessD] Export Metadata or Schema References: <200707301712.l6UHCAkD005195@databaseadvisors.com> <758E92433C4F3740B67BE4DD369AF5775C502B@ex2k3.corp.tnco-inc.com> Message-ID: <00be01c7d2d4$9f9c9f90$0202a8c0@Laptop> Dim db as dao.database Dim tdf as dao.tabledef Dim fld as dao.field set db = currentdb For each tdf in db.tabledefs For each fld in tdf.fields debug.print fld.name Next fld Next tdf set db = nothing Michael R. Mattys MapPoint & Access Dev www.mattysconsulting.com ----- Original Message ----- From: "Joe Rojas" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 1:54 PM Subject: [AccessD] Export Metadata or Schema > Hello, > > Is there a way in Access (I'm using 2007 but DB is 2000 format) to > export the information that is displayed when you are working with a > table in Design View? > > I am trying to compare the structure of two tables and I thought it > would be user to compare this if I could export or copy and paste into > Excel. > > Thanks in advance! > > Joe Rojas > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From wdhindman at dejpolsystems.com Mon Jul 30 13:17:34 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 14:17:34 -0400 Subject: [AccessD] Change Printers References: <004301c7d2d2$2b7d8540$0301a8c0@HAL9005> Message-ID: <004301c7d2d5$e74b3080$0c10a8c0@jisshowsbs.local> Rocky ...if the Form is meant to only print the labels on the roll printer, why not set it as the "specific" printer in the form's print properties ...that way you don't get the user involved in the printer selection process ...I usually do this with badge printers. William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 1:50 PM Subject: [AccessD] Change Printers > Dear List: > > I have a client who wants to print some labels on a roll printer so when > they open the form that prints the labels, I'd like them to have a combo > box > of installed printers (or alternatively a 'browse for printer' function), > save the default printer, change to the selected printer, print the label, > and change back to the default printer. > > I know I've done this but I can't find the module where I did it. Does > anyone a code snip that does this? > > MTIA > > Rocky > > > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From martyconnelly at shaw.ca Mon Jul 30 13:19:07 2007 From: martyconnelly at shaw.ca (MartyConnelly) Date: Mon, 30 Jul 2007 11:19:07 -0700 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files In-Reply-To: References: <200707292358.l6TNwXBk026421@databaseadvisors.com> Message-ID: <46AE2B9B.4090804@shaw.ca> Could be a couple of things, I haven't got an Ascii Table handy Have a look at last char in HexEditor. At a guess it could CTRL-Z which is an old DOS EOF McGillivray, Don [IT] wrote: >Darren, > >I've done something similar by redirecting the output of the DOS "type" command to a file. I've never had an issue with extraneous characters using this method. Something like this: > >Type *.fil >> BigFile.txt > >This concatenates the contents of all files with the extension "fil" into a single file called BigFile.txt. Don't know if the order of concatenation is predictable, if that's important to you. > >As for inserting text between additions or at either end, I think you can redirect the DOS "echo" command in a similar way. Something like: > >Echo "Start of file" >> BigFile.txt >Type *.fil >> BigFile.txt >Echo "End of file" >> BigFile.txt > >Hope this helps . . . > >Don > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D >Sent: Sunday, July 29, 2007 4:30 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files > >Hi all > > > >I am calling a batch file from my access app > > > >The batch file just 'merges' a few files into one big file and then gives it a >name > > > >This is the batch file - Very basic - 1 liner - > > > >copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt >mynewcoolcombinedfile.XML > > > >Pretty basic - but the combining leaves a small ascii type square as the very >very last character - Like this ---> > > > >Anyone know how to stop this from happening? > > > >Or even better - How to 'build' or merge a few files into one big file - from >VBA > > > >Or even better still - How to insert Text eg Merge > > > >"This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into >OneCoolFile.XML > > > >Many thanks in advance > > > >DD > > > > > -- Marty Connelly Victoria, B.C. Canada From rockysmolin at bchacc.com Mon Jul 30 13:36:23 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 11:36:23 -0700 Subject: [AccessD] Change Printers In-Reply-To: <004301c7d2d5$e74b3080$0c10a8c0@jisshowsbs.local> Message-ID: <004401c7d2d8$87c4a990$0301a8c0@HAL9005> As soon as I hard code it, they'll change it. So I'd prefer the more flexible route if it's not too much time to do. Also, makes it easier to test. But you're right - if I can't get a chunk of code going in short order, that's what I'll do. The client is actually 4 minutes from the house so dropping in to do the last tweaks and tests is easy. But it would be a nice module to have in the library. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman Sent: Monday, July 30, 2007 11:18 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Change Printers Rocky ...if the Form is meant to only print the labels on the roll printer, why not set it as the "specific" printer in the form's print properties ...that way you don't get the user involved in the printer selection process ...I usually do this with badge printers. William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 1:50 PM Subject: [AccessD] Change Printers > Dear List: > > I have a client who wants to print some labels on a roll printer so when > they open the form that prints the labels, I'd like them to have a combo > box > of installed printers (or alternatively a 'browse for printer' function), > save the default printer, change to the selected printer, print the label, > and change back to the default printer. > > I know I've done this but I can't find the module where I did it. Does > anyone a code snip that does this? > > MTIA > > Rocky > > > > > > > -- > 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 11:14 PM From wdhindman at dejpolsystems.com Mon Jul 30 14:27:37 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 15:27:37 -0400 Subject: [AccessD] Change Printers References: <004401c7d2d8$87c4a990$0301a8c0@HAL9005> Message-ID: <000301c7d2df$b07b7790$0c10a8c0@jisshowsbs.local> ...try http://allenbrowne.com/AppPrintMgt.html William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 2:36 PM Subject: Re: [AccessD] Change Printers > As soon as I hard code it, they'll change it. So I'd prefer the more > flexible route if it's not too much time to do. > > Also, makes it easier to test. But you're right - if I can't get a chunk > of > code going in short order, that's what I'll do. The client is actually 4 > minutes from the house so dropping in to do the last tweaks and tests is > easy. But it would be a nice module to have in the library. > > Rocky > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman > Sent: Monday, July 30, 2007 11:18 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > Rocky > ...if the Form is meant to only print the labels on the roll printer, why > not set it as the "specific" printer in the form's print properties > ...that > way you don't get the user involved in the printer selection process ...I > usually do this with badge printers. > William Hindman > > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 1:50 PM > Subject: [AccessD] Change Printers > > >> Dear List: >> >> I have a client who wants to print some labels on a roll printer so when >> they open the form that prints the labels, I'd like them to have a combo >> box >> of installed printers (or alternatively a 'browse for printer' function), >> save the default printer, change to the selected printer, print the >> label, >> and change back to the default printer. >> >> I know I've done this but I can't find the module where I did it. Does >> anyone a code snip that does this? >> >> MTIA >> >> Rocky >> >> >> >> >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 > 11:14 PM > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From rockysmolin at bchacc.com Mon Jul 30 15:43:49 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 13:43:49 -0700 Subject: [AccessD] Change Printers In-Reply-To: <000301c7d2df$b07b7790$0c10a8c0@jisshowsbs.local> Message-ID: <005c01c7d2ea$5549d230$0301a8c0@HAL9005> Looks like the right stuff. I also found this - if anybody's interested or has the same problem - but I haven't tried it. http://www.mvps.org/access/reports/rpt0009.htm Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman Sent: Monday, July 30, 2007 12:28 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Change Printers ...try http://allenbrowne.com/AppPrintMgt.html William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 2:36 PM Subject: Re: [AccessD] Change Printers > As soon as I hard code it, they'll change it. So I'd prefer the more > flexible route if it's not too much time to do. > > Also, makes it easier to test. But you're right - if I can't get a chunk > of > code going in short order, that's what I'll do. The client is actually 4 > minutes from the house so dropping in to do the last tweaks and tests is > easy. But it would be a nice module to have in the library. > > Rocky > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman > Sent: Monday, July 30, 2007 11:18 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > Rocky > ...if the Form is meant to only print the labels on the roll printer, why > not set it as the "specific" printer in the form's print properties > ...that > way you don't get the user involved in the printer selection process ...I > usually do this with badge printers. > William Hindman > > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 1:50 PM > Subject: [AccessD] Change Printers > > >> Dear List: >> >> I have a client who wants to print some labels on a roll printer so when >> they open the form that prints the labels, I'd like them to have a combo >> box >> of installed printers (or alternatively a 'browse for printer' function), >> save the default printer, change to the selected printer, print the >> label, >> and change back to the default printer. >> >> I know I've done this but I can't find the module where I did it. Does >> anyone a code snip that does this? >> >> MTIA >> >> Rocky >> >> >> >> >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 > 11:14 PM > > > -- > 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 11:14 PM From wdhindman at dejpolsystems.com Mon Jul 30 16:23:29 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 17:23:29 -0400 Subject: [AccessD] Change Printers References: <005c01c7d2ea$5549d230$0301a8c0@HAL9005> Message-ID: <000301c7d2ef$e04407c0$0c10a8c0@jisshowsbs.local> Rocky ...I think you'll find that reference is to pre A2K printer functionality using api calls ...Access has its own printer object now. William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 4:43 PM Subject: Re: [AccessD] Change Printers > Looks like the right stuff. I also found this - if anybody's interested > or > has the same problem - but I haven't tried it. > > http://www.mvps.org/access/reports/rpt0009.htm > > Rocky > > > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman > Sent: Monday, July 30, 2007 12:28 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > ...try http://allenbrowne.com/AppPrintMgt.html > William Hindman > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 2:36 PM > Subject: Re: [AccessD] Change Printers > > >> As soon as I hard code it, they'll change it. So I'd prefer the more >> flexible route if it's not too much time to do. >> >> Also, makes it easier to test. But you're right - if I can't get a chunk >> of >> code going in short order, that's what I'll do. The client is actually 4 >> minutes from the house so dropping in to do the last tweaks and tests is >> easy. But it would be a nice module to have in the library. >> >> Rocky >> >> >> >> >> >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William >> Hindman >> Sent: Monday, July 30, 2007 11:18 AM >> To: Access Developers discussion and problem solving >> Subject: Re: [AccessD] Change Printers >> >> Rocky >> ...if the Form is meant to only print the labels on the roll printer, why >> not set it as the "specific" printer in the form's print properties >> ...that >> way you don't get the user involved in the printer selection process ...I >> usually do this with badge printers. >> William Hindman >> >> ----- Original Message ----- >> From: "Rocky Smolin at Beach Access Software" >> To: "'Access Developers discussion and problem solving'" >> >> Sent: Monday, July 30, 2007 1:50 PM >> Subject: [AccessD] Change Printers >> >> >>> Dear List: >>> >>> I have a client who wants to print some labels on a roll printer so when >>> they open the form that prints the labels, I'd like them to have a combo >>> box >>> of installed printers (or alternatively a 'browse for printer' >>> function), >>> save the default printer, change to the selected printer, print the >>> label, >>> and change back to the default printer. >>> >>> I know I've done this but I can't find the module where I did it. Does >>> anyone a code snip that does this? >>> >>> MTIA >>> >>> Rocky >>> >>> >>> >>> >>> >>> >>> -- >>> 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 incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: >> 7/29/2007 >> 11:14 PM >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 > 11:14 PM > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From gustav at cactus.dk Mon Jul 30 16:59:04 2007 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 30 Jul 2007 23:59:04 +0200 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files Message-ID: Hi Darren Try with COPY /B, that should remove the EOF byte. /gustav >>> martyconnelly at shaw.ca 30-07-07 20:19 >>> Could be a couple of things, I haven't got an Ascii Table handy Have a look at last char in HexEditor. At a guess it could CTRL-Z which is an old DOS EOF McGillivray, Don [IT] wrote: >Darren, > >I've done something similar by redirecting the output of the DOS "type" command to a file. I've never had an issue with extraneous characters using this method. Something like this: > >Type *.fil >> BigFile.txt > >This concatenates the contents of all files with the extension "fil" into a single file called BigFile.txt. Don't know if the order of concatenation is predictable, if that's important to you. > >As for inserting text between additions or at either end, I think you can redirect the DOS "echo" command in a similar way. Something like: > >Echo "Start of file" >> BigFile.txt >Type *.fil >> BigFile.txt >Echo "End of file" >> BigFile.txt > >Hope this helps . . . > >Don > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D >Sent: Sunday, July 29, 2007 4:30 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files > >Hi all > > > >I am calling a batch file from my access app > > > >The batch file just 'merges' a few files into one big file and then gives it a >name > > > >This is the batch file - Very basic - 1 liner - > > > >copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt >mynewcoolcombinedfile.XML > > > >Pretty basic - but the combining leaves a small ascii type square as the very >very last character - Like this ---> > > > >Anyone know how to stop this from happening? > > > >Or even better - How to 'build' or merge a few files into one big file - from >VBA > > > >Or even better still - How to insert Text eg Merge > > > >"This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into >OneCoolFile.XML > > > >Many thanks in advance > > > >DD From rockysmolin at bchacc.com Mon Jul 30 17:22:16 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 15:22:16 -0700 Subject: [AccessD] Change Printers In-Reply-To: <000301c7d2ef$e04407c0$0c10a8c0@jisshowsbs.local> Message-ID: <007701c7d2f8$1656fb30$0301a8c0@HAL9005> I don't see the form's print properties you referred to. Where is that? Also, wouldn't it be the report's print properties? (which I don't see either) Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman Sent: Monday, July 30, 2007 2:23 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Change Printers Rocky ...I think you'll find that reference is to pre A2K printer functionality using api calls ...Access has its own printer object now. William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 4:43 PM Subject: Re: [AccessD] Change Printers > Looks like the right stuff. I also found this - if anybody's > interested or has the same problem - but I haven't tried it. > > http://www.mvps.org/access/reports/rpt0009.htm > > Rocky > > > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William > Hindman > Sent: Monday, July 30, 2007 12:28 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > ...try http://allenbrowne.com/AppPrintMgt.html > William Hindman > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 2:36 PM > Subject: Re: [AccessD] Change Printers > > >> As soon as I hard code it, they'll change it. So I'd prefer the more >> flexible route if it's not too much time to do. >> >> Also, makes it easier to test. But you're right - if I can't get a >> chunk of code going in short order, that's what I'll do. The client >> is actually 4 minutes from the house so dropping in to do the last >> tweaks and tests is easy. But it would be a nice module to have in >> the library. >> >> Rocky >> >> >> >> >> >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William >> Hindman >> Sent: Monday, July 30, 2007 11:18 AM >> To: Access Developers discussion and problem solving >> Subject: Re: [AccessD] Change Printers >> >> Rocky >> ...if the Form is meant to only print the labels on the roll printer, >> why not set it as the "specific" printer in the form's print >> properties ...that way you don't get the user involved in the printer >> selection process ...I usually do this with badge printers. >> William Hindman >> >> ----- Original Message ----- >> From: "Rocky Smolin at Beach Access Software" >> >> To: "'Access Developers discussion and problem solving'" >> >> Sent: Monday, July 30, 2007 1:50 PM >> Subject: [AccessD] Change Printers >> >> >>> Dear List: >>> >>> I have a client who wants to print some labels on a roll printer so >>> when they open the form that prints the labels, I'd like them to >>> have a combo box of installed printers (or alternatively a 'browse >>> for printer' >>> function), >>> save the default printer, change to the selected printer, print the >>> label, and change back to the default printer. >>> >>> I know I've done this but I can't find the module where I did it. >>> Does anyone a code snip that does this? >>> >>> MTIA >>> >>> Rocky >>> >>> >>> >>> >>> >>> >>> -- >>> 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 incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: >> 7/29/2007 >> 11:14 PM >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: > 7/29/2007 > 11:14 PM > > > -- > 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 11:14 PM From BarbaraRyan at cox.net Mon Jul 30 18:01:24 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Mon, 30 Jul 2007 19:01:24 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> Message-ID: <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> I normally would use continuous forms, but for this worker "scheduling" form (i.e., rows are worker types; columns are dates "07/01/07", "07/02/07"...) I thought I would check out grid controls to see if they would offer any advantages. Barb Ryan ----- Original Message ----- From: "Charlotte Foust" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 11:55 AM Subject: Re: [AccessD] Grid Control > Is there some reason you must have a grid? The built in continuous > forms and datasheet forms are much, much easier to work with. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan > Sent: Sunday, July 29, 2007 8:31 AM > To: Access List > Subject: [AccessD] Grid Control > > I would like to use a data grid control in Access for data entry. Any > suggestions? Free is best :-) > > Thanks, > Barb Ryan > -- > 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 cfoust at infostatsystems.com Mon Jul 30 18:10:10 2007 From: cfoust at infostatsystems.com (Charlotte Foust) Date: Mon, 30 Jul 2007 16:10:10 -0700 Subject: [AccessD] Grid Control In-Reply-To: <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> Message-ID: I haven't worked with grids in the last couple of versions, so I'm outdated. When I worked with them, you had to populate them programatically, and that doesn't seem worth the effort IMO. Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan Sent: Monday, July 30, 2007 4:01 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Grid Control I normally would use continuous forms, but for this worker "scheduling" form (i.e., rows are worker types; columns are dates "07/01/07", "07/02/07"...) I thought I would check out grid controls to see if they would offer any advantages. Barb Ryan ----- Original Message ----- From: "Charlotte Foust" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 11:55 AM Subject: Re: [AccessD] Grid Control > Is there some reason you must have a grid? The built in continuous > forms and datasheet forms are much, much easier to work with. > > Charlotte Foust > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan > Sent: Sunday, July 29, 2007 8:31 AM > To: Access List > Subject: [AccessD] Grid Control > > I would like to use a data grid control in Access for data entry. Any > suggestions? Free is best :-) > > Thanks, > Barb Ryan > -- > 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 miscellany at mvps.org Mon Jul 30 18:30:54 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 31 Jul 2007 11:30:54 +1200 Subject: [AccessD] Change Printers In-Reply-To: <007701c7d2f8$1656fb30$0301a8c0@HAL9005> References: <007701c7d2f8$1656fb30$0301a8c0@HAL9005> Message-ID: <46AE74AE.4060506@mvps.org> Rocky, In design view of the report, go to the File|Page Setup menu, and see under the 'Page' tab. Regards Steve Rocky Smolin at Beach Access Software wrote: > I don't see the form's print properties you referred to. Where is that? > Also, wouldn't it be the report's print properties? (which I don't see > either) From miscellany at mvps.org Mon Jul 30 18:36:55 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 31 Jul 2007 11:36:55 +1200 Subject: [AccessD] Grid Control In-Reply-To: <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> Message-ID: <46AE7617.9020204@mvps.org> Barbara, It might be worth giving this a try: http://www.devexpress.com/Products/ActiveX/XQuantumGrid/Index.xml I haven't used it myself. But I use the Sidebar control from the same company, and it is cool. Regards Steve Barbara Ryan wrote: > I normally would use continuous forms, but for this worker "scheduling" form > (i.e., rows are worker types; columns are dates "07/01/07", "07/02/07"...) I > thought I would check out grid controls to see if they would offer any > advantages. From rockysmolin at bchacc.com Mon Jul 30 18:50:45 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Mon, 30 Jul 2007 16:50:45 -0700 Subject: [AccessD] Change Printers In-Reply-To: <46AE74AE.4060506@mvps.org> Message-ID: <009201c7d304$72ce6f90$0301a8c0@HAL9005> Got it. Thanks. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Steve Schapel Sent: Monday, July 30, 2007 4:31 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Change Printers Rocky, In design view of the report, go to the File|Page Setup menu, and see under the 'Page' tab. Regards Steve Rocky Smolin at Beach Access Software wrote: > I don't see the form's print properties you referred to. Where is that? > Also, wouldn't it be the report's print properties? (which I don't see > either) -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 11:14 PM From wdhindman at dejpolsystems.com Mon Jul 30 19:25:19 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 20:25:19 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35><00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <46AE7617.9020204@mvps.org> Message-ID: <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> Steve ...that's an ATL based grid, don't think it will work in Access William Hindman ----- Original Message ----- From: "Steve Schapel" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 7:36 PM Subject: Re: [AccessD] Grid Control > Barbara, > > It might be worth giving this a try: > http://www.devexpress.com/Products/ActiveX/XQuantumGrid/Index.xml > > I haven't used it myself. But I use the Sidebar control from the same > company, and it is cool. > > Regards > Steve > > > Barbara Ryan wrote: >> I normally would use continuous forms, but for this worker "scheduling" >> form >> (i.e., rows are worker types; columns are dates "07/01/07", >> "07/02/07"...) I >> thought I would check out grid controls to see if they would offer any >> advantages. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From wdhindman at dejpolsystems.com Mon Jul 30 19:46:56 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 20:46:56 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> Message-ID: <000301c7d30c$4c43d290$517a6c4c@jisshowsbs.local> Barbara ...I think I sent you an all Access vba scheduling grid sample app pretty much like you describe a few months or so back when you were heading out on your own ...you might want to take a look there first ...if you don't find it, let me know. William Hindman ----- Original Message ----- From: "Barbara Ryan" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 7:01 PM Subject: Re: [AccessD] Grid Control >I normally would use continuous forms, but for this worker "scheduling" >form > (i.e., rows are worker types; columns are dates "07/01/07", "07/02/07"...) > I > thought I would check out grid controls to see if they would offer any > advantages. > > Barb Ryan > > ----- Original Message ----- > From: "Charlotte Foust" > To: "Access Developers discussion and problem solving" > > Sent: Monday, July 30, 2007 11:55 AM > Subject: Re: [AccessD] Grid Control > > >> Is there some reason you must have a grid? The built in continuous >> forms and datasheet forms are much, much easier to work with. >> >> Charlotte Foust >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan >> Sent: Sunday, July 29, 2007 8:31 AM >> To: Access List >> Subject: [AccessD] Grid Control >> >> I would like to use a data grid control in Access for data entry. Any >> suggestions? Free is best :-) >> >> Thanks, >> Barb Ryan >> -- >> 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 wdhindman at dejpolsystems.com Mon Jul 30 19:48:54 2007 From: wdhindman at dejpolsystems.com (William Hindman) Date: Mon, 30 Jul 2007 20:48:54 -0400 Subject: [AccessD] Change Printers References: <007701c7d2f8$1656fb30$0301a8c0@HAL9005> Message-ID: <000901c7d30c$927ef2d0$517a6c4c@jisshowsbs.local> ...form, report ...when you get to be my age it all kind of runs together :) William Hindman ----- Original Message ----- From: "Rocky Smolin at Beach Access Software" To: "'Access Developers discussion and problem solving'" Sent: Monday, July 30, 2007 6:22 PM Subject: Re: [AccessD] Change Printers >I don't see the form's print properties you referred to. Where is that? > Also, wouldn't it be the report's print properties? (which I don't see > either) > > Rocky > > > > > > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman > Sent: Monday, July 30, 2007 2:23 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Change Printers > > Rocky > ...I think you'll find that reference is to pre A2K printer functionality > using api calls ...Access has its own printer object now. > William Hindman > ----- Original Message ----- > From: "Rocky Smolin at Beach Access Software" > To: "'Access Developers discussion and problem solving'" > > Sent: Monday, July 30, 2007 4:43 PM > Subject: Re: [AccessD] Change Printers > > >> Looks like the right stuff. I also found this - if anybody's >> interested or has the same problem - but I haven't tried it. >> >> http://www.mvps.org/access/reports/rpt0009.htm >> >> Rocky >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William >> Hindman >> Sent: Monday, July 30, 2007 12:28 PM >> To: Access Developers discussion and problem solving >> Subject: Re: [AccessD] Change Printers >> >> ...try http://allenbrowne.com/AppPrintMgt.html >> William Hindman >> ----- Original Message ----- >> From: "Rocky Smolin at Beach Access Software" >> To: "'Access Developers discussion and problem solving'" >> >> Sent: Monday, July 30, 2007 2:36 PM >> Subject: Re: [AccessD] Change Printers >> >> >>> As soon as I hard code it, they'll change it. So I'd prefer the more >>> flexible route if it's not too much time to do. >>> >>> Also, makes it easier to test. But you're right - if I can't get a >>> chunk of code going in short order, that's what I'll do. The client >>> is actually 4 minutes from the house so dropping in to do the last >>> tweaks and tests is easy. But it would be a nice module to have in >>> the library. >>> >>> Rocky >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: accessd-bounces at databaseadvisors.com >>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William >>> Hindman >>> Sent: Monday, July 30, 2007 11:18 AM >>> To: Access Developers discussion and problem solving >>> Subject: Re: [AccessD] Change Printers >>> >>> Rocky >>> ...if the Form is meant to only print the labels on the roll printer, >>> why not set it as the "specific" printer in the form's print >>> properties ...that way you don't get the user involved in the printer >>> selection process ...I usually do this with badge printers. >>> William Hindman >>> >>> ----- Original Message ----- >>> From: "Rocky Smolin at Beach Access Software" >>> >>> To: "'Access Developers discussion and problem solving'" >>> >>> Sent: Monday, July 30, 2007 1:50 PM >>> Subject: [AccessD] Change Printers >>> >>> >>>> Dear List: >>>> >>>> I have a client who wants to print some labels on a roll printer so >>>> when they open the form that prints the labels, I'd like them to >>>> have a combo box of installed printers (or alternatively a 'browse >>>> for printer' >>>> function), >>>> save the default printer, change to the selected printer, print the >>>> label, and change back to the default printer. >>>> >>>> I know I've done this but I can't find the module where I did it. >>>> Does anyone a code snip that does this? >>>> >>>> MTIA >>>> >>>> Rocky >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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 incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: >>> 7/29/2007 >>> 11:14 PM >>> >>> >>> -- >>> 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 incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: >> 7/29/2007 >> 11:14 PM >> >> >> -- >> 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 incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 7/29/2007 > 11:14 PM > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From anitatiedemann at gmail.com Mon Jul 30 19:50:18 2007 From: anitatiedemann at gmail.com (Anita Smith) Date: Tue, 31 Jul 2007 10:50:18 +1000 Subject: [AccessD] Grid Control In-Reply-To: <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <46AE7617.9020204@mvps.org> <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> Message-ID: I use the Janus GridEX 2000 ActiveX Control in most of my Access applications. It can be bound to a Recordset, Table or Query. It gives me so much flexibility with a wealth of features. It is not free, but totally worth the cost. Anita On 7/31/07, William Hindman wrote: > > Steve > ...that's an ATL based grid, don't think it will work in Access > William Hindman > ----- Original Message ----- > From: "Steve Schapel" > To: "Access Developers discussion and problem solving" > > Sent: Monday, July 30, 2007 7:36 PM > Subject: Re: [AccessD] Grid Control > > > > Barbara, > > > > It might be worth giving this a try: > > http://www.devexpress.com/Products/ActiveX/XQuantumGrid/Index.xml > > > > I haven't used it myself. But I use the Sidebar control from the same > > company, and it is cool. > > > > Regards > > Steve > > > > > > Barbara Ryan wrote: > >> I normally would use continuous forms, but for this worker "scheduling" > >> form > >> (i.e., rows are worker types; columns are dates "07/01/07", > >> "07/02/07"...) I > >> thought I would check out grid controls to see if they would offer any > >> advantages. > > -- > > 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 BarbaraRyan at cox.net Mon Jul 30 20:02:57 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Mon, 30 Jul 2007 21:02:57 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35><00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <000301c7d30c$4c43d290$517a6c4c@jisshowsbs.local> Message-ID: <014401c7d30e$885ba9e0$0a00a8c0@PCRURI35> William.... The Contacts app that you sent has been very helpful. I forgot about the scheduling app. I will take a look at it --- thanks for reminding me I had it!!! Barb Ryan ----- Original Message ----- From: "William Hindman" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 8:46 PM Subject: Re: [AccessD] Grid Control > Barbara > > ...I think I sent you an all Access vba scheduling grid sample app pretty > much like you describe a few months or so back when you were heading out > on > your own ...you might want to take a look there first ...if you don't find > it, let me know. > > William Hindman > > ----- Original Message ----- > From: "Barbara Ryan" > To: "Access Developers discussion and problem solving" > > Sent: Monday, July 30, 2007 7:01 PM > Subject: Re: [AccessD] Grid Control > > >>I normally would use continuous forms, but for this worker "scheduling" >>form >> (i.e., rows are worker types; columns are dates "07/01/07", >> "07/02/07"...) >> I >> thought I would check out grid controls to see if they would offer any >> advantages. >> >> Barb Ryan >> >> ----- Original Message ----- >> From: "Charlotte Foust" >> To: "Access Developers discussion and problem solving" >> >> Sent: Monday, July 30, 2007 11:55 AM >> Subject: Re: [AccessD] Grid Control >> >> >>> Is there some reason you must have a grid? The built in continuous >>> forms and datasheet forms are much, much easier to work with. >>> >>> Charlotte Foust >>> >>> -----Original Message----- >>> From: accessd-bounces at databaseadvisors.com >>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan >>> Sent: Sunday, July 29, 2007 8:31 AM >>> To: Access List >>> Subject: [AccessD] Grid Control >>> >>> I would like to use a data grid control in Access for data entry. Any >>> suggestions? Free is best :-) >>> >>> Thanks, >>> Barb Ryan >>> -- >>> 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 BarbaraRyan at cox.net Mon Jul 30 20:05:35 2007 From: BarbaraRyan at cox.net (Barbara Ryan) Date: Mon, 30 Jul 2007 21:05:35 -0400 Subject: [AccessD] Grid Control References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35><00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <46AE7617.9020204@mvps.org><001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> Message-ID: <014a01c7d30e$e69b9fb0$0a00a8c0@PCRURI35> Anita.... I see that there is a trial version. I'll take a look at it. Thanks, Barb ----- Original Message ----- From: "Anita Smith" To: "Access Developers discussion and problem solving" Sent: Monday, July 30, 2007 8:50 PM Subject: Re: [AccessD] Grid Control >I use the Janus GridEX 2000 ActiveX Control in most of my Access > applications. It can be bound to a Recordset, Table or Query. It gives me > so > much flexibility with a wealth of features. It is not free, but totally > worth the cost. > > Anita > > > On 7/31/07, William Hindman wrote: >> >> Steve >> ...that's an ATL based grid, don't think it will work in Access >> William Hindman >> ----- Original Message ----- >> From: "Steve Schapel" >> To: "Access Developers discussion and problem solving" >> >> Sent: Monday, July 30, 2007 7:36 PM >> Subject: Re: [AccessD] Grid Control >> >> >> > Barbara, >> > >> > It might be worth giving this a try: >> > http://www.devexpress.com/Products/ActiveX/XQuantumGrid/Index.xml >> > >> > I haven't used it myself. But I use the Sidebar control from the same >> > company, and it is cool. >> > >> > Regards >> > Steve >> > >> > >> > Barbara Ryan wrote: >> >> I normally would use continuous forms, but for this worker >> >> "scheduling" >> >> form >> >> (i.e., rows are worker types; columns are dates "07/01/07", >> >> "07/02/07"...) I >> >> thought I would check out grid controls to see if they would offer any >> >> advantages. >> > -- >> > 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 Mon Jul 30 20:17:53 2007 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 30 Jul 2007 21:17:53 -0400 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files In-Reply-To: References: Message-ID: <29f585dd0707301817t282a66b9g1b59efb70ff241e@mail.gmail.com> Plus you can even do things like copy file1.txt + file2.txt + file3.txt result.txt. Arthur On 7/30/07, Gustav Brock wrote: > > Hi Darren > > Try with COPY /B, that should remove the EOF byte. > > /gustav > From miscellany at mvps.org Mon Jul 30 23:33:40 2007 From: miscellany at mvps.org (Steve Schapel) Date: Tue, 31 Jul 2007 16:33:40 +1200 Subject: [AccessD] Grid Control In-Reply-To: <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> References: <002101c7d1f5$81cff230$0a00a8c0@PCRURI35> <00e201c7d2fd$8d642d60$0a00a8c0@PCRURI35> <46AE7617.9020204@mvps.org> <001501c7d309$46e04de0$517a6c4c@jisshowsbs.local> Message-ID: <46AEBBA4.2010002@mvps.org> William, It does work in Access, but you need to use ADO. Regards Steve William Hindman wrote: > Steve > ...that's an ATL based grid, don't think it will work in Access From michael at ddisolutions.com.au Tue Jul 31 01:33:46 2007 From: michael at ddisolutions.com.au (Michael Maddison) Date: Tue, 31 Jul 2007 16:33:46 +1000 Subject: [AccessD] Going CRUD way... References: <000701c7d2b8$86cb14e0$6401a8c0@nant> Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D01289B43@ddi-01.DDI.local> Hi Guys, Heres a sample of the CRUD generated by NetTiers an a simple lookup table. I've used a couple of times now. Of course it also generates all the C# objects to go with it. IMO for complex systems CRUD makes good sense. CREATE PROCEDURE dbo.Agency_GetPaged ( @WhereClause varchar (2000) , @OrderBy varchar (2000) , @PageIndex int , @PageSize int ) AS BEGIN DECLARE @PageLowerBound int DECLARE @PageUpperBound int -- Set the page bounds SET @PageLowerBound = @PageSize * @PageIndex SET @PageUpperBound = @PageLowerBound + @PageSize -- Create a temp table to store the select results Create Table #PageIndex ( [IndexId] int IDENTITY (1, 1) NOT NULL, [AgencyID] int ) -- Insert into the temp table declare @SQL as nvarchar(4000) SET @SQL = 'INSERT INTO #PageIndex (AgencyID)' SET @SQL = @SQL + ' SELECT' IF @PageSize > 0 BEGIN SET @SQL = @SQL + ' TOP ' + convert(nvarchar, @PageUpperBound) END SET @SQL = @SQL + ' [AgencyID]' SET @SQL = @SQL + ' FROM dbo.[Agency]' IF LEN(@WhereClause) > 0 BEGIN SET @SQL = @SQL + ' WHERE ' + @WhereClause END IF LEN(@OrderBy) > 0 BEGIN SET @SQL = @SQL + ' ORDER BY ' + @OrderBy END -- Populate the temp table exec sp_executesql @SQL -- Return paged results SELECT O.[AgencyID], O.[AgencyName], O.[AgencyAbbr] FROM dbo.[Agency] O, #PageIndex PageIndex WHERE PageIndex.IndexID > @PageLowerBound AND O.[AgencyID] = PageIndex.[AgencyID] ORDER BY PageIndex.IndexID -- get row count SET @SQL = 'SELECT COUNT(*) as TotalRowCount' SET @SQL = @SQL + ' FROM dbo.[Agency]' IF LEN(@WhereClause) > 0 BEGIN SET @SQL = @SQL + ' WHERE ' + @WhereClause END exec sp_executesql @SQL END GO CREATE PROCEDURE dbo.Agency_Delete ( @AgencyID int ) AS DELETE FROM dbo.[Agency] WITH (ROWLOCK) WHERE [AgencyID] = @AgencyID CREATE PROCEDURE dbo.Agency_Find ( @SearchUsingOR bit = null , @AgencyID int = null , @AgencyName nvarchar (50) = null , @AgencyAbbr nvarchar (5) = null ) AS IF ISNULL(@SearchUsingOR, 0) <> 1 BEGIN SELECT [AgencyID] , [AgencyName] , [AgencyAbbr] FROM dbo.[Agency] WHERE ([AgencyID] = @AgencyID OR @AgencyID is null) AND ([AgencyName] = @AgencyName OR @AgencyName is null) AND ([AgencyAbbr] = @AgencyAbbr OR @AgencyAbbr is null) END ELSE BEGIN SELECT [AgencyID] , [AgencyName] , [AgencyAbbr] FROM dbo.[Agency] WHERE ([AgencyID] = @AgencyID AND @AgencyID is not null) OR ([AgencyName] = @AgencyName AND @AgencyName is not null) OR ([AgencyAbbr] = @AgencyAbbr AND @AgencyAbbr is not null) Select @@ROWCOUNT END GO CREATE PROCEDURE dbo.Agency_Get_List AS SELECT [AgencyID], [AgencyName], [AgencyAbbr] FROM dbo.[Agency] Select @@ROWCOUNT GO CREATE PROCEDURE dbo.Agency_GetByAgencyID ( @AgencyID int ) AS SELECT [AgencyID], [AgencyName], [AgencyAbbr] FROM dbo.[Agency] WHERE [AgencyID] = @AgencyID Select @@ROWCOUNT GO CREATE PROCEDURE dbo.Agency_Insert ( @AgencyID int OUTPUT, @AgencyName nvarchar (50) , @AgencyAbbr nvarchar (5) ) AS INSERT INTO dbo.[Agency] ( [AgencyName] ,[AgencyAbbr] ) VALUES ( @AgencyName , at AgencyAbbr ) -- Get the identity value SET @AgencyID = SCOPE_IDENTITY() GO CREATE PROCEDURE dbo.Agency_Update ( @AgencyID int , @AgencyName nvarchar (50) , @AgencyAbbr nvarchar (5) ) AS -- Modify the updatable columns UPDATE dbo.[Agency] SET [AgencyName] = @AgencyName ,[AgencyAbbr] = @AgencyAbbr WHERE [AgencyID] = @AgencyID GO cheers Michael M To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Going CRUD way... Hello Arthur, Thank you for your prompt feedback. May I say you're a "generated CRUDs fun"? (I'm getting like that here too therefore this "generated CRUDs fun" is a respectful nickname here :) ...) Do you have any samples of small CRUDs, which you use *in production*, which therefore proved themselves as stable and which you can publish here? - just one for every type of CRUD (Insert, Update, Delete SQL) + Select (by Id) SQL... Thank you. I must say that views used with WinForms (.NET 2.0), even when parameters are used but when views are run against large amounts of back-end data - such views are (very) slow comparing to parameterized stored procedures. I do use views but only as a "middle-/abstraction tier" between SPs and base tables... -- Shamil P.S. Here is a sample of Update SP I use made based on what OlyMars originally did generate - writing that stuff manually is a "no-go" obviously: if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[a_Table_Update]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) drop procedure [dbo].[a_Table_Update] GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO CREATE Procedure [a_Table_Update] -- Update an existing record in [a_Table] table ( @rowId [int] = Null -- for [a_Table].[ID] column , @ConsiderNull_iD bit = 0 , at bitField [bit] = Null -- for [a_Table].[bitField] column , @ConsiderNull_bitField bit = 0 , at intField [int] = Null -- for [a_Table].[intField] column , @ConsiderNull_intField bit = 0 , at decimalField [decimal] = Null -- for [a_Table].[decimalField] column , @ConsiderNull_decimalField bit = 0 , at numericField [numeric] = Null -- for [a_Table].[numericField] column , @ConsiderNull_numericField bit = 0 , at floatField [float] = Null -- for [a_Table].[floatField] column , @ConsiderNull_floatField bit = 0 , at smallMoneyField [smallmoney] = Null -- for [a_Table].[smallMoneyField] column , @ConsiderNull_smallMoneyField bit = 0 , at charField [char](10) = Null -- for [a_Table].[charField] column , @ConsiderNull_charField bit = 0 , at varcharField [varchar](50) = Null -- for [a_Table].[varcharField] column , @ConsiderNull_varcharField bit = 0 , at textField [text] = Null -- for [a_Table].[textField] column , @ConsiderNull_textField bit = 0 , at nvarCharField [nvarchar](50) = Null -- for [a_Table].[nvarCharField] column , @ConsiderNull_nvarCharField bit = 0 , at ntextField [ntext] = Null -- for [a_Table].[ntextField] column , @ConsiderNull_ntextField bit = 0 , at dateTimeField [datetime] = Null -- for [a_Table].[dateTimeField] column , @ConsiderNull_dateTimeField bit = 0 , at uniqueidentifierField [uniqueidentifier] = Null -- for [a_Table].[uniqueidentifierField] column , @ConsiderNull_uniqueidentifierField bit = 0 , at imageField [image] = Null -- for [a_Table].[imageField] column , @ConsiderNull_imageField bit = 0 ) As Set NoCount On Declare @retValue int If @ConsiderNull_iD Is Null Set @ConsiderNull_iD = 0 If @ConsiderNull_bitField Is Null Set @ConsiderNull_bitField = 0 If @ConsiderNull_intField Is Null Set @ConsiderNull_intField = 0 If @ConsiderNull_decimalField Is Null Set @ConsiderNull_decimalField = 0 If @ConsiderNull_numericField Is Null Set @ConsiderNull_numericField = 0 If @ConsiderNull_floatField Is Null Set @ConsiderNull_floatField = 0 If @ConsiderNull_smallMoneyField Is Null Set @ConsiderNull_smallMoneyField = 0 If @ConsiderNull_charField Is Null Set @ConsiderNull_charField = 0 If @ConsiderNull_varcharField Is Null Set @ConsiderNull_varcharField = 0 If @ConsiderNull_textField Is Null Set @ConsiderNull_textField = 0 If @ConsiderNull_nvarCharField Is Null Set @ConsiderNull_nvarCharField = 0 If @ConsiderNull_ntextField Is Null Set @ConsiderNull_ntextField = 0 If @ConsiderNull_dateTimeField Is Null Set @ConsiderNull_dateTimeField = 0 If @ConsiderNull_uniqueidentifierField Is Null Set @ConsiderNull_uniqueidentifierField = 0 If @ConsiderNull_imageField Is Null Set @ConsiderNull_imageField = 0 Update [dbo].[a_Table] Set [rowId] = Case @ConsiderNull_iD When 0 Then IsNull(@rowId, [rowId]) When 1 Then @rowId End , [bitField] = Case @ConsiderNull_bitField When 0 Then IsNull(@bitField, [bitField]) When 1 Then @bitField End , [intField] = Case @ConsiderNull_intField When 0 Then IsNull(@intField, [intField]) When 1 Then @intField End , [decimalField] = Case @ConsiderNull_decimalField When 0 Then IsNull(@decimalField, [decimalField]) When 1 Then @decimalField End , [numericField] = Case @ConsiderNull_numericField When 0 Then IsNull(@numericField, [numericField]) When 1 Then @numericField End , [floatField] = Case @ConsiderNull_floatField When 0 Then IsNull(@floatField, [floatField]) When 1 Then @floatField End , [smallMoneyField] = Case @ConsiderNull_smallMoneyField When 0 Then IsNull(@smallMoneyField, [smallMoneyField]) When 1 Then @smallMoneyField End , [charField] = Case @ConsiderNull_charField When 0 Then IsNull(@charField, [charField]) When 1 Then @charField End , [varcharField] = Case @ConsiderNull_varcharField When 0 Then IsNull(@varcharField, [varcharField]) When 1 Then @varcharField End , [textField] = Case @ConsiderNull_textField When 0 Then IsNull(@textField, [textField]) When 1 Then @textField End , [nvarCharField] = Case @ConsiderNull_nvarCharField When 0 Then IsNull(@nvarCharField, [nvarCharField]) When 1 Then @nvarCharField End , [ntextField] = Case @ConsiderNull_ntextField When 0 Then IsNull(@ntextField, [ntextField]) When 1 Then @ntextField End , [dateTimeField] = Case @ConsiderNull_dateTimeField When 0 Then IsNull(@dateTimeField, [dateTimeField]) When 1 Then @dateTimeField End , [uniqueidentifierField] = Case @ConsiderNull_uniqueidentifierField When 0 Then IsNull(@uniqueidentifierField, [uniqueidentifierField]) When 1 Then @uniqueidentifierField End , [imageField] = Case @ConsiderNull_imageField When 0 Then IsNull(@imageField, [imageField]) When 1 Then @imageField End Where ([rowId] = @rowId) select @retValue = @@ERROR Set NoCount Off Return(@retValue) GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Monday, July 30, 2007 5:02 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Going CRUD way... Since you wrote this to the AccessD list, I'll begin there with my response. I'm currently doing an ADP for a riding stable (which will soon be for sale, so if any listers have any friends with riding stables... LOL). The general approach in it is forms bound to views. (Nobody but me gets to talk directly to tables.) Some of the views use table-UDFs to simplify joins. All of the combo-boxes and list-boxes use named queries (views) to retrieve their contents. This app is simple, so there's not much need for complicated sprocs, except here and there. These fall mainly in the Reports realm; a dialog box opens, requests parameters such as "Horse", Start Date and End Date, then invokes the report which invokes the sproc and passes the parameters, so you end up with a cross-tab report showing the particular horse's activities ( group lesson, private lesson, sem-private lesson, injury day, etc.) during the date range. In the larger scheme of things, I use ERwin. Its code-gen capabilities are totally wonderful. It has a template language built-in which will generate your CRUD code automatically, and even give you a choice between returning a rowset and a set out OUTPUT parameters. I hadn't realized the benefit of the latter strategy until I worked on a large project with my friend Dejan Sunderic (who wrote a great book about SQL 2005). That type of sproc is useful only when you want exactly one record back, but if you're searching millions of rows, it's demonstrably faster than returning a rowset. You don't even need a timer to note the difference. In Access, there are significant advantages to using views as the data source, IMO, not the least of which is how easily subforms behave. Access does the dirty work for you. You just create a subform based on a view, plonk it onto a master form, and Access handles the plumbing. It couldn't be easier, and in addition you insulate the actual tables. Suppose that your app contains a form that only selected people (let's call them Managers) ought to see. So in SQL you create a Managers role and grant access to the view(s) in question. Then even if you forget to program around it in your Access app, it's ok -- no one but managers will be able to run that report. The message they will receive isn't elegant, but the data is safe. I'm not an ERwin expert but I have worked with one or two. At one point, I asked my friend and colleague Andrei Pascal whether we could customize the template to place what ERwin calls a description into the Extended Properties code. It took Andrei about 5 minutes to modify the template so it did this. That's two "hats off" -- one to the template language and one to Andrei. The template language is pretty much beyond my feeble intellect, but Andrei just whipped out a tiny little loop that walked every table and added an extended property to every table for every column that had a Description, and poof! All done. I used to hate ERwin and I much preferred PowerDesigner and Dezign (whose interface is pretty much a clone of PowerDesigner, although it lacks lots of the PD power). I was dragged kicking and screaming into using ERwin, but have since grown into an enthusiast, not least because generating CRUD and even customized CRUD is a one-click operation. Arthur On 7/30/07, Shamil Salakhetdinov wrote: > > Hi All, > > It looks like we haven't yet have here CRUD vs. (mainly) dynamic > manually written SQL vs. metadata-driven application (frameworks) > development debate? > Or did I miss it? > > Anyway my question is what do you prefer to use when developing > applications against MS SQL backend:? > > - 1) CRUD SPs based approach to work with base tables + custom > SPs(views, > UDFs,...) to implement custom functionality - and SPs only "visible to > outer world"? > > - 2) dynamic SQL - DAO, ADO, ADO.NET (mainly) manually written etc. > with or without SPs (views, UDFs,...)? > > - 3) metadata driven (flexible) dynamic SQL approach? > > - 4) you do not use not the first not the second not the third > approach - you do use a "mixture" of them IOW you just write code to > implement custom functionality and whatever approach to use in every > certain case you usually decide as you go... > > - 5) something else (please add other useful approached I missed to > mention here)... > > Thank you. > > > -- > Shamil > > > > -- > 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 adtp at airtelbroadband.in Tue Jul 31 07:29:29 2007 From: adtp at airtelbroadband.in (A.D.TEJPAL) Date: Tue, 31 Jul 2007 17:59:29 +0530 Subject: [AccessD] Get all controls on all forms References: <586905.71583.qm@web31611.mail.mud.yahoo.com> Message-ID: <005201c7d36e$8ea6d530$7357a27a@pcadt> Sander, Sample subroutine P_ListAllControlsAllForms(), as given below, will populate table named T_AllControls with the names of all forms in the db as well as all controls thereon, along with particulars of ControlType. If any form happens to be blank (no controls), its name will appear against field FormName, leaving the ControlName & ControlType fields blank. Before using this procedure, please make sure that table T_AllControls is available, with fields named FormName (text type), ControlName (text type) and ControlType (number type). Note: This procedure should preferably be run directly from VBA window. If you wish to run it from a test form, the code should be modified suitably so as to prevent opening of that test form. This is because, each form in AllForms collection gets opened turn by turn, in design view. If test form also gets opened in design view, further execution of code will get interrupted. Best wishes, A.D.Tejpal --------------- Sample Subroutine (For listing all forms & their controls) ==================================== Sub P_ListAllControlsAllForms() Dim obj As AccessObject, ct As Control Dim rst As DAO.Recordset Dim FormName As String ' Clear existing contents of table T_AllControls CurrentDb.Execute "DELETE FROM " & _ "T_AllControls;", dbFailOnError Set rst = CurrentDb.OpenRecordset("T_AllControls") For Each obj In CurrentProject.AllForms FormName = obj.Name DoCmd.OpenForm FormName, acDesign If Forms(FormName).Controls.Count > 0 Then For Each ct In Forms(FormName).Controls rst.AddNew With rst.Fields !FormName = FormName !ControlName = ct.Name !ControlType = ct.ControlType End With rst.Update Next Else rst.AddNew rst.Fields("FormName") = FormName rst.Update End If DoCmd.Close acForm, FormName, acSaveNo Next rst.Close Set rst = Nothing Set ct = Nothing Set obj = Nothing End Sub ==================================== ----- Original Message ----- From: Sad Der To: Acces User Group Sent: Monday, July 30, 2007 19:25 Subject: [AccessD] Get all controls on all forms Hi group, Does anybody have piece of code that retrieves all controles on all forms in a database? I need to store these in a database. Thnx! Regards, Sander From rockysmolin at bchacc.com Tue Jul 31 12:07:49 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 31 Jul 2007 10:07:49 -0700 Subject: [AccessD] Calling Subform Routine from Main Form Message-ID: <003e01c7d395$535bc720$0301a8c0@HAL9005> Dear List: I can never remember this syntax: I want to call a sub in a subform from the main form's Current event. Does anyone know this offhand? MTIA Rocky From robert at webedb.com Tue Jul 31 12:14:42 2007 From: robert at webedb.com (Robert L. Stewart) Date: Tue, 31 Jul 2007 12:14:42 -0500 Subject: [AccessD] Going CRUD way... In-Reply-To: References: Message-ID: <200707311720.l6VHKCqK029241@databaseadvisors.com> Michael, The SPs generated by netTiers go beyond a simple CRUD system. They generate a paged get like the first one you listed. But, they also generate a read by each of the foreign keys if you define then in the SQL DB. They are very good and what I use for development in Visual Studio. No, I do not use my CRUD generator for my VS development. It was developed for my day job where the environment is ColdFusion and Access 97. After doing ,Net development for the last 3 years, I finally found Codesmith and netTiers and will probably never write another data layer of my own again. I see no reason to reinvent the wheel when there is one that works so well already. Robert At 12:00 PM 7/31/2007, you wrote: >Date: Tue, 31 Jul 2007 16:33:46 +1000 >From: "Michael Maddison" >Subject: Re: [AccessD] Going CRUD way... >To: "Access Developers discussion and problem solving" > >Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D01289B43 at ddi-01.DDI.local> >Content-Type: text/plain; charset="us-ascii" > >Hi Guys, > >Heres a sample of the CRUD generated by NetTiers an a simple lookup >table. >I've used a couple of times now. >Of course it also generates all the C# objects to go with it. > >IMO for complex systems CRUD makes good sense. From rockysmolin at bchacc.com Tue Jul 31 13:08:02 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 31 Jul 2007 11:08:02 -0700 Subject: [AccessD] Calling Subform Routine from Main Form In-Reply-To: <003e01c7d395$535bc720$0301a8c0@HAL9005> Message-ID: <004b01c7d39d$bd4413b0$0301a8c0@HAL9005> Think I got it. Had to make the routing in the subform Public. And then: Call Me.Child293.Form.UpdateFilter Seems to work. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Tuesday, July 31, 2007 10:08 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Calling Subform Routine from Main Form Dear List: I can never remember this syntax: I want to call a sub in a subform from the main form's Current event. Does anyone know this offhand? MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM From Lambert.Heenan at AIG.com Tue Jul 31 13:11:49 2007 From: Lambert.Heenan at AIG.com (Heenan, Lambert) Date: Tue, 31 Jul 2007 13:11:49 -0500 Subject: [AccessD] Calling Subform Routine from Main Form Message-ID: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6D33@xlivmbx35.aig.com> Your it call from the main form with.. Me.SubformControlName.Form.RoutineName If you want to call the routine from any place other than the subform or its parent form then the routine needs to be made Public and you would call it with... Forms("MainFomrName").SubformControlName.Form.RoutineName HTH Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Tuesday, July 31, 2007 1:08 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Calling Subform Routine from Main Form Dear List: I can never remember this syntax: I want to call a sub in a subform from the main form's Current event. Does anyone know this offhand? MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Tue Jul 31 18:05:40 2007 From: rockysmolin at bchacc.com (Rocky Smolin at Beach Access Software) Date: Tue, 31 Jul 2007 16:05:40 -0700 Subject: [AccessD] Calling Subform Routine from Main Form In-Reply-To: <34C8A2AB1EF3564CB0D64DB6AFFDD5C208ED6D33@xlivmbx35.aig.com> Message-ID: <007701c7d3c7$50f11d00$0301a8c0@HAL9005> Thanks Lambert. That works. I just can't remember how to do it from time to time. Old age I guess... Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Tuesday, July 31, 2007 11:12 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Calling Subform Routine from Main Form Your it call from the main form with.. Me.SubformControlName.Form.RoutineName If you want to call the routine from any place other than the subform or its parent form then the routine needs to be made Public and you would call it with... Forms("MainFomrName").SubformControlName.Form.RoutineName HTH Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Tuesday, July 31, 2007 1:08 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Calling Subform Routine from Main Form Dear List: I can never remember this syntax: I want to call a sub in a subform from the main form's Current event. Does anyone know this offhand? MTIA Rocky -- 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 incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM From jwcolby at colbyconsulting.com Tue Jul 31 21:46:48 2007 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 31 Jul 2007 22:46:48 -0400 Subject: [AccessD] Hamachi on the road Message-ID: <20070801024649.DBE60BD3B@smtp-auth.no-ip.com> I set up Hamachi on my three servers before I left home, as well as my laptop which I have with me. I bought the pay version, one month license, for each server. That basically gives me the ability to load it as a service which is not available with the free version. Tonight I am in a hotel with "high speed internet" and I can see all of the shares on all of my servers, right over the Hamachi link. I can also remote desktop in to all three machines over the Hamachi IP address. COOL stuff. John W. Colby Colby Consulting www.ColbyConsulting.com From darrend at nimble.com.au Tue Jul 31 22:22:21 2007 From: darrend at nimble.com.au (Darren D) Date: Wed, 1 Aug 2007 13:22:21 +1000 Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files In-Reply-To: Message-ID: <200708010322.l713MKjY019538@databaseadvisors.com> Hi Gustav et al The COPY /B worked Donald the Type >> line is excellent - I can see a use for this already Many thanks to those who responded The final syntax was... COPY /B Header.txt + *.xml + Footer.txt MyAyCoolAndWayBig.XML Thanks DD -----Original Message----- From: Gustav Brock [mailto:gustav at cactus.dk] Sent: Tuesday, 31 July 2007 7:59 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Kinda OT:A2003 Calling a batch file - merging files Hi Darren Try with COPY /B, that should remove the EOF byte. /gustav >>> martyconnelly at shaw.ca 30-07-07 20:19 >>> Could be a couple of things, I haven't got an Ascii Table handy Have a look at last char in HexEditor. At a guess it could CTRL-Z which is an old DOS EOF McGillivray, Don [IT] wrote: >Darren, > >I've done something similar by redirecting the output of the DOS "type" command to a file. I've never had an issue with extraneous characters using this method. Something like this: > >Type *.fil >> BigFile.txt > >This concatenates the contents of all files with the extension "fil" into a single file called BigFile.txt. Don't know if the order of concatenation is predictable, if that's important to you. > >As for inserting text between additions or at either end, I think you can redirect the DOS "echo" command in a similar way. Something like: > >Echo "Start of file" >> BigFile.txt >Type *.fil >> BigFile.txt >Echo "End of file" >> BigFile.txt > >Hope this helps . . . > >Don > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren D >Sent: Sunday, July 29, 2007 4:30 PM >To: 'Access Developers discussion and problem solving' >Subject: [AccessD] Kinda OT:A2003 Calling a batch file - merging files > >Hi all > > > >I am calling a batch file from my access app > > > >The batch file just 'merges' a few files into one big file and then gives it a >name > > > >This is the batch file - Very basic - 1 liner - > > > >copy FirstFile.txt + C:\SomeFolder\*.xml + Secondfile.txt >mynewcoolcombinedfile.XML > > > >Pretty basic - but the combining leaves a small ascii type square as the very >very last character - Like this ---> > > > >Anyone know how to stop this from happening? > > > >Or even better - How to 'build' or merge a few files into one big file - from >VBA > > > >Or even better still - How to insert Text eg Merge > > > >"This is the start of the file" + C:\SomeFolder\*.XML + "This is the end" into >OneCoolFile.XML > > > >Many thanks in advance > > > >DD -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bhjohnson at verizon.net Tue Jul 31 23:40:09 2007 From: bhjohnson at verizon.net (Bruce H. Johnson) Date: Tue, 31 Jul 2007 21:40:09 -0700 Subject: [AccessD] Hamachi on the road In-Reply-To: <20070801024649.DBE60BD3B@smtp-auth.no-ip.com> References: <20070801024649.DBE60BD3B@smtp-auth.no-ip.com> Message-ID: <005701c7d3f6$0afa9b80$0201a8c0@HALSR> I've had decent results with Hamachi over the Internet. As well, I use the free versions of LogMeIn (logmein.com). With Hamachi seeming to be part of LogMeIn (it's on the web site), I can do a remote control of my home system from pretty much any Internet connection. If I need a file or so, I can either email it (free version of LogMeIn doesn't have file xfer) or fire up Hamachi on both ends. It's worked well for me, too. Bruce H. Johnson Sylmar, CA -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, July 31, 2007 7:47 PM To: 'Access Developers discussion and problem solving'; 'Discussion of Hardware and Software issues' Subject: [AccessD] Hamachi on the road I set up Hamachi on my three servers before I left home, as well as my laptop which I have with me. I bought the pay version, one month license, for each server. That basically gives me the ability to load it as a service which is not available with the free version. Tonight I am in a hotel with "high speed internet" and I can see all of the shares on all of my servers, right over the Hamachi link. I can also remote desktop in to all three machines over the Hamachi IP address. COOL stuff. John W. Colby Colby Consulting www.ColbyConsulting.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date: 7/30/2007 5:02 PM