From newsgrps at dalyn.co.nz Fri May 1 22:04:16 2015 From: newsgrps at dalyn.co.nz (David Emerson) Date: Sat, 2 May 2015 15:04:16 +1200 Subject: [AccessD] Consolidating two sets of values Message-ID: <001501d08484$ad249630$076dc290$@dalyn.co.nz> Hi Listers, I am having a brain freeze at the moment. I have a table with three fields: Employee, Date, Sales. Up to now the client wanted the total for each employee. No problem: SELECT tblSales.Employee, Sum(tblSales.Sales) AS SumOfSales FROM tblSales GROUP BY tblSales.Employee; Now the client wants the same except he wants two employee figures to be combined into one figure. For example Results of current query: Bob $5000 Jim $2000 Joe $1000 Lee $8000 Now let's say that Bob and Jim are to be combined as Gen. The results are now to be: Gen $7000 Joe $1000 Lee $8000 What is the syntax I should use? Regards David Emerson Dalyn Software Ltd Wellington, New Zealand From jackandpat.d at gmail.com Fri May 1 22:43:38 2015 From: jackandpat.d at gmail.com (jack drawbridge) Date: Fri, 1 May 2015 23:43:38 -0400 Subject: [AccessD] Consolidating two sets of values In-Reply-To: <001501d08484$ad249630$076dc290$@dalyn.co.nz> References: <001501d08484$ad249630$076dc290$@dalyn.co.nz> Message-ID: David; Small sample based on your data: Select Names, sumofsales from ( SELECT IIf(Empname="Bob" Or EmpName="Jim","GEN",empname) AS Names, Sum(tblSales.Sales) AS SumOfSales FROM tblSales GROUP BY IIf(Empname="Bob" Or EmpName="Jim","GEN",empname) ) Gives result: *Query3* Names sumofsales GEN $7,000.00 Joe $1,000.00 Lee $8,000.00 Good luck. On Fri, May 1, 2015 at 11:04 PM, David Emerson wrote: > Hi Listers, > > > > I am having a brain freeze at the moment. I have a table with three > fields: > Employee, Date, Sales. > > > > Up to now the client wanted the total for each employee. No problem: > > > > SELECT tblSales.Employee, Sum(tblSales.Sales) AS SumOfSales > > FROM tblSales > > GROUP BY tblSales.Employee; > > > > Now the client wants the same except he wants two employee figures to be > combined into one figure. For example > > > > Results of current query: > > > > Bob $5000 > > Jim $2000 > > Joe $1000 > > Lee $8000 > > > > Now let's say that Bob and Jim are to be combined as Gen. The results are > now to be: > > > > Gen $7000 > > Joe $1000 > > Lee $8000 > > > > What is the syntax I should use? > > > > Regards > > David Emerson > Dalyn Software Ltd > Wellington, New Zealand > > > > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From paul.hartland at googlemail.com Sat May 2 00:05:53 2015 From: paul.hartland at googlemail.com (Paul Hartland) Date: Sat, 2 May 2015 06:05:53 +0100 Subject: [AccessD] Consolidating two sets of values In-Reply-To: References: <001501d08484$ad249630$076dc290$@dalyn.co.nz> Message-ID: couple of ways you can do this, you can use the IIF as previously said but the problem comes where you require a lot of names to be joined, or you can add an additional field to the employee table and put a code in there Name JoinCode Bob GEN Jim GEN Joe JOE Lee LEE and run the query based on the JoinCode (or whatever you call it field) On 2 May 2015 at 04:43, jack drawbridge wrote: > David; > > Small sample based on your data: > > Select Names, sumofsales from > ( > SELECT IIf(Empname="Bob" Or EmpName="Jim","GEN",empname) AS Names, > Sum(tblSales.Sales) AS SumOfSales > FROM tblSales > GROUP BY IIf(Empname="Bob" Or EmpName="Jim","GEN",empname) > ) > > Gives result: > > *Query3* Names sumofsales GEN $7,000.00 Joe $1,000.00 Lee $8,000.00 > > Good luck. > > On Fri, May 1, 2015 at 11:04 PM, David Emerson > wrote: > > > Hi Listers, > > > > > > > > I am having a brain freeze at the moment. I have a table with three > > fields: > > Employee, Date, Sales. > > > > > > > > Up to now the client wanted the total for each employee. No problem: > > > > > > > > SELECT tblSales.Employee, Sum(tblSales.Sales) AS SumOfSales > > > > FROM tblSales > > > > GROUP BY tblSales.Employee; > > > > > > > > Now the client wants the same except he wants two employee figures to be > > combined into one figure. For example > > > > > > > > Results of current query: > > > > > > > > Bob $5000 > > > > Jim $2000 > > > > Joe $1000 > > > > Lee $8000 > > > > > > > > Now let's say that Bob and Jim are to be combined as Gen. The results > are > > now to be: > > > > > > > > Gen $7000 > > > > Joe $1000 > > > > Lee $8000 > > > > > > > > What is the syntax I should use? > > > > > > > > Regards > > > > David Emerson > > Dalyn Software Ltd > > Wellington, New Zealand > > > > > > > > > > > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- Paul Hartland paul.hartland at googlemail.com From newsgrps at dalyn.co.nz Sat May 2 00:36:53 2015 From: newsgrps at dalyn.co.nz (David Emerson) Date: Sat, 2 May 2015 17:36:53 +1200 Subject: [AccessD] Consolidating two sets of values In-Reply-To: References: <001501d08484$ad249630$076dc290$@dalyn.co.nz> Message-ID: <000c01d08499$ffad13e0$ff073ba0$@dalyn.co.nz> Thanks Jack and Paul. Much appreciated. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Paul Hartland Sent: Saturday, 2 May 2015 5:06 p.m. To: Access Developers discussion and problem solving Subject: Re: [AccessD] Consolidating two sets of values couple of ways you can do this, you can use the IIF as previously said but the problem comes where you require a lot of names to be joined, or you can add an additional field to the employee table and put a code in there Name JoinCode Bob GEN Jim GEN Joe JOE Lee LEE and run the query based on the JoinCode (or whatever you call it field) On 2 May 2015 at 04:43, jack drawbridge wrote: > David; > > Small sample based on your data: > > Select Names, sumofsales from > ( > SELECT IIf(Empname="Bob" Or EmpName="Jim","GEN",empname) AS Names, > Sum(tblSales.Sales) AS SumOfSales > FROM tblSales > GROUP BY IIf(Empname="Bob" Or EmpName="Jim","GEN",empname) > ) > > Gives result: > > *Query3* Names sumofsales GEN $7,000.00 Joe $1,000.00 Lee $8,000.00 > > Good luck. > > On Fri, May 1, 2015 at 11:04 PM, David Emerson > wrote: > > > Hi Listers, > > > > > > > > I am having a brain freeze at the moment. I have a table with three > > fields: > > Employee, Date, Sales. > > > > > > > > Up to now the client wanted the total for each employee. No problem: > > > > > > > > SELECT tblSales.Employee, Sum(tblSales.Sales) AS SumOfSales > > > > FROM tblSales > > > > GROUP BY tblSales.Employee; > > > > > > > > Now the client wants the same except he wants two employee figures > > to be combined into one figure. For example > > > > > > > > Results of current query: > > > > > > > > Bob $5000 > > > > Jim $2000 > > > > Joe $1000 > > > > Lee $8000 > > > > > > > > Now let's say that Bob and Jim are to be combined as Gen. The > > results > are > > now to be: > > > > > > > > Gen $7000 > > > > Joe $1000 > > > > Lee $8000 > > > > > > > > What is the syntax I should use? > > > > > > > > Regards > > > > David Emerson > > Dalyn Software Ltd > > Wellington, New Zealand > > > > > > > > > > > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- Paul Hartland paul.hartland at googlemail.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From gustav at cactus.dk Sat May 2 03:53:05 2015 From: gustav at cactus.dk (Gustav Brock) Date: Sat, 2 May 2015 08:53:05 +0000 Subject: [AccessD] Office 365 Developer Program Message-ID: <1430556784643.88552@cactus.dk> Hi all Here you can have a one-year free (test) account for Office365: https://dev.office.com/devprogram and, of course, lots of info on how to interoperate between Office365 and your applications. /gustav From gustav at cactus.dk Sat May 2 04:10:21 2015 From: gustav at cactus.dk (Gustav Brock) Date: Sat, 2 May 2015 09:10:21 +0000 Subject: [AccessD] Office 365 Developer Program In-Reply-To: <1430556784643.88552@cactus.dk> References: <1430556784643.88552@cactus.dk> Message-ID: <1430557820914.37632@cactus.dk> Hi all The VBA reference is here: https://msdn.microsoft.com/en-us/library/office/gg264383(v=office.15).aspx /gustav ________________________________________ Fra: AccessD p? vegne af Gustav Brock Sendt: 2. maj 2015 10:53 Til: Access Developers discussion and problem solving Emne: [AccessD] Office 365 Developer Program Hi all Here you can have a one-year free (test) account for Office365: https://dev.office.com/devprogram and, of course, lots of info on how to interoperate between Office365 and your applications. /gustav From gustav at cactus.dk Sat May 2 04:32:23 2015 From: gustav at cactus.dk (Gustav Brock) Date: Sat, 2 May 2015 09:32:23 +0000 Subject: [AccessD] Office 365 Developer Program In-Reply-To: <1430557820914.37632@cactus.dk> References: <1430556784643.88552@cactus.dk>,<1430557820914.37632@cactus.dk> Message-ID: <1430559142934.86697@cactus.dk> Sorry, that link is for the general VBA reference - nothing specific for Office365. /gustav ________________________________________ Fra: AccessD p? vegne af Gustav Brock Sendt: 2. maj 2015 11:10 Til: Access Developers discussion and problem solving Emne: Re: [AccessD] Office 365 Developer Program Hi all The VBA reference is here: https://msdn.microsoft.com/en-us/library/office/gg264383(v=office.15).aspx /gustav From ssharkins at gmail.com Sat May 2 07:35:11 2015 From: ssharkins at gmail.com (Susan Harkins) Date: Sat, 2 May 2015 08:35:11 -0400 Subject: [AccessD] Office 365 Developer Program In-Reply-To: <1430559142934.86697@cactus.dk> References: <1430556784643.88552@cactus.dk> <1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> Message-ID: Is anyone actually working on any 365 development? Susan H. On Sat, May 2, 2015 at 5:32 AM, Gustav Brock wrote: > Sorry, that link is for the general VBA reference - nothing specific for > Office365. > > /gustav > > ________________________________________ > Fra: AccessD p? vegne af Gustav > Brock > Sendt: 2. maj 2015 11:10 > Til: Access Developers discussion and problem solving > Emne: Re: [AccessD] Office 365 Developer Program > > Hi all > > The VBA reference is here: > > > https://msdn.microsoft.com/en-us/library/office/gg264383(v=office.15).aspx > > /gustav > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From accessd at shaw.ca Sun May 3 17:25:31 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Sun, 3 May 2015 16:25:31 -0600 (MDT) Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: Message-ID: <1934826082.66137556.1430691931396.JavaMail.root@shaw.ca> One comment Brad. Things may have changed since a decade ago but I have found that improvement in MS Access tend not to progress too rapidly. My one recommendation is to not embed pictures within the application just call any images from their own directory as necessary. Jim ----- Original Message ----- From: "Brad Marks" To: "Access Developers discussion and problem solving" Sent: Thursday, April 30, 2015 11:48:04 AM Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 All, We have a purchased accounting package called Sage Business Works. Pictures of products are stored in the Business Works database (Pervasive). >From the product documentation I see a field named "Image". When I connect to the Parts table, with Access, I can run a query which shows the Image field as "OLE object". All of the other fields are shown (text fields, numeric fields) I have never worked with images before. I would like to be able to display these images with an Access form or report. I have done a number of experiments, but I have not been able to see the images with either an Access form or report. I must be missing something. Any help would be appreciated. Thanks, Brad -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From marksimms at verizon.net Sun May 3 20:25:11 2015 From: marksimms at verizon.net (Mark Simms) Date: Sun, 03 May 2015 21:25:11 -0400 Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: <1934826082.66137556.1430691931396.JavaMail.root@shaw.ca> References: <1934826082.66137556.1430691931396.JavaMail.root@shaw.ca> Message-ID: <070901d08609$2a7458c0$7f5d0a40$@net> Re: " improvement in MS Access tend not to progress too rapidly." This may be the understatement of the century. Examples: 1) SQL in queries don't retain their original format. Any large query quickly becomes a indecipherable string of letters. 2) no comments permitted in the SQL of a query. Why did I do this GROUP BY again ? This has to be intentional. > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of Jim Lawrence > Sent: Sunday, May 03, 2015 6:26 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] How To Display an Image from a Pervasive > Database table Via Access 2007 > > One comment Brad. Things may have changed since a decade ago but I have > found that improvement in MS Access tend not to progress too rapidly. > My one recommendation is to not embed pictures within the application > just call any images from their own directory as necessary. > > Jim > > ----- Original Message ----- > From: "Brad Marks" > To: "Access Developers discussion and problem solving" > > Sent: Thursday, April 30, 2015 11:48:04 AM > Subject: [AccessD] How To Display an Image from a Pervasive Database > table Via Access 2007 > > All, > > We have a purchased accounting package called Sage Business Works. > > Pictures of products are stored in the Business Works database > (Pervasive). > > From the product documentation I see a field named "Image". > > When I connect to the Parts table, with Access, I can run a query which > shows the Image field as "OLE object". All of the other fields are > shown (text fields, numeric fields) > > I have never worked with images before. I would like to be able to > display these images with an Access form or report. > > I have done a number of experiments, but I have not been able to see > the images with either an Access form or report. > > I must be missing something. > > Any help would be appreciated. > > Thanks, > > Brad > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From marksimms at verizon.net Sun May 3 20:30:40 2015 From: marksimms at verizon.net (Mark Simms) Date: Sun, 03 May 2015 21:30:40 -0400 Subject: [AccessD] Office 365 Developer Program In-Reply-To: <1430559142934.86697@cactus.dk> References: <1430556784643.88552@cactus.dk>,<1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> Message-ID: <070a01d08609$eea34710$cbe9d530$@net> Gang - as I had mentioned "many moons" ago, the huge, HUGE issues are: 1) porting existing Excel, Word, Access VBA to Office 365 apps 2) having the same (or very similar) object models in Office 365 as existed in regular Office. The programming language can change (i.e. Javascript, even better: Typescript)... But 1 and 2 above are "must haves". Obviously, but not surprisingly, nothing related to the above got accomplished under Balmer. Can the new CEO deliver this ? > > Sorry, that link is for the general VBA reference - nothing specific > for Office365. > > /gustav From bradm at blackforestltd.com Sun May 3 21:33:40 2015 From: bradm at blackforestltd.com (Brad Marks) Date: Mon, 4 May 2015 02:33:40 +0000 Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: <1934826082.66137556.1430691931396.JavaMail.root@shaw.ca> References: , <1934826082.66137556.1430691931396.JavaMail.root@shaw.ca> Message-ID: <1430706820829.63051@blackforestltd.com> Jim, Thanks for your input on this problem. I agree with you. If the pictures were stored in their own folder, I would not be running into this problem. The catch is that I am trying to pull pictures that are stored in a database that is part of a purchased accounting package. When this accounting system was installed, there was not an option as to where the pictures are stored. We had to use the system as delivered. Therefore the pictures are stored in the database. I have many queries that pull data via ODBC from this database. These all work nicely. When I add the image field to one of these queries, I see "OLE" when I run the query. However, when I try to view the picture with an Access report or form, nothing is shown. I wonder if I need to add some additional software to view images via Access 2007 reports or forms. Brad ________________________________________ From: AccessD on behalf of Jim Lawrence Sent: Sunday, May 3, 2015 5:25 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 One comment Brad. Things may have changed since a decade ago but I have found that improvement in MS Access tend not to progress too rapidly. My one recommendation is to not embed pictures within the application just call any images from their own directory as necessary. Jim ----- Original Message ----- From: "Brad Marks" To: "Access Developers discussion and problem solving" Sent: Thursday, April 30, 2015 11:48:04 AM Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 All, We have a purchased accounting package called Sage Business Works. Pictures of products are stored in the Business Works database (Pervasive). >From the product documentation I see a field named "Image". When I connect to the Parts table, with Access, I can run a query which shows the Image field as "OLE object". All of the other fields are shown (text fields, numeric fields) I have never worked with images before. I would like to be able to display these images with an Access form or report. I have done a number of experiments, but I have not been able to see the images with either an Access form or report. I must be missing something. Any help would be appreciated. Thanks, Brad -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From dbdoug at gmail.com Sun May 3 21:34:01 2015 From: dbdoug at gmail.com (Doug Steele) Date: Sun, 3 May 2015 19:34:01 -0700 Subject: [AccessD] Office 365 Developer Program In-Reply-To: <070a01d08609$eea34710$cbe9d530$@net> References: <1430556784643.88552@cactus.dk> <1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> <070a01d08609$eea34710$cbe9d530$@net> Message-ID: I have one client who, without mentioning it to me, subscribed to Office 365 on a couple of his machines running their Access 2003 database. So far, after my initial heart stoppage, no problem... On Sun, May 3, 2015 at 6:30 PM, Mark Simms wrote: > Gang - as I had mentioned "many moons" ago, the huge, HUGE issues are: > > 1) porting existing Excel, Word, Access VBA to Office 365 apps > > 2) having the same (or very similar) object models in Office 365 as existed > in regular Office. > > The programming language can change (i.e. Javascript, even better: > Typescript)... > > But 1 and 2 above are "must haves". > > Obviously, but not surprisingly, nothing related to the above got > accomplished under Balmer. > Can the new CEO deliver this ? > > > > > Sorry, that link is for the general VBA reference - nothing specific > > for Office365. > > > > /gustav > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From accessd at shaw.ca Mon May 4 06:33:20 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Mon, 4 May 2015 05:33:20 -0600 (MDT) Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: <070901d08609$2a7458c0$7f5d0a40$@net> Message-ID: <908215625.66371055.1430739200129.JavaMail.root@shaw.ca> Ouch. Jim ----- Original Message ----- From: "Mark Simms" To: "Access Developers discussion and problem solving" Sent: Sunday, May 3, 2015 6:25:11 PM Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 Re: " improvement in MS Access tend not to progress too rapidly." This may be the understatement of the century. Examples: 1) SQL in queries don't retain their original format. Any large query quickly becomes a indecipherable string of letters. 2) no comments permitted in the SQL of a query. Why did I do this GROUP BY again ? This has to be intentional. > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of Jim Lawrence > Sent: Sunday, May 03, 2015 6:26 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] How To Display an Image from a Pervasive > Database table Via Access 2007 > > One comment Brad. Things may have changed since a decade ago but I have > found that improvement in MS Access tend not to progress too rapidly. > My one recommendation is to not embed pictures within the application > just call any images from their own directory as necessary. > > Jim > > ----- Original Message ----- > From: "Brad Marks" > To: "Access Developers discussion and problem solving" > > Sent: Thursday, April 30, 2015 11:48:04 AM > Subject: [AccessD] How To Display an Image from a Pervasive Database > table Via Access 2007 > > All, > > We have a purchased accounting package called Sage Business Works. > > Pictures of products are stored in the Business Works database > (Pervasive). > > From the product documentation I see a field named "Image". > > When I connect to the Parts table, with Access, I can run a query which > shows the Image field as "OLE object". All of the other fields are > shown (text fields, numeric fields) > > I have never worked with images before. I would like to be able to > display these images with an Access form or report. > > I have done a number of experiments, but I have not been able to see > the images with either an Access form or report. > > I must be missing something. > > Any help would be appreciated. > > Thanks, > > Brad > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Mon May 4 06:51:29 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Mon, 4 May 2015 05:51:29 -0600 (MDT) Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: <1430706820829.63051@blackforestltd.com> Message-ID: <1131653334.66378033.1430740289867.JavaMail.root@shaw.ca> Hi Brad: You have got me on that one... I am sure there is a simple trick to it. Jim ----- Original Message ----- From: "Brad Marks" To: "Access Developers discussion and problem solving" Sent: Sunday, May 3, 2015 7:33:40 PM Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 Jim, Thanks for your input on this problem. I agree with you. If the pictures were stored in their own folder, I would not be running into this problem. The catch is that I am trying to pull pictures that are stored in a database that is part of a purchased accounting package. When this accounting system was installed, there was not an option as to where the pictures are stored. We had to use the system as delivered. Therefore the pictures are stored in the database. I have many queries that pull data via ODBC from this database. These all work nicely. When I add the image field to one of these queries, I see "OLE" when I run the query. However, when I try to view the picture with an Access report or form, nothing is shown. I wonder if I need to add some additional software to view images via Access 2007 reports or forms. Brad ________________________________________ From: AccessD on behalf of Jim Lawrence Sent: Sunday, May 3, 2015 5:25 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 One comment Brad. Things may have changed since a decade ago but I have found that improvement in MS Access tend not to progress too rapidly. My one recommendation is to not embed pictures within the application just call any images from their own directory as necessary. Jim ----- Original Message ----- From: "Brad Marks" To: "Access Developers discussion and problem solving" Sent: Thursday, April 30, 2015 11:48:04 AM Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 All, We have a purchased accounting package called Sage Business Works. Pictures of products are stored in the Business Works database (Pervasive). >From the product documentation I see a field named "Image". When I connect to the Parts table, with Access, I can run a query which shows the Image field as "OLE object". All of the other fields are shown (text fields, numeric fields) I have never worked with images before. I would like to be able to display these images with an Access form or report. I have done a number of experiments, but I have not been able to see the images with either an Access form or report. I must be missing something. Any help would be appreciated. Thanks, Brad -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bensonforums at gmail.com Mon May 4 16:59:08 2015 From: bensonforums at gmail.com (Bill Benson) Date: Mon, 4 May 2015 17:59:08 -0400 Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: <908215625.66371055.1430739200129.JavaMail.root@shaw.ca> References: <070901d08609$2a7458c0$7f5d0a40$@net> <908215625.66371055.1430739200129.JavaMail.root@shaw.ca> Message-ID: Someone showed me an SQL editor that they pasted code into and it showed up much better than in the Access SQL window. I wish I knew what that was, I am sure it was a common editor many people use. Doesn't prevent Access from messing with it afterward of course. On Mon, May 4, 2015 at 7:33 AM, Jim Lawrence wrote: > Ouch. > > Jim > > ----- Original Message ----- > From: "Mark Simms" > To: "Access Developers discussion and problem solving" < > accessd at databaseadvisors.com> > Sent: Sunday, May 3, 2015 6:25:11 PM > Subject: Re: [AccessD] How To Display an Image from a Pervasive Database > table Via Access 2007 > > Re: " improvement in MS Access tend not to progress too rapidly." > This may be the understatement of the century. > Examples: > 1) SQL in queries don't retain their original format. > Any large query quickly becomes a indecipherable string of letters. > 2) no comments permitted in the SQL of a query. > Why did I do this GROUP BY again ? > > This has to be intentional. > > > -----Original Message----- > > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > > Of Jim Lawrence > > Sent: Sunday, May 03, 2015 6:26 PM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] How To Display an Image from a Pervasive > > Database table Via Access 2007 > > > > One comment Brad. Things may have changed since a decade ago but I have > > found that improvement in MS Access tend not to progress too rapidly. > > My one recommendation is to not embed pictures within the application > > just call any images from their own directory as necessary. > > > > Jim > > > > ----- Original Message ----- > > From: "Brad Marks" > > To: "Access Developers discussion and problem solving" > > > > Sent: Thursday, April 30, 2015 11:48:04 AM > > Subject: [AccessD] How To Display an Image from a Pervasive Database > > table Via Access 2007 > > > > All, > > > > We have a purchased accounting package called Sage Business Works. > > > > Pictures of products are stored in the Business Works database > > (Pervasive). > > > > From the product documentation I see a field named "Image". > > > > When I connect to the Parts table, with Access, I can run a query which > > shows the Image field as "OLE object". All of the other fields are > > shown (text fields, numeric fields) > > > > I have never worked with images before. I would like to be able to > > display these images with an Access form or report. > > > > I have done a number of experiments, but I have not been able to see > > the images with either an Access form or report. > > > > I must be missing something. > > > > Any help would be appreciated. > > > > Thanks, > > > > Brad > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From charlotte.foust at gmail.com Mon May 4 17:54:07 2015 From: charlotte.foust at gmail.com (Charlotte Foust) Date: Mon, 4 May 2015 15:54:07 -0700 Subject: [AccessD] Office 365 Developer Program In-Reply-To: <070a01d08609$eea34710$cbe9d530$@net> References: <1430556784643.88552@cactus.dk> <1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> <070a01d08609$eea34710$cbe9d530$@net> Message-ID: Mark, I don't see those huge issues. VBA works the same in Office 365 as it does in Office locally installed. I have both and there is no difference. What is your exact experience, because it doesn't jibe with mine. Charlotte Foust (916) 206-4336 On Sun, May 3, 2015 at 6:30 PM, Mark Simms wrote: > Gang - as I had mentioned "many moons" ago, the huge, HUGE issues are: > > 1) porting existing Excel, Word, Access VBA to Office 365 apps > > 2) having the same (or very similar) object models in Office 365 as existed > in regular Office. > > The programming language can change (i.e. Javascript, even better: > Typescript)... > > But 1 and 2 above are "must haves". > > Obviously, but not surprisingly, nothing related to the above got > accomplished under Balmer. > Can the new CEO deliver this ? > > > > > Sorry, that link is for the general VBA reference - nothing specific > > for Office365. > > > > /gustav > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From marksimms at verizon.net Mon May 4 19:33:13 2015 From: marksimms at verizon.net (Mark Simms) Date: Mon, 04 May 2015 20:33:13 -0400 Subject: [AccessD] Office 365 Developer Program In-Reply-To: References: <1430556784643.88552@cactus.dk> <1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> <070a01d08609$eea34710$cbe9d530$@net> Message-ID: <00f001d086cb$12cde1b0$3869a510$@net> Interesting. It supports accda (addins) as well ? That's huge IMHO. First thing I noticed: once an Excel file is beyond a certain size, Office 365 forces it to open with a local copy of Excel. That told me: limitations abound. Are XLAM's (Excel addins) supported ? > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of Charlotte Foust > Sent: Monday, May 04, 2015 6:54 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Office 365 Developer Program > > Mark, > > I don't see those huge issues. VBA works the same in Office 365 as it > does > in Office locally installed. I have both and there is no difference. > What > is your exact experience, because it doesn't jibe with mine. > > Charlotte Foust > (916) 206-4336 > > On Sun, May 3, 2015 at 6:30 PM, Mark Simms > wrote: > > > Gang - as I had mentioned "many moons" ago, the huge, HUGE issues > are: > > > > 1) porting existing Excel, Word, Access VBA to Office 365 apps > > > > 2) having the same (or very similar) object models in Office 365 as > existed > > in regular Office. > > > > The programming language can change (i.e. Javascript, even better: > > Typescript)... > > > > But 1 and 2 above are "must haves". > > > > Obviously, but not surprisingly, nothing related to the above got > > accomplished under Balmer. > > Can the new CEO deliver this ? > > > > > > > > Sorry, that link is for the general VBA reference - nothing > specific > > > for Office365. > > > > > > /gustav > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com From darryl at whittleconsulting.com.au Mon May 4 20:19:40 2015 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Tue, 5 May 2015 01:19:40 +0000 Subject: [AccessD] Office 365 Developer Program In-Reply-To: References: <1430556784643.88552@cactus.dk> <1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> <070a01d08609$eea34710$cbe9d530$@net> Message-ID: I have said this a few times before. You have to compare 'apples to apples' here folks. What I call and consider to be 'Office 365' might be very different to your 'Office 365' option and user experience. See <> for a decent summary of plans and options. There is also a big variance in functionality between the online apps and their much more powerful desktop parents. Assuming you are using a plan that allows for Desktop application you will be fine. Otherwise 'Here be Dragons....' Regards Darryl. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Tuesday, 5 May 2015 8:54 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Office 365 Developer Program Mark, I don't see those huge issues. VBA works the same in Office 365 as it does in Office locally installed. I have both and there is no difference. What is your exact experience, because it doesn't jibe with mine. Charlotte Foust (916) 206-4336 On Sun, May 3, 2015 at 6:30 PM, Mark Simms wrote: > Gang - as I had mentioned "many moons" ago, the huge, HUGE issues are: > > 1) porting existing Excel, Word, Access VBA to Office 365 apps > > 2) having the same (or very similar) object models in Office 365 as > existed in regular Office. > > The programming language can change (i.e. Javascript, even better: > Typescript)... > > But 1 and 2 above are "must haves". > > Obviously, but not surprisingly, nothing related to the above got > accomplished under Balmer. > Can the new CEO deliver this ? > > > > > Sorry, that link is for the general VBA reference - nothing specific > > for Office365. > > > > /gustav > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > 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 May 5 02:09:31 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 5 May 2015 01:09:31 -0600 (MDT) Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: Message-ID: <1153088320.67195219.1430809771306.JavaMail.root@shaw.ca> Hi Bill: There are some great little editors out there. Some with all types of features and either free or very reasonably priced http://www.elegantthemes.com/blog/resources/the-11-best-code-editors-available-in-2015 Jim ----- Original Message ----- From: "Bill Benson" To: "Access Developers discussion and problem solving" Sent: Monday, May 4, 2015 2:59:08 PM Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 Someone showed me an SQL editor that they pasted code into and it showed up much better than in the Access SQL window. I wish I knew what that was, I am sure it was a common editor many people use. Doesn't prevent Access from messing with it afterward of course. On Mon, May 4, 2015 at 7:33 AM, Jim Lawrence wrote: > Ouch. > > Jim > > ----- Original Message ----- > From: "Mark Simms" > To: "Access Developers discussion and problem solving" < > accessd at databaseadvisors.com> > Sent: Sunday, May 3, 2015 6:25:11 PM > Subject: Re: [AccessD] How To Display an Image from a Pervasive Database > table Via Access 2007 > > Re: " improvement in MS Access tend not to progress too rapidly." > This may be the understatement of the century. > Examples: > 1) SQL in queries don't retain their original format. > Any large query quickly becomes a indecipherable string of letters. > 2) no comments permitted in the SQL of a query. > Why did I do this GROUP BY again ? > > This has to be intentional. > > > -----Original Message----- > > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > > Of Jim Lawrence > > Sent: Sunday, May 03, 2015 6:26 PM > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] How To Display an Image from a Pervasive > > Database table Via Access 2007 > > > > One comment Brad. Things may have changed since a decade ago but I have > > found that improvement in MS Access tend not to progress too rapidly. > > My one recommendation is to not embed pictures within the application > > just call any images from their own directory as necessary. > > > > Jim > > > > ----- Original Message ----- > > From: "Brad Marks" > > To: "Access Developers discussion and problem solving" > > > > Sent: Thursday, April 30, 2015 11:48:04 AM > > Subject: [AccessD] How To Display an Image from a Pervasive Database > > table Via Access 2007 > > > > All, > > > > We have a purchased accounting package called Sage Business Works. > > > > Pictures of products are stored in the Business Works database > > (Pervasive). > > > > From the product documentation I see a field named "Image". > > > > When I connect to the Parts table, with Access, I can run a query which > > shows the Image field as "OLE object". All of the other fields are > > shown (text fields, numeric fields) > > > > I have never worked with images before. I would like to be able to > > display these images with an Access form or report. > > > > I have done a number of experiments, but I have not been able to see > > the images with either an Access form or report. > > > > I must be missing something. > > > > Any help would be appreciated. > > > > Thanks, > > > > Brad > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From james at fcidms.com Tue May 5 09:42:49 2015 From: james at fcidms.com (James Barash) Date: Tue, 5 May 2015 14:42:49 +0000 Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: <1430706820829.63051@blackforestltd.com> References: , <1934826082.66137556.1430691931396.JavaMail.root@shaw.ca> <1430706820829.63051@blackforestltd.com> Message-ID: Brad: I assume you tried adding a Bound Object Frame to a form and binding it to the OLE field. If that didn't work then the object is probably a format that Access doesn't support. I'm not sure if this will help but I've used some of Lebans' code to extract files from Access OLE fields so maybe it will work here as well. www.lebans.com/oletodisk.htm You'd have to save each object to disk and then try to read it back but it might do what you need. Hope this helps. James -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks Sent: Sunday, May 03, 2015 10:34 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 Jim, Thanks for your input on this problem. I agree with you. If the pictures were stored in their own folder, I would not be running into this problem. The catch is that I am trying to pull pictures that are stored in a database that is part of a purchased accounting package. When this accounting system was installed, there was not an option as to where the pictures are stored. We had to use the system as delivered. Therefore the pictures are stored in the database. I have many queries that pull data via ODBC from this database. These all work nicely. When I add the image field to one of these queries, I see "OLE" when I run the query. However, when I try to view the picture with an Access report or form, nothing is shown. I wonder if I need to add some additional software to view images via Access 2007 reports or forms. Brad ________________________________________ From: AccessD on behalf of Jim Lawrence Sent: Sunday, May 3, 2015 5:25 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 One comment Brad. Things may have changed since a decade ago but I have found that improvement in MS Access tend not to progress too rapidly. My one recommendation is to not embed pictures within the application just call any images from their own directory as necessary. Jim ----- Original Message ----- From: "Brad Marks" To: "Access Developers discussion and problem solving" Sent: Thursday, April 30, 2015 11:48:04 AM Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 All, We have a purchased accounting package called Sage Business Works. Pictures of products are stored in the Business Works database (Pervasive). >From the product documentation I see a field named "Image". When I connect to the Parts table, with Access, I can run a query which shows the Image field as "OLE object". All of the other fields are shown (text fields, numeric fields) I have never worked with images before. I would like to be able to display these images with an Access form or report. I have done a number of experiments, but I have not been able to see the images with either an Access form or report. I must be missing something. Any help would be appreciated. Thanks, Brad -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jimdettman at verizon.net Tue May 5 10:22:05 2015 From: jimdettman at verizon.net (Jim Dettman) Date: Tue, 05 May 2015 11:22:05 -0400 Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: <1430706820829.63051@blackforestltd.com> References: , <1934826082.66137556.1430691931396.JavaMail.root@shaw.ca> <1430706820829.63051@blackforestltd.com> Message-ID: <80282E9C90494A4FAACB0EF6371104A2@XPS> << I wonder if I need to add some additional software to view images via Access 2007 reports or forms. >> That would be correct. You need something installed on your system and registered for the extension that the OLE object is in. Ie. MS Paint can handle .jpg and can be registered as an OLE server. Jim. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks Sent: Sunday, May 03, 2015 10:34 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 Jim, Thanks for your input on this problem. I agree with you. If the pictures were stored in their own folder, I would not be running into this problem. The catch is that I am trying to pull pictures that are stored in a database that is part of a purchased accounting package. When this accounting system was installed, there was not an option as to where the pictures are stored. We had to use the system as delivered. Therefore the pictures are stored in the database. I have many queries that pull data via ODBC from this database. These all work nicely. When I add the image field to one of these queries, I see "OLE" when I run the query. However, when I try to view the picture with an Access report or form, nothing is shown. I wonder if I need to add some additional software to view images via Access 2007 reports or forms. Brad ________________________________________ From: AccessD on behalf of Jim Lawrence Sent: Sunday, May 3, 2015 5:25 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 One comment Brad. Things may have changed since a decade ago but I have found that improvement in MS Access tend not to progress too rapidly. My one recommendation is to not embed pictures within the application just call any images from their own directory as necessary. Jim ----- Original Message ----- From: "Brad Marks" To: "Access Developers discussion and problem solving" Sent: Thursday, April 30, 2015 11:48:04 AM Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 All, We have a purchased accounting package called Sage Business Works. Pictures of products are stored in the Business Works database (Pervasive). >From the product documentation I see a field named "Image". When I connect to the Parts table, with Access, I can run a query which shows the Image field as "OLE object". All of the other fields are shown (text fields, numeric fields) I have never worked with images before. I would like to be able to display these images with an Access form or report. I have done a number of experiments, but I have not been able to see the images with either an Access form or report. I must be missing something. Any help would be appreciated. Thanks, Brad -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Tue May 5 14:32:04 2015 From: rockysmolin at bchacc.com (Rocky Smolin) Date: Tue, 5 May 2015 12:32:04 -0700 Subject: [AccessD] Outlook looking into Access Message-ID: Dear List: I developed an app for a client that has a lot of customer contact records with email addresses. He wants to know if Outlook can 'see' those addresses to create emails - without importing them into the Outlook Contacts folder. I said I didn't know of a way but would ask around. Can this be done? I've already told him about the two step process - export from Access db to csv file and import using the wiz. MTIA Rocky From rockysmolin at bchacc.com Tue May 5 15:13:09 2015 From: rockysmolin at bchacc.com (Rocky Smolin) Date: Tue, 5 May 2015 13:13:09 -0700 Subject: [AccessD] Diff Now Message-ID: Anyone know about or use this tool to compare code snips? http://www.diffnow.com/ Rocky From steve at datamanagementsolutions.biz Tue May 5 15:43:16 2015 From: steve at datamanagementsolutions.biz (Steve Schapel) Date: Wed, 6 May 2015 08:43:16 +1200 Subject: [AccessD] Diff Now In-Reply-To: References: Message-ID: <9FC3B3F472D041F4B44A504219B0C6F7@SteveT540p> Thanks for letting us know about that, Rocky. I'd never heard of it before, but I just had a play with it, and it looks pretty good. I can see I will have a use for it. Regards Steve -----Original Message----- From: Rocky Smolin Sent: Wednesday, May 6, 2015 8:13 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Diff Now Anyone know about or use this tool to compare code snips? http://www.diffnow.com/ Rocky From accessd at shaw.ca Tue May 5 17:25:02 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 5 May 2015 16:25:02 -0600 (MDT) Subject: [AccessD] Diff Now In-Reply-To: Message-ID: <110468384.67778998.1430864702621.JavaMail.root@shaw.ca> That could be useful. Jim ----- Original Message ----- From: "Rocky Smolin" To: "Access Developers discussion and problem solving" Sent: Tuesday, May 5, 2015 1:13:09 PM Subject: [AccessD] Diff Now Anyone know about or use this tool to compare code snips? http://www.diffnow.com/ Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jbartow at winhaven.net Tue May 5 19:47:15 2015 From: jbartow at winhaven.net (John R Bartow) Date: Tue, 5 May 2015 19:47:15 -0500 Subject: [AccessD] Outlook looking into Access In-Reply-To: References: Message-ID: <007f01d08796$3299d190$97cd74b0$@winhaven.net> Probably. I went the other way and used Access to email to the addresses in its database via Outlook. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin Sent: Tuesday, May 05, 2015 2:32 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Outlook looking into Access Dear List: I developed an app for a client that has a lot of customer contact records with email addresses. He wants to know if Outlook can 'see' those addresses to create emails - without importing them into the Outlook Contacts folder. I said I didn't know of a way but would ask around. Can this be done? I've already told him about the two step process - export from Access db to csv file and import using the wiz. MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From marksimms at verizon.net Tue May 5 20:24:18 2015 From: marksimms at verizon.net (Mark Simms) Date: Tue, 05 May 2015 21:24:18 -0400 Subject: [AccessD] Office 365 Developer Program In-Reply-To: References: <1430556784643.88552@cactus.dk> <1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> <070a01d08609$eea34710$cbe9d530$@net> Message-ID: <01e001d0879b$5fed1d00$1fc75700$@net> Re: "There is also a big variance in functionality between the online apps and their much more powerful desktop parents" Darryl - can you enumerate these functional items ? I think Office 365 apps are just a "shell" of the desktop counterparts. From darryl at whittleconsulting.com.au Tue May 5 22:07:54 2015 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Wed, 6 May 2015 03:07:54 +0000 Subject: [AccessD] Office 365 Developer Program In-Reply-To: <01e001d0879b$5fed1d00$1fc75700$@net> References: <1430556784643.88552@cactus.dk> <1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> <070a01d08609$eea34710$cbe9d530$@net> <01e001d0879b$5fed1d00$1fc75700$@net> Message-ID: Yes... If you are talking the 'universal' online apps, they are very thin on features and have no VBA functionality. The whole 'metro/modern/universal' apps vs the desktop apps thing is still bloody confusing for most people. They (logically enough) don't get they are two separate application and not always that compatible.... -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark Simms Sent: Wednesday, 6 May 2015 11:24 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Office 365 Developer Program Re: "There is also a big variance in functionality between the online apps and their much more powerful desktop parents" Darryl - can you enumerate these functional items ? I think Office 365 apps are just a "shell" of the desktop counterparts. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From rockysmolin at bchacc.com Wed May 6 10:16:17 2015 From: rockysmolin at bchacc.com (Rocky Smolin) Date: Wed, 6 May 2015 08:16:17 -0700 Subject: [AccessD] Outlook looking into Access In-Reply-To: <007f01d08796$3299d190$97cd74b0$@winhaven.net> References: <007f01d08796$3299d190$97cd74b0$@winhaven.net> Message-ID: <5DA28EA655294EB2BB50DB69017DFE9E@HAL9007> That code I have. Going the other way is more problematic. I suppose, although I've never done it, there's a way to put some VBA behind Outlook like you can with Excel to open an Access table and extract selected email addresses. But I've never done that. R -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John R Bartow Sent: Tuesday, May 05, 2015 5:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Outlook looking into Access Importance: High Probably. I went the other way and used Access to email to the addresses in its database via Outlook. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin Sent: Tuesday, May 05, 2015 2:32 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Outlook looking into Access Dear List: I developed an app for a client that has a lot of customer contact records with email addresses. He wants to know if Outlook can 'see' those addresses to create emails - without importing them into the Outlook Contacts folder. I said I didn't know of a way but would ask around. Can this be done? I've already told him about the two step process - export from Access db to csv file and import using the wiz. 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 From gustav at cactus.dk Wed May 6 10:22:49 2015 From: gustav at cactus.dk (Gustav Brock) Date: Wed, 6 May 2015 15:22:49 +0000 Subject: [AccessD] Outlook looking into Access Message-ID: Hi Rocky Pressing Alt+F11 in Outlook, it seems like nothing more than adding a reference to DAO and pull the table. Problem is: What next? /gustav -----Oprindelig meddelelse----- Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Rocky Smolin Sendt: 6. maj 2015 17:16 Til: 'Access Developers discussion and problem solving' Emne: Re: [AccessD] Outlook looking into Access That code I have. Going the other way is more problematic. I suppose, although I've never done it, there's a way to put some VBA behind Outlook like you can with Excel to open an Access table and extract selected email addresses. But I've never done that. R -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John R Bartow Sent: Tuesday, May 05, 2015 5:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Outlook looking into Access Importance: High Probably. I went the other way and used Access to email to the addresses in its database via Outlook. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin Sent: Tuesday, May 05, 2015 2:32 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Outlook looking into Access Dear List: I developed an app for a client that has a lot of customer contact records with email addresses. He wants to know if Outlook can 'see' those addresses to create emails - without importing them into the Outlook Contacts folder. I said I didn't know of a way but would ask around. Can this be done? I've already told him about the two step process - export from Access db to csv file and import using the wiz. MTIA Rocky From rockysmolin at bchacc.com Wed May 6 10:32:58 2015 From: rockysmolin at bchacc.com (Rocky Smolin) Date: Wed, 6 May 2015 08:32:58 -0700 Subject: [AccessD] Outlook looking into Access In-Reply-To: References: Message-ID: <7B564A5E5E4D4D4195BC33898E7BFAA0@HAL9007> How would one then in Outlook, trigger that code which would have to open some kind of list from the table, allow the user to select names, and push those email addresses into an email? TIA Rocky -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Wednesday, May 06, 2015 8:23 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Outlook looking into Access Hi Rocky Pressing Alt+F11 in Outlook, it seems like nothing more than adding a reference to DAO and pull the table. Problem is: What next? /gustav -----Oprindelig meddelelse----- Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Rocky Smolin Sendt: 6. maj 2015 17:16 Til: 'Access Developers discussion and problem solving' Emne: Re: [AccessD] Outlook looking into Access That code I have. Going the other way is more problematic. I suppose, although I've never done it, there's a way to put some VBA behind Outlook like you can with Excel to open an Access table and extract selected email addresses. But I've never done that. R -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John R Bartow Sent: Tuesday, May 05, 2015 5:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Outlook looking into Access Importance: High Probably. I went the other way and used Access to email to the addresses in its database via Outlook. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin Sent: Tuesday, May 05, 2015 2:32 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Outlook looking into Access Dear List: I developed an app for a client that has a lot of customer contact records with email addresses. He wants to know if Outlook can 'see' those addresses to create emails - without importing them into the Outlook Contacts folder. I said I didn't know of a way but would ask around. Can this be done? I've already told him about the two step process - export from Access db to csv file and import using the wiz. MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jbartow at winhaven.net Wed May 6 11:21:52 2015 From: jbartow at winhaven.net (John R Bartow) Date: Wed, 6 May 2015 11:21:52 -0500 Subject: [AccessD] Outlook looking into Access In-Reply-To: <7B564A5E5E4D4D4195BC33898E7BFAA0@HAL9007> References: <7B564A5E5E4D4D4195BC33898E7BFAA0@HAL9007> Message-ID: <00dd01d08818$c38db0e0$4aa912a0$@winhaven.net> And the biggest problem for me was - which version of Outlook? The beast is not consistent enough to allow for a runtime reference. You'd have to verify that the objection model and VBA you use works with each version you might expect to run it with. I currently support 2003-2013, that?s a lot of work if you can do it the other way around. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin Sent: Wednesday, May 06, 2015 10:33 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Outlook looking into Access How would one then in Outlook, trigger that code which would have to open some kind of list from the table, allow the user to select names, and push those email addresses into an email? TIA Rocky -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Wednesday, May 06, 2015 8:23 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Outlook looking into Access Hi Rocky Pressing Alt+F11 in Outlook, it seems like nothing more than adding a reference to DAO and pull the table. Problem is: What next? /gustav -----Oprindelig meddelelse----- Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Rocky Smolin Sendt: 6. maj 2015 17:16 Til: 'Access Developers discussion and problem solving' Emne: Re: [AccessD] Outlook looking into Access That code I have. Going the other way is more problematic. I suppose, although I've never done it, there's a way to put some VBA behind Outlook like you can with Excel to open an Access table and extract selected email addresses. But I've never done that. R -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John R Bartow Sent: Tuesday, May 05, 2015 5:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Outlook looking into Access Importance: High Probably. I went the other way and used Access to email to the addresses in its database via Outlook. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin Sent: Tuesday, May 05, 2015 2:32 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Outlook looking into Access Dear List: I developed an app for a client that has a lot of customer contact records with email addresses. He wants to know if Outlook can 'see' those addresses to create emails - without importing them into the Outlook Contacts folder. I said I didn't know of a way but would ask around. Can this be done? I've already told him about the two step process - export from Access db to csv file and import using the wiz. 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 From jimdettman at verizon.net Wed May 6 11:42:58 2015 From: jimdettman at verizon.net (Jim Dettman) Date: Wed, 06 May 2015 12:42:58 -0400 Subject: [AccessD] Outlook looking into Access In-Reply-To: References: Message-ID: Only problem there is you need to be careful where you put code. Outlook has a "Microsoft Office Outlook Object" section with a module called "ThisOutlookSession" and a "Modules" section where you can add new modules. Code that needs to react to Outlook events goes in the first. Code that does not (such as adding a button to a tool bar) goes in the second. On the first, note that the object dropdown has "Application" listed. On the procedure drop down, these are the events you can react to and add code for. Anything outside of that is ignored by Outlook. Jim. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Wednesday, May 06, 2015 11:23 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Outlook looking into Access Hi Rocky Pressing Alt+F11 in Outlook, it seems like nothing more than adding a reference to DAO and pull the table. Problem is: What next? /gustav -----Oprindelig meddelelse----- Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Rocky Smolin Sendt: 6. maj 2015 17:16 Til: 'Access Developers discussion and problem solving' Emne: Re: [AccessD] Outlook looking into Access That code I have. Going the other way is more problematic. I suppose, although I've never done it, there's a way to put some VBA behind Outlook like you can with Excel to open an Access table and extract selected email addresses. But I've never done that. R -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John R Bartow Sent: Tuesday, May 05, 2015 5:47 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Outlook looking into Access Importance: High Probably. I went the other way and used Access to email to the addresses in its database via Outlook. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin Sent: Tuesday, May 05, 2015 2:32 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Outlook looking into Access Dear List: I developed an app for a client that has a lot of customer contact records with email addresses. He wants to know if Outlook can 'see' those addresses to create emails - without importing them into the Outlook Contacts folder. I said I didn't know of a way but would ask around. Can this be done? I've already told him about the two step process - export from Access db to csv file and import using the wiz. MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From marksimms at verizon.net Thu May 7 18:52:44 2015 From: marksimms at verizon.net (Mark Simms) Date: Thu, 07 May 2015 19:52:44 -0400 Subject: [AccessD] Office 365 Developer Program In-Reply-To: References: <1430556784643.88552@cactus.dk> <1430557820914.37632@cactus.dk> <1430559142934.86697@cactus.dk> <070a01d08609$eea34710$cbe9d530$@net> <01e001d0879b$5fed1d00$1fc75700$@net> Message-ID: <03af01d08920$ea532260$bef96720$@net> This is total B.S. They've had YEARS now to port the coding to Javascript as well as the object model. I don't think this new CEO is much better than Balmer. I'll bet Google "beats them to the punch"....and that will end the Office dominance by MSFT. They really deserve to "go down". > > Yes... If you are talking the 'universal' online apps, they are very > thin on features and have no VBA functionality. > From marksimms at verizon.net Thu May 7 18:53:36 2015 From: marksimms at verizon.net (Mark Simms) Date: Thu, 07 May 2015 19:53:36 -0400 Subject: [AccessD] Outlook looking into Access In-Reply-To: References: Message-ID: <03b001d08921$09115000$1b33f000$@net> VBA coding in Outlook is extremely tricky and challenging. Period. Been there, done that. > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of Jim Dettman > Sent: Wednesday, May 06, 2015 12:43 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Outlook looking into Access > > > Only problem there is you need to be careful where you put code. > Outlook > has a "Microsoft Office Outlook Object" section with a module called > "ThisOutlookSession" and a "Modules" section where you can add new > modules. > > Code that needs to react to Outlook events goes in the first. Code > that > does not (such as adding a button to a tool bar) goes in the second. > > On the first, note that the object dropdown has "Application" listed. > On > the procedure drop down, these are the events you can react to and add > code > for. Anything outside of that is ignored by Outlook. > > Jim. > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of > Gustav Brock > Sent: Wednesday, May 06, 2015 11:23 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Outlook looking into Access > > Hi Rocky > > Pressing Alt+F11 in Outlook, it seems like nothing more than adding a > reference to DAO and pull the table. Problem is: What next? > > /gustav > > -----Oprindelig meddelelse----- > Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] P? vegne af > Rocky > Smolin > Sendt: 6. maj 2015 17:16 > Til: 'Access Developers discussion and problem solving' > Emne: Re: [AccessD] Outlook looking into Access > > That code I have. Going the other way is more problematic. I suppose, > although I've never done it, there's a way to put some VBA behind > Outlook > like you can with Excel to open an Access table and extract selected > email > addresses. But I've never done that. > > R > > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of > John R Bartow > Sent: Tuesday, May 05, 2015 5:47 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Outlook looking into Access > Importance: High > > Probably. I went the other way and used Access to email to the > addresses in > its database via Outlook. > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of > Rocky Smolin > Sent: Tuesday, May 05, 2015 2:32 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Outlook looking into Access > > Dear List: > > I developed an app for a client that has a lot of customer contact > records > with email addresses. He wants to know if Outlook can 'see' those > addresses > to create emails - without importing them into the Outlook Contacts > folder. > > > I said I didn't know of a way but would ask around. > > Can this be done? > > I've already told him about the two step process - export from Access > db to > csv file and import using the wiz. > > 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 From rockysmolin at bchacc.com Thu May 7 19:22:37 2015 From: rockysmolin at bchacc.com (Rocky Smolin) Date: Thu, 7 May 2015 17:22:37 -0700 Subject: [AccessD] Outlook looking into Access In-Reply-To: <03b001d08921$09115000$1b33f000$@net> References: <03b001d08921$09115000$1b33f000$@net> Message-ID: Good. My perfect excuse not to do this. R -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark Simms Sent: Thursday, May 07, 2015 4:54 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Outlook looking into Access VBA coding in Outlook is extremely tricky and challenging. Period. Been there, done that. > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of Jim Dettman > Sent: Wednesday, May 06, 2015 12:43 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Outlook looking into Access > > > Only problem there is you need to be careful where you put code. > Outlook > has a "Microsoft Office Outlook Object" section with a module called > "ThisOutlookSession" and a "Modules" section where you can add new > modules. > > Code that needs to react to Outlook events goes in the first. Code > that does not (such as adding a button to a tool bar) goes in the > second. > > On the first, note that the object dropdown has "Application" listed. > On > the procedure drop down, these are the events you can react to and add > code for. Anything outside of that is ignored by Outlook. > > Jim. > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of Gustav Brock > Sent: Wednesday, May 06, 2015 11:23 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Outlook looking into Access > > Hi Rocky > > Pressing Alt+F11 in Outlook, it seems like nothing more than adding a > reference to DAO and pull the table. Problem is: What next? > > /gustav > > -----Oprindelig meddelelse----- > Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] Pe vegne af > Rocky Smolin > Sendt: 6. maj 2015 17:16 > Til: 'Access Developers discussion and problem solving' > Emne: Re: [AccessD] Outlook looking into Access > > That code I have. Going the other way is more problematic. I > suppose, although I've never done it, there's a way to put some VBA > behind Outlook like you can with Excel to open an Access table and > extract selected email addresses. But I've never done that. > > R > > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of John R Bartow > Sent: Tuesday, May 05, 2015 5:47 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Outlook looking into Access > Importance: High > > Probably. I went the other way and used Access to email to the > addresses in its database via Outlook. > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of Rocky Smolin > Sent: Tuesday, May 05, 2015 2:32 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Outlook looking into Access > > Dear List: > > I developed an app for a client that has a lot of customer contact > records with email addresses. He wants to know if Outlook can 'see' > those addresses to create emails - without importing them into the > Outlook Contacts folder. > > > I said I didn't know of a way but would ask around. > > Can this be done? > > I've already told him about the two step process - export from Access > db to csv file and import using the wiz. > > 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 From accessd at shaw.ca Thu May 7 20:37:07 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 7 May 2015 19:37:07 -0600 (MDT) Subject: [AccessD] Office 365 Developer Program In-Reply-To: <03af01d08920$ea532260$bef96720$@net> Message-ID: <1831836659.69600341.1431049027324.JavaMail.root@shaw.ca> It is worthy of noting that LibraOffice will be, very shortly, offering, realtime internet collaborative inter-active document/spreadsheet etc functionality. It will be desktop based but they also plan to have a cloud based version as well. Right now collaborative desktop apps will incur no extra costs. It should be interesting to see how this new tech works. Unfortunately, LibraOffice does not have a viable database replacement but that will come and apparently Microsoft doesn't either. ;-) IMHO, the one big problem with converting products from proprietary to OS or desktop to web based, it is hard to establish if a user is appropriately licensed. That is what is holding everything back. Jim ----- Original Message ----- From: "Mark Simms" To: "Access Developers discussion and problem solving" Sent: Thursday, May 7, 2015 4:52:44 PM Subject: Re: [AccessD] Office 365 Developer Program This is total B.S. They've had YEARS now to port the coding to Javascript as well as the object model. I don't think this new CEO is much better than Balmer. I'll bet Google "beats them to the punch"....and that will end the Office dominance by MSFT. They really deserve to "go down". > > Yes... If you are talking the 'universal' online apps, they are very > thin on features and have no VBA functionality. > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From darryl at whittleconsulting.com.au Thu May 7 20:59:02 2015 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Fri, 8 May 2015 01:59:02 +0000 Subject: [AccessD] Office 365 Developer Program In-Reply-To: <1831836659.69600341.1431049027324.JavaMail.root@shaw.ca> References: <03af01d08920$ea532260$bef96720$@net> <1831836659.69600341.1431049027324.JavaMail.root@shaw.ca> Message-ID: Sounds like they need to drop the 1980's way of doing business and come up with a new and better model for charging customers. Seems crazy to let something like licensing hold this back. There is no stopping the tide so the sooner they come up with a new model the better - for both them and us. Hmmmm.... -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Friday, 8 May 2015 11:37 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Office 365 Developer Program It is worthy of noting that LibraOffice will be, very shortly, offering, realtime internet collaborative inter-active document/spreadsheet etc functionality. It will be desktop based but they also plan to have a cloud based version as well. Right now collaborative desktop apps will incur no extra costs. It should be interesting to see how this new tech works. Unfortunately, LibraOffice does not have a viable database replacement but that will come and apparently Microsoft doesn't either. ;-) IMHO, the one big problem with converting products from proprietary to OS or desktop to web based, it is hard to establish if a user is appropriately licensed. That is what is holding everything back. Jim ----- Original Message ----- From: "Mark Simms" To: "Access Developers discussion and problem solving" Sent: Thursday, May 7, 2015 4:52:44 PM Subject: Re: [AccessD] Office 365 Developer Program This is total B.S. They've had YEARS now to port the coding to Javascript as well as the object model. I don't think this new CEO is much better than Balmer. I'll bet Google "beats them to the punch"....and that will end the Office dominance by MSFT. They really deserve to "go down". > > Yes... If you are talking the 'universal' online apps, they are very > thin on features and have no VBA functionality. > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwelz at hotmail.com Mon May 11 15:58:41 2015 From: jwelz at hotmail.com (Jurgen Welz) Date: Mon, 11 May 2015 14:58:41 -0600 Subject: [AccessD] SQL Formatter (Was How To Display an Image from a Pervasive Database table Via Access 2007) In-Reply-To: References: <070901d08609$2a7458c0$7f5d0a40$@net>, <908215625.66371055.1430739200129.JavaMail.root@shaw.ca>, Message-ID: I use http://poorsql.com/ It does a great job of parsing the text into something much more comprehensible. I've been using Pervasive data since Sage bought out Precision Estimating (Timberline). Sage's most recent foray into SQL server with their construction estimating product has us running two systems; Pervasive for the estimators and SQL Server for the project managers. Their conversion to SQL Server was a total flop. The whole system started out as text file fields limited to 50 characters concatenated a fixed number of times to a maximum field length. This rule was simply carried over to the Pervasive and then SQL Server versions. The result is unweildy in production. Pervasive itself was pretty slick and pulled data out of data stored in the file system. There was a root file with metadata about the data files, a sub folder named 'PVData' and roughly 60 files beneath that approximately mapping to a table each. The fun was copying estimate files and renaming the estimate without renaming the PVData folders to match. It was not possible to mine data across multiple estimates without linking to multiple estimate backends (1 per estimate) or sequentially linking, extracting and compiling data in a aggregation database, but within a single estimate, it at least worked consistently and very quickly. In all our time with Pervasive, we've never had image data stored there so I can help on that issue. Ciao J?rgen Welz Edmonton, Alberta > Date: Mon, 4 May 2015 17:59:08 -0400 > From: bensonforums at gmail.com > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 > > Someone showed me an SQL editor that they pasted code into and it showed up > much better than in the Access SQL window. I wish I knew what that was, I > am sure it was a common editor many people use. Doesn't prevent Access from > messing with it afterward of course. > > On Mon, May 4, 2015 at 7:33 AM, Jim Lawrence wrote: > > > Ouch. > > > > Jim From bradm at blackforestltd.com Mon May 11 16:26:32 2015 From: bradm at blackforestltd.com (Brad Marks) Date: Mon, 11 May 2015 21:26:32 +0000 Subject: [AccessD] SQL Formatter (Was How To Display an Image from a Pervasive Database table Via Access 2007) In-Reply-To: References: <070901d08609$2a7458c0$7f5d0a40$@net>, <908215625.66371055.1430739200129.JavaMail.root@shaw.ca>, Message-ID: J?rgen, Thanks for your post. I have not run into very many people who work with Pervasive databases. We have Sage's accounting system called Business Works. This system works fairly well, but like many purchased packages, the canned reports and the built-in report-writer are not very good. We therefore have used the Microsoft Access report engine to build a very nice "Inquiry System" which provides "on demand" reports for our users. I still have not been able to figure out how to display images stored in the Pervasive Database via an Access Report or Form, however. I put together a little query for the Pervasive table that holds the images. When I run this query, I see "OLE Object" in the image field in each record. The other fields, like the part number are shown properly. This is not a serious problem, as our users can go through the "front door" and view the Part info and images via the Sage Business Works screens. If I can figure out how to show images with Access, however, I could provide a better method for our users. The other interesting thing is that when our users run one of the canned reports in Business Works, the report may take 1-2 minutes to run. When they use the inquiry system that we built with Access, they can obtain the same info in less than 2 seconds (via ODBC). Brad PS. We also have a purchased manufacturing system called DBA Manufacturing that uses a DBMS called Firebird. We have had great success in pulling data from this database also with ODBC to feed Access-based reports. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jurgen Welz Sent: Monday, May 11, 2015 3:59 PM To: Access Developers discussion and problem solving Subject: [AccessD] SQL Formatter (Was How To Display an Image from a Pervasive Database table Via Access 2007) I use http://poorsql.com/ It does a great job of parsing the text into something much more comprehensible. I've been using Pervasive data since Sage bought out Precision Estimating (Timberline). Sage's most recent foray into SQL server with their construction estimating product has us running two systems; Pervasive for the estimators and SQL Server for the project managers. Their conversion to SQL Server was a total flop. The whole system started out as text file fields limited to 50 characters concatenated a fixed number of times to a maximum field length. This rule was simply carried over to the Pervasive and then SQL Server versions. The result is unweildy in production. Pervasive itself was pretty slick and pulled data out of data stored in the file system. There was a root file with metadata about the data files, a sub folder named 'PVData' and roughly 60 files beneath that approximately mapping to a table each. The fun was copying estimate files and renaming the estimate without renaming the PVData folders to match. It was not possible to mine data across multiple estimates without linking to multiple estimate backends (1 per estimate) or sequentially linking, extracting and compiling data in a aggregation database, but within a single estimate, it at least worked consistently and very quickly. In all our time with Pervasive, we've never had image data stored there so I can help on that issue. Ciao J?rgen Welz Edmonton, Alberta > Date: Mon, 4 May 2015 17:59:08 -0400 > From: bensonforums at gmail.com > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] How To Display an Image from a Pervasive > Database table Via Access 2007 > > Someone showed me an SQL editor that they pasted code into and it > showed up much better than in the Access SQL window. I wish I knew > what that was, I am sure it was a common editor many people use. > Doesn't prevent Access from messing with it afterward of course. > > On Mon, May 4, 2015 at 7:33 AM, Jim Lawrence wrote: > > > Ouch. > > > > Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Tue May 12 12:32:51 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 12 May 2015 11:32:51 -0600 (MDT) Subject: [AccessD] SQL Formatter (Was How To Display an Image from a Pervasive Database table Via Access 2007) In-Reply-To: Message-ID: <797377982.72577824.1431451971625.JavaMail.root@shaw.ca> Hi Jurgen Is that ever cool. :-) Jim ----- Original Message ----- From: "Jurgen Welz" To: "Access Developers discussion and problem solving" Sent: Monday, May 11, 2015 1:58:41 PM Subject: [AccessD] SQL Formatter (Was How To Display an Image from a Pervasive Database table Via Access 2007) I use http://poorsql.com/ It does a great job of parsing the text into something much more comprehensible. I've been using Pervasive data since Sage bought out Precision Estimating (Timberline). Sage's most recent foray into SQL server with their construction estimating product has us running two systems; Pervasive for the estimators and SQL Server for the project managers. Their conversion to SQL Server was a total flop. The whole system started out as text file fields limited to 50 characters concatenated a fixed number of times to a maximum field length. This rule was simply carried over to the Pervasive and then SQL Server versions. The result is unweildy in production. Pervasive itself was pretty slick and pulled data out of data stored in the file system. There was a root file with metadata about the data files, a sub folder named 'PVData' and roughly 60 files beneath that approximately mapping to a table each. The fun was copying estimate files and renaming the estimate without renaming the PVData folders to match. It was not possible to mine data across multiple estimates without linking to multiple estimate backends (1 per estimate) or sequentially linking, extracting and compiling data in a aggregation database, but within a single estimate, it at least worked consistently and very quickly. In all our time with Pervasive, we've never had image data stored there so I can help on that issue. Ciao J?rgen Welz Edmonton, Alberta > Date: Mon, 4 May 2015 17:59:08 -0400 > From: bensonforums at gmail.com > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 > > Someone showed me an SQL editor that they pasted code into and it showed up > much better than in the Access SQL window. I wish I knew what that was, I > am sure it was a common editor many people use. Doesn't prevent Access from > messing with it afterward of course. > > On Mon, May 4, 2015 at 7:33 AM, Jim Lawrence wrote: > > > Ouch. > > > > Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bensonforums at gmail.com Wed May 13 01:44:29 2015 From: bensonforums at gmail.com (Bill Benson) Date: Wed, 13 May 2015 02:44:29 -0400 Subject: [AccessD] SQL Formatter (Was How To Display an Image from a Pervasive Database table Via Access 2007) In-Reply-To: <797377982.72577824.1431451971625.JavaMail.root@shaw.ca> References: <797377982.72577824.1431451971625.JavaMail.root@shaw.ca> Message-ID: What part? On May 12, 2015 1:34 PM, "Jim Lawrence" wrote: > Hi Jurgen > > Is that ever cool. :-) > > Jim > > ----- Original Message ----- > From: "Jurgen Welz" > To: "Access Developers discussion and problem solving" < > accessd at databaseadvisors.com> > Sent: Monday, May 11, 2015 1:58:41 PM > Subject: [AccessD] SQL Formatter (Was How To Display an Image from a > Pervasive Database table Via Access 2007) > > I use http://poorsql.com/ > It does a great job of parsing the text into something much more > comprehensible. > > I've been using Pervasive data since Sage bought out Precision Estimating > (Timberline). Sage's most recent foray into SQL server with their > construction estimating product has us running two systems; Pervasive for > the estimators and SQL Server for the project managers. Their conversion > to SQL Server was a total flop. The whole system started out as text file > fields limited to 50 characters concatenated a fixed number of times to a > maximum field length. This rule was simply carried over to the Pervasive > and then SQL Server versions. The result is unweildy in production. > > Pervasive itself was pretty slick and pulled data out of data stored in > the file system. There was a root file with metadata about the data files, > a sub folder named 'PVData' and roughly 60 files beneath that approximately > mapping to a table each. The fun was copying estimate files and renaming > the estimate without renaming the PVData folders to match. It was not > possible to mine data across multiple estimates without linking to multiple > estimate backends (1 per estimate) or sequentially linking, extracting and > compiling data in a aggregation database, but within a single estimate, it > at least worked consistently and very quickly. > > In all our time with Pervasive, we've never had image data stored there so > I can help on that issue. > > Ciao > J?rgen Welz > Edmonton, Alberta > > > Date: Mon, 4 May 2015 17:59:08 -0400 > > From: bensonforums at gmail.com > > To: accessd at databaseadvisors.com > > Subject: Re: [AccessD] How To Display an Image from a Pervasive Database > table Via Access 2007 > > > > Someone showed me an SQL editor that they pasted code into and it showed > up > > much better than in the Access SQL window. I wish I knew what that was, I > > am sure it was a common editor many people use. Doesn't prevent Access > from > > messing with it afterward of course. > > > > On Mon, May 4, 2015 at 7:33 AM, Jim Lawrence wrote: > > > > > Ouch. > > > > > > 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 accessd at shaw.ca Wed May 13 01:59:32 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Wed, 13 May 2015 00:59:32 -0600 (MDT) Subject: [AccessD] SQL Formatter (Was How To Display an Image from a Pervasive Database table Via Access 2007) In-Reply-To: Message-ID: <1386858296.73028076.1431500372152.JavaMail.root@shaw.ca> I really like that online editor. Jim ----- Original Message ----- From: "Bill Benson" To: "Access Developers discussion and problem solving" Sent: Tuesday, May 12, 2015 11:44:29 PM Subject: Re: [AccessD] SQL Formatter (Was How To Display an Image from a Pervasive Database table Via Access 2007) What part? On May 12, 2015 1:34 PM, "Jim Lawrence" wrote: > Hi Jurgen > > Is that ever cool. :-) > > Jim > > ----- Original Message ----- > From: "Jurgen Welz" > To: "Access Developers discussion and problem solving" < > accessd at databaseadvisors.com> > Sent: Monday, May 11, 2015 1:58:41 PM > Subject: [AccessD] SQL Formatter (Was How To Display an Image from a > Pervasive Database table Via Access 2007) > > I use http://poorsql.com/ > It does a great job of parsing the text into something much more > comprehensible. > > I've been using Pervasive data since Sage bought out Precision Estimating > (Timberline). Sage's most recent foray into SQL server with their > construction estimating product has us running two systems; Pervasive for > the estimators and SQL Server for the project managers. Their conversion > to SQL Server was a total flop. The whole system started out as text file > fields limited to 50 characters concatenated a fixed number of times to a > maximum field length. This rule was simply carried over to the Pervasive > and then SQL Server versions. The result is unweildy in production. > > Pervasive itself was pretty slick and pulled data out of data stored in > the file system. There was a root file with metadata about the data files, > a sub folder named 'PVData' and roughly 60 files beneath that approximately > mapping to a table each. The fun was copying estimate files and renaming > the estimate without renaming the PVData folders to match. It was not > possible to mine data across multiple estimates without linking to multiple > estimate backends (1 per estimate) or sequentially linking, extracting and > compiling data in a aggregation database, but within a single estimate, it > at least worked consistently and very quickly. > > In all our time with Pervasive, we've never had image data stored there so > I can help on that issue. > > Ciao > J?rgen Welz > Edmonton, Alberta > > > Date: Mon, 4 May 2015 17:59:08 -0400 > > From: bensonforums at gmail.com > > To: accessd at databaseadvisors.com > > Subject: Re: [AccessD] How To Display an Image from a Pervasive Database > table Via Access 2007 > > > > Someone showed me an SQL editor that they pasted code into and it showed > up > > much better than in the Access SQL window. I wish I knew what that was, I > > am sure it was a common editor many people use. Doesn't prevent Access > from > > messing with it afterward of course. > > > > On Mon, May 4, 2015 at 7:33 AM, Jim Lawrence wrote: > > > > > Ouch. > > > > > > 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 darren at activebilling.com.au Wed May 13 22:47:12 2015 From: darren at activebilling.com.au (Darren) Date: Thu, 14 May 2015 13:47:12 +1000 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses Message-ID: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> Hi Team I appreciate this may trigger a right vs. wrong discussion. All comments appreciated but this is for a Pro-Bono Project so there are no funds and my time is not infinite. So a perfect solution is not required. Just a working one :-) So... I have inherited a dB with approx 12K names and addresses for a community project I am working on. Data entry has been on home built Access dBs and Excel spreadsheets and data veracity is poor. I can easily identify nearly 1000 records with same first and last names so there appear to be a lot of duplicate entries. We will handle that and will sanitise the old data. However does anyone have a quick and easy "test" where I can quickly check completed names (First and Last) once entered, to see if we have exact or similar matches already in the dB? I really would like the same thing with addresses? I have Googled and I have seen some very complex weighting routines etc - Too tricky for me and beyond the scope of this project (and my skill set). I just need to present the users with a list of exact matches (I can do that now) and some potentials, in a list that they can then decide if it's ok to proceed or not. Many thanks in advance. Darren. From jwcolby at gmail.com Wed May 13 23:26:37 2015 From: jwcolby at gmail.com (John W. Colby) Date: Thu, 14 May 2015 00:26:37 -0400 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> Message-ID: <555423FD.7050503@gmail.com> I use SHA1 in SQL Server to generate a hash. I append all of the address pieces together, then feed the resulting string into the hashbytes function. Obviously the SP updates a HashFamily and HashPerson field VarBinary(200) in the same table as the name / address. ALTER PROCEDURE [dbo].[zzsp_HashFieldsAllAdults_Update] -- Add the parameters for the stored procedure here @DBName varchar(50), @TblName varchar(50) AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here declare @SQL varchar(1000) BEGIN TRY SELECT @SQL = 'UPDATE [' + @DBName + '].[dbo].[' + @TblName + '] ' + 'SET [HashFamily]= hashbytes(''' + 'sha1' + ''', Addr + Zip5 + Zip4 + LName), ' + '[HashPerson]= hashbytes(''' + 'sha1' + ''', Addr + Zip5 + Zip4 + LName + FName)' --WHERE ADDRValid not in(''ANK'',''INV'')' print @SQL exec (@SQL) END TRY BEGIN CATCH print 'There was an error UPDATING the hash fields! ' print ERROR_MESSAGE() END CATCH END The resulting hash can be used to dedupe the data since an identical name/address will create an identical hash. AZData is my table name. Or just select the dupes using a groupby / count kind of construct. ALTER PROCEDURE [dbo].[usp_TblAZData_DedupePK] -- Add the parameters for the stored procedure here AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; declare @RecsAffected int -- Insert statements for procedure here -- --Clean out all records with a bad hash -- DELETE FROM f FROM [dbo].[AZData] AS f WHERE HashFamily is null select @RecsAffected = 1 while (@RecsAffected > 0) begin -- --Use the hash number to select identical records, then the PK (autonumber) to select between identical records. --And delete the dupes -- DELETE FROM f FROM [dbo].[AZData] AS f INNER JOIN [dbo].[AZData] AS g ON g.HashPerson = f.HashPerson AND f.pk < g.pk select @RecsAffected = @@RowCount print @RecsAffected print 'success deduping AZData' end END I can actually do this for you if you send me a file with the data. It needs to have FName, LName, Addr, City, St and Postal Code, or whatever makes it distinguishable from the next record. John W. Colby On 5/13/2015 11:47 PM, Darren wrote: > Hi Team > I appreciate this may trigger a right vs. wrong discussion. All comments > appreciated but this is for a Pro-Bono Project so there are no funds and my > time is not infinite. > So a perfect solution is not required. Just a working one :-) > So... > I have inherited a dB with approx 12K names and addresses for a community > project I am working on. > Data entry has been on home built Access dBs and Excel spreadsheets and data > veracity is poor. > I can easily identify nearly 1000 records with same first and last names so > there appear to be a lot of duplicate entries. > We will handle that and will sanitise the old data. However does anyone have > a quick and easy "test" where I can quickly check completed names (First and > Last) once entered, to see if we have exact or similar matches already in > the dB? > I really would like the same thing with addresses? > I have Googled and I have seen some very complex weighting routines etc - > Too tricky for me and beyond the scope of this project (and my skill set). > I just need to present the users with a list of exact matches (I can do that > now) and some potentials, in a list that they can then decide if it's ok to > proceed or not. > Many thanks in advance. > Darren. From jimdettman at verizon.net Thu May 14 06:35:33 2015 From: jimdettman at verizon.net (Jim Dettman) Date: Thu, 14 May 2015 07:35:33 -0400 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> Message-ID: <9259EDA484B148448AEAC1EEFF70B811@XPS> Depends on what the goal is. If it's only to check for exact matches, then a collapse of the strings involved (removing all white space) and concatenated against an index suffices. If it's more of a "fuzzy" type of analysis that you want to use, then there are various approaches, like soundex (i.e. One name is "Jim Dettman" vs "Jim Debtman"). Weighting would be throwing in comparing the different components, name vs address. On a straight compare though, I've always fully collapsed the strings, then do a find on an index. Jim. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darren Sent: Wednesday, May 13, 2015 11:47 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] A2003: Checking for Similar Names and or Addresses Hi Team I appreciate this may trigger a right vs. wrong discussion. All comments appreciated but this is for a Pro-Bono Project so there are no funds and my time is not infinite. So a perfect solution is not required. Just a working one :-) So... I have inherited a dB with approx 12K names and addresses for a community project I am working on. Data entry has been on home built Access dBs and Excel spreadsheets and data veracity is poor. I can easily identify nearly 1000 records with same first and last names so there appear to be a lot of duplicate entries. We will handle that and will sanitise the old data. However does anyone have a quick and easy "test" where I can quickly check completed names (First and Last) once entered, to see if we have exact or similar matches already in the dB? I really would like the same thing with addresses? I have Googled and I have seen some very complex weighting routines etc - Too tricky for me and beyond the scope of this project (and my skill set). I just need to present the users with a list of exact matches (I can do that now) and some potentials, in a list that they can then decide if it's ok to proceed or not. Many thanks in advance. Darren. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Thu May 14 10:50:14 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 14 May 2015 09:50:14 -0600 (MDT) Subject: [AccessD] Electron In-Reply-To: Message-ID: <1642534357.74199120.1431618614073.JavaMail.root@shaw.ca> Hi All: The new big development application, according to some articles I have read is the product Electron (formally Atom). What it does is interesting, in that it translates webbased applications and make desktop applications out of them. What makes this concept so interesting and perhaps amusing is that, ten years ago, I never imagined that web applications would have so many features as to make them as powerful as any desktop program but that was ten year ago. Today, there is hardly anything that that a web application couldn't do compared to a desktop app. The product is Open Source, can be downloaded in its entirety off GitHub and its compiled products can run on any platform: http://electron.atom.io If you want to see how this product can be used to convert a web application to a desktop one, check out the new Microsoft new cross-platform Visual Studio: https://code.visualstudio.com/Download ...and... http://techcrunch.com/2015/04/29/microsoft-shocks-the-world-with-visual-studio-code-a-free-code-editor-for-os-x-linux-and-windows/#.efujwt:k3qL My question is when will we have a full featured MS Access built on the web and compiled on the desktop? Jim From davidmcafee at gmail.com Thu May 14 11:20:52 2015 From: davidmcafee at gmail.com (David McAfee) Date: Thu, 14 May 2015 09:20:52 -0700 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: <9259EDA484B148448AEAC1EEFF70B811@XPS> References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> <9259EDA484B148448AEAC1EEFF70B811@XPS> Message-ID: Don't forget James and little Jimmy Dettman ;) On Thu, May 14, 2015 at 4:35 AM, Jim Dettman wrote: > > Depends on what the goal is. If it's only to check for exact matches, > then > a collapse of the strings involved (removing all white space) and > concatenated against an index suffices. > > If it's more of a "fuzzy" type of analysis that you want to use, then there > are various approaches, like soundex (i.e. One name is "Jim Dettman" vs > "Jim Debtman"). > > Weighting would be throwing in comparing the different components, name vs > address. > > On a straight compare though, I've always fully collapsed the strings, then > do a find on an index. > > Jim. > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > Darren > Sent: Wednesday, May 13, 2015 11:47 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] A2003: Checking for Similar Names and or Addresses > > Hi Team > I appreciate this may trigger a right vs. wrong discussion. All comments > appreciated but this is for a Pro-Bono Project so there are no funds and my > time is not infinite. > So a perfect solution is not required. Just a working one :-) > So... > I have inherited a dB with approx 12K names and addresses for a community > project I am working on. > Data entry has been on home built Access dBs and Excel spreadsheets and > data > veracity is poor. > I can easily identify nearly 1000 records with same first and last names so > there appear to be a lot of duplicate entries. > We will handle that and will sanitise the old data. However does anyone > have > a quick and easy "test" where I can quickly check completed names (First > and > Last) once entered, to see if we have exact or similar matches already in > the dB? > I really would like the same thing with addresses? > I have Googled and I have seen some very complex weighting routines etc - > Too tricky for me and beyond the scope of this project (and my skill set). > I just need to present the users with a list of exact matches (I can do > that > now) and some potentials, in a list that they can then decide if it's ok to > proceed or not. > Many thanks in advance. > Darren. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From jwelz at hotmail.com Thu May 14 15:46:44 2015 From: jwelz at hotmail.com (Jurgen Welz) Date: Thu, 14 May 2015 14:46:44 -0600 Subject: [AccessD] How To Display an Image from a Pervasive Database table Via Access 2007 In-Reply-To: References: , <797377982.72577824.1431451971625.JavaMail.root@shaw.ca>, Message-ID: I haven't been able to get an image into one of our Pervasive databases so pulling one out is problematic. I use the following code to change the picture in an image control (originally Access 2000 code but still running in 2013) Me.imgSort.PictureData = Forms("frmScheduling")("imgDescending").PictureData Perhaps reading in the binary stream to a variable and setting an image control .PictureData property. I'm not certain about how savy Access is in interpreting the content of the picture data. I've been setting image controls on the fly for quite some time and have done some parsing of the binary data to read pixel row/col counts and rgb values based on various colour depths and I have a pretty slick VB class for dealing with EXIF data from camera based images. Without access to an example of the bitstream data, which varies with the image format, i've run into a dead end on this one. Ciao J?rgen Welz Edmonton, Alberta From davidmcafee at gmail.com Thu May 14 17:38:57 2015 From: davidmcafee at gmail.com (David McAfee) Date: Thu, 14 May 2015 15:38:57 -0700 Subject: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? Message-ID: I have an Excel file that I copy contents from five different queries into five different worksheets in the same Excel file/workbook. The column headers for the worksheets have certain formatting and word wrapping, so I figured it was easier to take an existing workbook, rename it as a template then paste (through access VBA) the query contents into each worksheet. One worksheet, a summary sheet, is always 30 rows and 10 columns of data. Row 1 is the fancy, word wrapped and formatted row. Row 30 is the sum of data (rows 2-29 for columns B-J). It is easier to insert a blank row in row 2, paste my (28 rows of data and one row of header) data in cell A2, format the data (grid, number format) then delete row 2, leaving the formatted header row. I ran the Excel Macro recorder to see how to do this in Excel, but I'd like to do it all from within Access. Any thoughts which is easier to do? Should I save the first and second sections as separate macros and run the macros from Access? Or do I manipulate the excel file with (early, or) late binding through VBA? The reason I am trying to do this all from within Access is that I am trying to automate a bunch of manual processes to hand them off to someone else to run. Here are my macro steps:: 'Insert Blank Row, to deal with header row Rows("2:2").Select Selection.Insert Shift:=xlDown, CopyOrigin:=xlFormatFromLeftOrAbove Range("A2").Select '***************Access Section ********* 'Run Query in MS Access 'Select All data using Ctrl+A 'Copy Query Data to clipboard '************************************** 'Paste into cell A2: ActiveSheet.Paste 'Format Active Cells with grid: Selection.Borders(xlDiagonalDown).LineStyle = xlNone Selection.Borders(xlDiagonalUp).LineStyle = xlNone With Selection.Borders(xlEdgeLeft) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeTop) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeBottom) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeRight) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlInsideVertical) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlInsideHorizontal) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With 'Add comma to number format: Selection.Style = "Comma" 'Get rid of cents: Selection.NumberFormat = "_(* #,##0.0_);_(* (#,##0.0);_(* ""-""??_);_(@_)" Selection.NumberFormat = "_(* #,##0_);_(* (#,##0);_(* ""-""??_);_(@_)" 'Delete the 2nd Header row: Rows("2:2").Select Selection.Delete Shift:=xlUp From stuart at lexacorp.com.pg Thu May 14 19:35:08 2015 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Fri, 15 May 2015 10:35:08 +1000 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> Message-ID: <55553F3C.26660.1FD289DE@stuart.lexacorp.com.pg> For similarity matches, Hamming Distance is a good metric. I've got some code somewhere that I wrote many years ago but can't find it at the moment. You may be able to cannibalise something from the code here: http://www.freevbcode.com/ShowCode.asp?ID=8613 -- Stuart On 14 May 2015 at 13:47, Darren wrote: > Hi Team > I appreciate this may trigger a right vs. wrong discussion. All > comments appreciated but this is for a Pro-Bono Project so there are > no funds and my time is not infinite. So a perfect solution is not > required. Just a working one :-) So... I have inherited a dB with > approx 12K names and addresses for a community project I am working > on. Data entry has been on home built Access dBs and Excel > spreadsheets and data veracity is poor. I can easily identify nearly > 1000 records with same first and last names so there appear to be a > lot of duplicate entries. We will handle that and will sanitise the > old data. However does anyone have a quick and easy "test" where I can > quickly check completed names (First and Last) once entered, to see if > we have exact or similar matches already in the dB? I really would > like the same thing with addresses? I have Googled and I have seen > some very complex weighting routines etc - Too tricky for me and > beyond the scope of this project (and my skill set). I just need to > present the users with a list of exact matches (I can do that now) and > some potentials, in a list that they can then decide if it's ok to > proceed or not. Many thanks in advance. Darren. -- AccessD mailing > list AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd Website: > http://www.databaseadvisors.com > From darryl at whittleconsulting.com.au Thu May 14 20:07:04 2015 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Fri, 15 May 2015 01:07:04 +0000 Subject: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? In-Reply-To: References: Message-ID: The pesky answer is "It depends". I always try to keep the Excel code in Excel, but that works for me as I will call an Excel template with all the necessary code (in Excel) from Access. This Excel template has a single starting module (I usually call it "RunMe" or "RunFromAccess". Then Access can do it's thing and when it is ready you can open the Excel template and run the code in Excel. There are few advantages to doing this. Firstly you can build all of the Excel side of the code without needing to invoke Access first, this is handy for build and debugging. It also means you can update the Excel workbook (which in my case is usually for reporting) without having to update the Access FE. I prefer it that way, but it is horse for courses. There are advantage to building everything on the fly to. Sample of some Access code to give you the idea. Set fso = CreateObject("Scripting.FileSystemObject") 'Copy the Source file into the target path and filename fso.copyfile strSourcePathAndName, strTargetPathAndName Set objExcelApp = CreateObject("Excel.Application") objExcelApp.Visible = True With objExcelApp .Workbooks.Open FileName:=strTargetPathAndName Set objExcelWB = objExcelApp.ActiveWorkbook With objExcelWB.Worksheets("Lookups") .Range("xlnrDB_Parent").Value = CurrentDb.Name .Range("xlnrDetailedReports").Value = gbDetailedReports .Range("xlnrSummaryReports").Value = gbSummaryReports .Range("xlnrBulkCosts").Value = gbBulkCostRpts .Range("xlnrLimitsOnly").Value = gbLimitsOnly .Range("xlnrExpSeq").Value = gbExpSeq .Range("xlnrSeqRptsOnly").Value = gbSeqOnly .Range("xlnrSeqRptsMiningOnly").Value = gbSeqOnlyMining .Range("xlnrSeqRptsDSOnly").Value = gbSeqOnlyDS .Range("xlnrIncludeStockpile").Value = gbIncSP End With DoEvents .Run "RunMe" '<----- THIS RUNS THE MS EXCEL CODE NATIVELY FROM EXCEL DoEvents ' Blah blah blah.... Cheers Darryl. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David McAfee Sent: Friday, 15 May 2015 8:39 AM To: Access Developers discussion and problem solving Subject: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? I have an Excel file that I copy contents from five different queries into five different worksheets in the same Excel file/workbook. The column headers for the worksheets have certain formatting and word wrapping, so I figured it was easier to take an existing workbook, rename it as a template then paste (through access VBA) the query contents into each worksheet. One worksheet, a summary sheet, is always 30 rows and 10 columns of data. Row 1 is the fancy, word wrapped and formatted row. Row 30 is the sum of data (rows 2-29 for columns B-J). It is easier to insert a blank row in row 2, paste my (28 rows of data and one row of header) data in cell A2, format the data (grid, number format) then delete row 2, leaving the formatted header row. I ran the Excel Macro recorder to see how to do this in Excel, but I'd like to do it all from within Access. Any thoughts which is easier to do? Should I save the first and second sections as separate macros and run the macros from Access? Or do I manipulate the excel file with (early, or) late binding through VBA? The reason I am trying to do this all from within Access is that I am trying to automate a bunch of manual processes to hand them off to someone else to run. Here are my macro steps:: 'Insert Blank Row, to deal with header row Rows("2:2").Select Selection.Insert Shift:=xlDown, CopyOrigin:=xlFormatFromLeftOrAbove Range("A2").Select '***************Access Section ********* 'Run Query in MS Access 'Select All data using Ctrl+A 'Copy Query Data to clipboard '************************************** 'Paste into cell A2: ActiveSheet.Paste 'Format Active Cells with grid: Selection.Borders(xlDiagonalDown).LineStyle = xlNone Selection.Borders(xlDiagonalUp).LineStyle = xlNone With Selection.Borders(xlEdgeLeft) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeTop) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeBottom) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeRight) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlInsideVertical) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlInsideHorizontal) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With 'Add comma to number format: Selection.Style = "Comma" 'Get rid of cents: Selection.NumberFormat = "_(* #,##0.0_);_(* (#,##0.0);_(* ""-""??_);_(@_)" Selection.NumberFormat = "_(* #,##0_);_(* (#,##0);_(* ""-""??_);_(@_)" 'Delete the 2nd Header row: Rows("2:2").Select Selection.Delete Shift:=xlUp -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From darryl at whittleconsulting.com.au Thu May 14 20:18:36 2015 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Fri, 15 May 2015 01:18:36 +0000 Subject: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? In-Reply-To: References: Message-ID: David, Whilst on this, I strongly recommend you get rid of all the "Activesheet" and "Select" from you code. Be explicit, otherwise you will come undone, and badly too, at some point. I have clean up the code below (quickly and it is a bit 'aircode' but you get the idea. Dim xlshtTarget as Excel.Worksheet Application.screenupdating = false Set xlshtTarget = Sheet1 '(using sheet1 as the sheet CODE name, not the sheet name, although you can use either) xlshtTarget. Rows("2:2").Insert Shift:=xlDown ' HERE YOU WANT TO USE 'CopyFromRecordset' TO AUTOMATE THIS. '***************Access Section ********* 'Run Query in MS Access 'Select All data using Ctrl+A 'Copy Query Data to clipboard '************************************** 'Paste into cell A2: xlshtTarget.Range("A2").Paste application.cutcopymode = false 'empties the clipboard 'Format Active Cells with grid: Selection.Borders(xlDiagonalDown).LineStyle = xlNone Selection.Borders(xlDiagonalUp).LineStyle = xlNone With Selection.Borders(xlEdgeLeft) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeTop) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeBottom) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeRight) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlInsideVertical) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlInsideHorizontal) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With 'Add comma to number format: Selection.Style = "Comma" 'Get rid of cents: Selection.NumberFormat = "_(* #,##0_);_(* (#,##0);_(* ""-""??_);_(@_)" 'Delete the 2nd Header row: xlshtTarget. Rows("2:2").Rows("2:2").Delete Shift:=xlUp -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David McAfee Sent: Friday, 15 May 2015 8:39 AM To: Access Developers discussion and problem solving Subject: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? I have an Excel file that I copy contents from five different queries into five different worksheets in the same Excel file/workbook. The column headers for the worksheets have certain formatting and word wrapping, so I figured it was easier to take an existing workbook, rename it as a template then paste (through access VBA) the query contents into each worksheet. One worksheet, a summary sheet, is always 30 rows and 10 columns of data. Row 1 is the fancy, word wrapped and formatted row. Row 30 is the sum of data (rows 2-29 for columns B-J). It is easier to insert a blank row in row 2, paste my (28 rows of data and one row of header) data in cell A2, format the data (grid, number format) then delete row 2, leaving the formatted header row. I ran the Excel Macro recorder to see how to do this in Excel, but I'd like to do it all from within Access. Any thoughts which is easier to do? Should I save the first and second sections as separate macros and run the macros from Access? Or do I manipulate the excel file with (early, or) late binding through VBA? The reason I am trying to do this all from within Access is that I am trying to automate a bunch of manual processes to hand them off to someone else to run. Here are my macro steps:: 'Insert Blank Row, to deal with header row Rows("2:2").Select Selection.Insert Shift:=xlDown, CopyOrigin:=xlFormatFromLeftOrAbove Range("A2").Select '***************Access Section ********* 'Run Query in MS Access 'Select All data using Ctrl+A 'Copy Query Data to clipboard '************************************** 'Paste into cell A2: ActiveSheet.Paste 'Format Active Cells with grid: Selection.Borders(xlDiagonalDown).LineStyle = xlNone Selection.Borders(xlDiagonalUp).LineStyle = xlNone With Selection.Borders(xlEdgeLeft) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeTop) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeBottom) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlEdgeRight) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlInsideVertical) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With With Selection.Borders(xlInsideHorizontal) .LineStyle = xlContinuous .ColorIndex = 0 .TintAndShade = 0 .Weight = xlThin End With 'Add comma to number format: Selection.Style = "Comma" 'Get rid of cents: Selection.NumberFormat = "_(* #,##0.0_);_(* (#,##0.0);_(* ""-""??_);_(@_)" Selection.NumberFormat = "_(* #,##0_);_(* (#,##0);_(* ""-""??_);_(@_)" 'Delete the 2nd Header row: Rows("2:2").Select Selection.Delete Shift:=xlUp -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From bensonforums at gmail.com Fri May 15 03:26:16 2015 From: bensonforums at gmail.com (Bill Benson) Date: Fri, 15 May 2015 04:26:16 -0400 Subject: [AccessD] Fwd: Re: Is it better to call Excel Macro from access, or manipulate from Access? In-Reply-To: References: Message-ID: Some opinions from additional excel experts David. I also by just gut feeling would have coded this from Access. On the flip side I might have treated Access like a backend and written similar queries and transformations you might be running in Access with ADO and put the project in Excel, if possible. ---------- Forwarded message ---------- From: "John Nurick" Date: May 15, 2015 4:22 AM Subject: Re: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? To: Cc: +1. Also, to my tidy mind it always feels neater to have all the code in the same project (not counting add-ins). -----Original Message----- From: Microsoft Excel Developers List [mailto:EXCEL-L at PEACH.EASE.LSOFT.COM] On Behalf Of Rory Archibald Sent: 15 May 2015 09:18 To: EXCEL-L at PEACH.EASE.LSOFT.COM Subject: Re: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? Unless there is a need for the macros to exist in Excel (e.g. they may need to be run again separately to the original Access processing) I see no benefit in having them in Excel. I'd do everything in Access. The process itself sounds unnecessarily complicated to me - a simple CopyFromRecordset would avoid the need for creating and deleting header rows altogether. -------------------------------------------------------------------------- The EXCEL-L list is hosted on L-Soft international's LISTSERV(R) software running on Microsoft Windows Server 2008 R2. For subscription/signoff info and archives, see http://peach.ease.lsoft.com/archives/excel-l.html . COPYRIGHT INFO: http://peach.ease.lsoft.com/scripts/wa.exe?SHOWTPL=COPYRIGHT&L=EXCEL-L From bensonforums at gmail.com Fri May 15 09:26:22 2015 From: bensonforums at gmail.com (Bill Benson) Date: Fri, 15 May 2015 10:26:22 -0400 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: <9259EDA484B148448AEAC1EEFF70B811@XPS> References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> <9259EDA484B148448AEAC1EEFF70B811@XPS> Message-ID: Jim Debtman I would add to a "collection" which if a duplicate would produce an error. But seriously that is one reason I like collections, they error out on duplicates. If you write a routine that compresses (trims and removes spaces) then adds to a collection, then any duplicates (err.number<>0) means that the duplicate should be written to a duplicates table. You can also start instantiate and add to a counter collection for all erroring items, with the compressed fullname as the key, and with each new error (with error handling still set to On Error Resume Next), read any current value for the countercollection based on the key, add 1 to it, remove the item (if it's not there, this won't hurt), and add it back incremented by 1 ... so that when you are done with this routine you have 1 collection which is a list of all duplicates, and a second collection which is a series containing the number of duplicates per value. Then run a count from 1 to col.count, and append to a table of duplicates that has 2 columns, the 1st comes from colNames and the 2nd comes from colCounter(colNames(i)) Then run a query any time you want where the compressed name contatenation from the data list equals a value in this table and you have all records that duplicated. Even with several thousand names to create and maintain this list of duplicates would take seconds, not minutes. On Thu, May 14, 2015 at 7:35 AM, Jim Dettman wrote: > > Depends on what the goal is. If it's only to check for exact matches, > then > a collapse of the strings involved (removing all white space) and > concatenated against an index suffices. > > If it's more of a "fuzzy" type of analysis that you want to use, then there > are various approaches, like soundex (i.e. One name is "Jim Dettman" vs > "Jim Debtman"). > > Weighting would be throwing in comparing the different components, name vs > address. > > On a straight compare though, I've always fully collapsed the strings, then > do a find on an index. > > Jim. > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > Darren > Sent: Wednesday, May 13, 2015 11:47 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] A2003: Checking for Similar Names and or Addresses > > Hi Team > I appreciate this may trigger a right vs. wrong discussion. All comments > appreciated but this is for a Pro-Bono Project so there are no funds and my > time is not infinite. > So a perfect solution is not required. Just a working one :-) > So... > I have inherited a dB with approx 12K names and addresses for a community > project I am working on. > Data entry has been on home built Access dBs and Excel spreadsheets and > data > veracity is poor. > I can easily identify nearly 1000 records with same first and last names so > there appear to be a lot of duplicate entries. > We will handle that and will sanitise the old data. However does anyone > have > a quick and easy "test" where I can quickly check completed names (First > and > Last) once entered, to see if we have exact or similar matches already in > the dB? > I really would like the same thing with addresses? > I have Googled and I have seen some very complex weighting routines etc - > Too tricky for me and beyond the scope of this project (and my skill set). > I just need to present the users with a list of exact matches (I can do > that > now) and some potentials, in a list that they can then decide if it's ok to > proceed or not. > Many thanks in advance. > Darren. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From jwcolby at gmail.com Fri May 15 10:02:54 2015 From: jwcolby at gmail.com (John W. Colby) Date: Fri, 15 May 2015 11:02:54 -0400 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> <9259EDA484B148448AEAC1EEFF70B811@XPS> Message-ID: <55560A9E.5080608@gmail.com> I would like to interject here that while this is fine and a worthwhile method to use in some cases (and I LOVE collections!!!), it won't scale well. I was faced with dealing with 220 MILLION records, essentially every name / address in the US (well close). Using set based (query) methods was the only solution. As you can imagine, trying to do that in code will simply never complete. Even doing it in SQL will take awhile. That is why I did all the preliminaries discussed, such as preprocessing (one time and stored) to remove padding left and right etc. Once that is done then using a hash, calculated once and stored, allows you to index on that hash and then self join on the hash to find duplicates. Doing a groupby (on the hash) and count (on the hash or PK) allows you to filter on only the hashes with duplicates - WHERE Cnt > 1. Then you can store that query (exposing the hash) and join it back to the table on the hash to pull all the duplicate records. Sort by hash, then by whatever suites your fancy (LName / FName) to actually see and take care of duplicates. I build a 1) HashPerson: FNameLNameAddrZip5Zip4 2) HashFamily: LNameAddrZip5Zip4 3) HashAddr: AddrZip5Zip4 Notice that in the US at least, city and state are not required since Zip5 and Zip4 get you there. In fact it gets rid of a bunch of ambiguity (in the US) since the city can be called several different things, but regardless of what the city field contains, the zip5 / zip4 is identical. Using these hashes allows me to then select all records at a given address, all records with the same last name at a given address, or just individuals. Because the hash is calced and stored, I can index the hash and joins on the hash works very fast. Additionally, given this method I can have different databases (and I do) where I can pull matching records from the different databases. For example I have a database of : 1) People with dogs and cats. 2) People with children with child age fields 3) People with boats 4) People with a TON of various demographics info. So I can join the dogs and cats to the kids database on person to get EXACT people matches. Or I can join Family hashes to get people in the same family that have kids and dogs or cats. Or Families with kids and boats, or Kids and boats and dogs. This method of using hashes has made the process of matching up families and people across databases possible, and actually quite trivial. And FAST! Ok, fastER. Joining a 220 million record database with a 110 million record database still takes time, but at least it is possible. It just can't be done with code. And finally, I recognize that the OP said it was all done in Access. However SQL Server is free for us developers and so getting the hashes calculated, and in fact all this processing (on a one time basis) can be done on SQL Server and written back to Access. And probably much faster, both in development and certainly in processing, than trying to develop code to do it in Access. John W. Colby On 5/15/2015 10:26 AM, Bill Benson wrote: > Jim Debtman I would add to a "collection" which if a duplicate would > produce an error. > But seriously that is one reason I like collections, they error out on > duplicates. > If you write a routine that compresses (trims and removes spaces) then adds > to a collection, then any duplicates (err.number<>0) means that the > duplicate should be written to a duplicates table. > You can also start instantiate and add to a counter collection for all > erroring items, with the compressed fullname as the key, and with each new > error (with error handling still set to On Error Resume Next), read any > current value for the countercollection based on the key, add 1 to it, > remove the item (if it's not there, this won't hurt), and add it back > incremented by 1 ... so that when you are done with this routine you have 1 > collection which is a list of all duplicates, and a second collection which > is a series containing the number of duplicates per value. Then run a count > from 1 to col.count, and append to a table of duplicates that has 2 > columns, the 1st comes from colNames and the 2nd comes from > colCounter(colNames(i)) > > Then run a query any time you want where the compressed name contatenation > from the data list equals a value in this table and you have all records > that duplicated. > > Even with several thousand names to create and maintain this list of > duplicates would take seconds, not minutes. > From davidmcafee at gmail.com Fri May 15 11:27:26 2015 From: davidmcafee at gmail.com (David McAfee) Date: Fri, 15 May 2015 09:27:26 -0700 Subject: [AccessD] Fwd: Re: Is it better to call Excel Macro from access, or manipulate from Access? In-Reply-To: References: Message-ID: I want to keep it in Access because the report is just one step of many that are ran from a menu system that I made. I really am trying to dumb it down for the user as much as possible. Press a button and a nicely formatted Excel file is placed in a certain directory. Last night, I did find some useful links: http://datapigtechnologies.com/blog/index.php/running-an-excel-macro-from-access-or-another-excel-workbook/ http://bytes.com/topic/access/answers/902069-export-queries-excel-specific-sheet-specific-range http://www.access-programmers.co.uk/forums/showthread.php?t=249829 I think I can piece together something over the weekend that resembles a rube-goldberg project :P Thanks again, David On Fri, May 15, 2015 at 1:26 AM, Bill Benson wrote: > Some opinions from additional excel experts David. I also by just gut > feeling would have coded this from Access. > > On the flip side I might have treated Access like a backend and written > similar queries and transformations you might be running in Access with ADO > and put the project in Excel, if possible. > ---------- Forwarded message ---------- > From: "John Nurick" > Date: May 15, 2015 4:22 AM > Subject: Re: [AccessD] Is it better to call Excel Macro from access, or > manipulate from Access? > To: > Cc: > > +1. Also, to my tidy mind it always feels neater to have all the code in > the > same project (not counting add-ins). > > -----Original Message----- > From: Microsoft Excel Developers List [mailto:EXCEL-L at PEACH.EASE.LSOFT.COM > ] > On Behalf Of Rory Archibald > Sent: 15 May 2015 09:18 > To: EXCEL-L at PEACH.EASE.LSOFT.COM > Subject: Re: [AccessD] Is it better to call Excel Macro from access, or > manipulate from Access? > > Unless there is a need for the macros to exist in Excel (e.g. they may need > to be run again separately to the original Access processing) I see no > benefit in having them in Excel. I'd do everything in Access. The process > itself sounds unnecessarily complicated to me - a simple CopyFromRecordset > would avoid the need for creating and deleting header rows altogether. > > -------------------------------------------------------------------------- > The EXCEL-L list is hosted on L-Soft international's LISTSERV(R) software > running on Microsoft Windows Server 2008 R2. For subscription/signoff info > and archives, see http://peach.ease.lsoft.com/archives/excel-l.html . > COPYRIGHT INFO: > http://peach.ease.lsoft.com/scripts/wa.exe?SHOWTPL=COPYRIGHT&L=EXCEL-L > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From dw-murphy at cox.net Fri May 15 11:40:21 2015 From: dw-murphy at cox.net (Doug Murphy) Date: Fri, 15 May 2015 09:40:21 -0700 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> <9259EDA484B148448AEAC1EEFF70B811@XPS> Message-ID: <006b01d08f2d$d587a000$8096e000$@cox.net> HI John, I am trying to learn here. Why is hashing better that concatenating the same fields and using as you are doing with your hashes? Doug -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Friday, May 15, 2015 8:03 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] A2003: Checking for Similar Names and or Addresses I would like to interject here that while this is fine and a worthwhile method to use in some cases (and I LOVE collections!!!), it won't scale well. I was faced with dealing with 220 MILLION records, essentially every name / address in the US (well close). Using set based (query) methods was the only solution. As you can imagine, trying to do that in code will simply never complete. Even doing it in SQL will take awhile. That is why I did all the preliminaries discussed, such as preprocessing (one time and stored) to remove padding left and right etc. Once that is done then using a hash, calculated once and stored, allows you to index on that hash and then self join on the hash to find duplicates. Doing a groupby (on the hash) and count (on the hash or PK) allows you to filter on only the hashes with duplicates - WHERE Cnt > 1. Then you can store that query (exposing the hash) and join it back to the table on the hash to pull all the duplicate records. Sort by hash, then by whatever suites your fancy (LName / FName) to actually see and take care of duplicates. I build a 1) HashPerson: FNameLNameAddrZip5Zip4 2) HashFamily: LNameAddrZip5Zip4 3) HashAddr: AddrZip5Zip4 Notice that in the US at least, city and state are not required since Zip5 and Zip4 get you there. In fact it gets rid of a bunch of ambiguity (in the US) since the city can be called several different things, but regardless of what the city field contains, the zip5 / zip4 is identical. Using these hashes allows me to then select all records at a given address, all records with the same last name at a given address, or just individuals. Because the hash is calced and stored, I can index the hash and joins on the hash works very fast. Additionally, given this method I can have different databases (and I do) where I can pull matching records from the different databases. For example I have a database of : 1) People with dogs and cats. 2) People with children with child age fields 3) People with boats 4) People with a TON of various demographics info. So I can join the dogs and cats to the kids database on person to get EXACT people matches. Or I can join Family hashes to get people in the same family that have kids and dogs or cats. Or Families with kids and boats, or Kids and boats and dogs. This method of using hashes has made the process of matching up families and people across databases possible, and actually quite trivial. And FAST! Ok, fastER. Joining a 220 million record database with a 110 million record database still takes time, but at least it is possible. It just can't be done with code. And finally, I recognize that the OP said it was all done in Access. However SQL Server is free for us developers and so getting the hashes calculated, and in fact all this processing (on a one time basis) can be done on SQL Server and written back to Access. And probably much faster, both in development and certainly in processing, than trying to develop code to do it in Access. John W. Colby On 5/15/2015 10:26 AM, Bill Benson wrote: > Jim Debtman I would add to a "collection" which if a duplicate would > produce an error. > But seriously that is one reason I like collections, they error out on > duplicates. > If you write a routine that compresses (trims and removes spaces) then > adds to a collection, then any duplicates (err.number<>0) means that > the duplicate should be written to a duplicates table. > You can also start instantiate and add to a counter collection for all > erroring items, with the compressed fullname as the key, and with each > new error (with error handling still set to On Error Resume Next), > read any current value for the countercollection based on the key, add > 1 to it, remove the item (if it's not there, this won't hurt), and add > it back incremented by 1 ... so that when you are done with this > routine you have 1 collection which is a list of all duplicates, and a > second collection which is a series containing the number of > duplicates per value. Then run a count from 1 to col.count, and append > to a table of duplicates that has 2 columns, the 1st comes from > colNames and the 2nd comes from > colCounter(colNames(i)) > > Then run a query any time you want where the compressed name > contatenation from the data list equals a value in this table and you > have all records that duplicated. > > Even with several thousand names to create and maintain this list of > duplicates would take seconds, not minutes. > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jwcolby at gmail.com Fri May 15 11:48:50 2015 From: jwcolby at gmail.com (John W. Colby) Date: Fri, 15 May 2015 12:48:50 -0400 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: <006b01d08f2d$d587a000$8096e000$@cox.net> References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> <9259EDA484B148448AEAC1EEFF70B811@XPS> <006b01d08f2d$d587a000$8096e000$@cox.net> Message-ID: <55562372.2000401@gmail.com> It isn't clear that it always is. A hash is a fixed length string. So you exchange a variable length string for a (typically but not always shorter) fixed length string, but you give up readability. The longer the concatenated string, the more likely the storage, indexing and comparisons of hashes will win. In any event you want to calc the string (hash or straight concatenation) store and index it. John W. Colby On 5/15/2015 12:40 PM, Doug Murphy wrote: > HI John, > > I am trying to learn here. Why is hashing better that concatenating the same > fields and using as you are doing with your hashes? > > Doug > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > John W. Colby > Sent: Friday, May 15, 2015 8:03 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] A2003: Checking for Similar Names and or Addresses > > I would like to interject here that while this is fine and a worthwhile > method to use in some cases (and I LOVE collections!!!), it won't scale > well. I was faced with dealing with 220 MILLION records, essentially every > name / address in the US (well close). Using set based (query) methods was > the only solution. As you can imagine, trying to do that in code will > simply never complete. Even doing it in SQL will take awhile. > > That is why I did all the preliminaries discussed, such as preprocessing > (one time and stored) to remove padding left and right etc. Once that is > done then using a hash, calculated once and stored, allows you to index on > that hash and then self join on the hash to find duplicates. > Doing a groupby (on the hash) and count (on the hash or PK) allows you to > filter on only the hashes with duplicates - WHERE Cnt > 1. Then you can > store that query (exposing the hash) and join it back to the table on the > hash to pull all the duplicate records. Sort by hash, then by whatever > suites your fancy (LName / FName) to actually see and take care of > duplicates. > > I build a > > 1) HashPerson: FNameLNameAddrZip5Zip4 > 2) HashFamily: LNameAddrZip5Zip4 > 3) HashAddr: AddrZip5Zip4 > > Notice that in the US at least, city and state are not required since > Zip5 and Zip4 get you there. In fact it gets rid of a bunch of ambiguity > (in the US) since the city can be called several different things, but > regardless of what the city field contains, the zip5 / zip4 is identical. > > Using these hashes allows me to then select all records at a given address, > all records with the same last name at a given address, or just individuals. > > Because the hash is calced and stored, I can index the hash and joins on the > hash works very fast. > > Additionally, given this method I can have different databases (and I > do) where I can pull matching records from the different databases. For > example I have a database of : > > 1) People with dogs and cats. > 2) People with children with child age fields > 3) People with boats > 4) People with a TON of various demographics info. > > So I can join the dogs and cats to the kids database on person to get EXACT > people matches. Or I can join Family hashes to get people in the same > family that have kids and dogs or cats. Or Families with kids and boats, or > Kids and boats and dogs. > > This method of using hashes has made the process of matching up families and > people across databases possible, and actually quite trivial. And FAST! > Ok, fastER. Joining a 220 million record database with a 110 million record > database still takes time, but at least it is possible. > It just can't be done with code. > > And finally, I recognize that the OP said it was all done in Access. > However SQL Server is free for us developers and so getting the hashes > calculated, and in fact all this processing (on a one time basis) can be > done on SQL Server and written back to Access. And probably much faster, > both in development and certainly in processing, than trying to develop code > to do it in Access. > > John W. Colby > > On 5/15/2015 10:26 AM, Bill Benson wrote: >> Jim Debtman I would add to a "collection" which if a duplicate would >> produce an error. >> But seriously that is one reason I like collections, they error out on >> duplicates. >> If you write a routine that compresses (trims and removes spaces) then >> adds to a collection, then any duplicates (err.number<>0) means that >> the duplicate should be written to a duplicates table. >> You can also start instantiate and add to a counter collection for all >> erroring items, with the compressed fullname as the key, and with each >> new error (with error handling still set to On Error Resume Next), >> read any current value for the countercollection based on the key, add >> 1 to it, remove the item (if it's not there, this won't hurt), and add >> it back incremented by 1 ... so that when you are done with this >> routine you have 1 collection which is a list of all duplicates, and a >> second collection which is a series containing the number of >> duplicates per value. Then run a count from 1 to col.count, and append >> to a table of duplicates that has 2 columns, the 1st comes from >> colNames and the 2nd comes from >> colCounter(colNames(i)) >> >> Then run a query any time you want where the compressed name >> contatenation from the data list equals a value in this table and you >> have all records that duplicated. >> >> Even with several thousand names to create and maintain this list of >> duplicates would take seconds, not minutes. >> > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From dw-murphy at cox.net Fri May 15 12:43:14 2015 From: dw-murphy at cox.net (Doug Murphy) Date: Fri, 15 May 2015 10:43:14 -0700 Subject: [AccessD] A2003: Checking for Similar Names and or Addresses In-Reply-To: References: <31B0480D1D5C4F038F65F3122A4FD25D@DDNote> <9259EDA484B148448AEAC1EEFF70B811@XPS> <006b01d08f2d$d587a000$8096e000$@cox.net> Message-ID: <008a01d08f36$9ea1e380$dbe5aa80$@cox.net> OK, thank you. For the size of project I typically work on concatenation would probably suffice. Doug -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Friday, May 15, 2015 9:49 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] A2003: Checking for Similar Names and or Addresses It isn't clear that it always is. A hash is a fixed length string. So you exchange a variable length string for a (typically but not always shorter) fixed length string, but you give up readability. The longer the concatenated string, the more likely the storage, indexing and comparisons of hashes will win. In any event you want to calc the string (hash or straight concatenation) store and index it. John W. Colby On 5/15/2015 12:40 PM, Doug Murphy wrote: > HI John, > > I am trying to learn here. Why is hashing better that concatenating > the same fields and using as you are doing with your hashes? > > Doug > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of John W. Colby > Sent: Friday, May 15, 2015 8:03 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] A2003: Checking for Similar Names and or > Addresses > > I would like to interject here that while this is fine and a > worthwhile method to use in some cases (and I LOVE collections!!!), it > won't scale well. I was faced with dealing with 220 MILLION records, > essentially every name / address in the US (well close). Using set > based (query) methods was the only solution. As you can imagine, > trying to do that in code will simply never complete. Even doing it in SQL will take awhile. > > That is why I did all the preliminaries discussed, such as > preprocessing (one time and stored) to remove padding left and right > etc. Once that is done then using a hash, calculated once and stored, > allows you to index on that hash and then self join on the hash to find duplicates. > Doing a groupby (on the hash) and count (on the hash or PK) allows you > to filter on only the hashes with duplicates - WHERE Cnt > 1. Then > you can store that query (exposing the hash) and join it back to the > table on the hash to pull all the duplicate records. Sort by hash, > then by whatever suites your fancy (LName / FName) to actually see and > take care of duplicates. > > I build a > > 1) HashPerson: FNameLNameAddrZip5Zip4 > 2) HashFamily: LNameAddrZip5Zip4 > 3) HashAddr: AddrZip5Zip4 > > Notice that in the US at least, city and state are not required since > Zip5 and Zip4 get you there. In fact it gets rid of a bunch of > ambiguity (in the US) since the city can be called several different > things, but regardless of what the city field contains, the zip5 / zip4 is identical. > > Using these hashes allows me to then select all records at a given > address, all records with the same last name at a given address, or just individuals. > > Because the hash is calced and stored, I can index the hash and joins > on the hash works very fast. > > Additionally, given this method I can have different databases (and I > do) where I can pull matching records from the different databases. > For example I have a database of : > > 1) People with dogs and cats. > 2) People with children with child age fields > 3) People with boats > 4) People with a TON of various demographics info. > > So I can join the dogs and cats to the kids database on person to get > EXACT people matches. Or I can join Family hashes to get people in > the same family that have kids and dogs or cats. Or Families with > kids and boats, or Kids and boats and dogs. > > This method of using hashes has made the process of matching up > families and people across databases possible, and actually quite trivial. And FAST! > Ok, fastER. Joining a 220 million record database with a 110 million > record database still takes time, but at least it is possible. > It just can't be done with code. > > And finally, I recognize that the OP said it was all done in Access. > However SQL Server is free for us developers and so getting the hashes > calculated, and in fact all this processing (on a one time basis) can > be done on SQL Server and written back to Access. And probably much > faster, both in development and certainly in processing, than trying > to develop code to do it in Access. > > John W. Colby > > On 5/15/2015 10:26 AM, Bill Benson wrote: >> Jim Debtman I would add to a "collection" which if a duplicate would >> produce an error. >> But seriously that is one reason I like collections, they error out >> on duplicates. >> If you write a routine that compresses (trims and removes spaces) >> then adds to a collection, then any duplicates (err.number<>0) means >> that the duplicate should be written to a duplicates table. >> You can also start instantiate and add to a counter collection for >> all erroring items, with the compressed fullname as the key, and with >> each new error (with error handling still set to On Error Resume >> Next), read any current value for the countercollection based on the >> key, add >> 1 to it, remove the item (if it's not there, this won't hurt), and >> add it back incremented by 1 ... so that when you are done with this >> routine you have 1 collection which is a list of all duplicates, and >> a second collection which is a series containing the number of >> duplicates per value. Then run a count from 1 to col.count, and >> append to a table of duplicates that has 2 columns, the 1st comes >> from colNames and the 2nd comes from >> colCounter(colNames(i)) >> >> Then run a query any time you want where the compressed name >> contatenation from the data list equals a value in this table and you >> have all records that duplicated. >> >> Even with several thousand names to create and maintain this list of >> duplicates would take seconds, not minutes. >> > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > 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 Fri May 15 13:22:11 2015 From: davidmcafee at gmail.com (David McAfee) Date: Fri, 15 May 2015 11:22:11 -0700 Subject: [AccessD] Looping through queries over and over Message-ID: So I have to come up with a report that shows an ongoing loss of insurance. I would really like to do this on the fly. Each week, we process a batch of records and those are stored with their batch name. Sample batch names: Month Begin 20150105 Month Week2 20150112 Month Week3 20150120 Month End 20150126 Month Begin 20150203 Month Week2 20150209 Month Week3 20150216 Month End 20150223 Starting in Week2, I compare Week 2 to Week 1 (Month Begin) where Week1.Insuranceflag =1 and Week2.Insuranceflag =0. Easy. On week 3, I compare week 3 vs wk 2 loss (new loss) plus any losses from the previous week that are still 0. I wrote a stored procedure where I pass it the batch names: EXEC stpLossOfMediCalDetail 'Month Begin 20150105','Month Week2 20150112' I can insert those results into a table variable, but I'm thinking I need two temp tables. One to hold the cumulative (new loss) records and another to temporarily hold the results comparing week 2 to week 1 then left join those back to the cumulative table and delete any records that don't exist in both tables. Then do that over and over. I don't know how my little text grid will display after being emailed: Month1 Month2 W1 W2 W3 W4 W5 W6 W7 W8 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 Am I over complicating this? :) I hope I don't scare any Non SQL folk off, I could do this with VBA & Queries instead of Cursors and TSQL. I'm just trying to think of a good way to do this. From davidmcafee at gmail.com Fri May 15 15:01:09 2015 From: davidmcafee at gmail.com (David McAfee) Date: Fri, 15 May 2015 13:01:09 -0700 Subject: [AccessD] Looping through queries over and over In-Reply-To: References: Message-ID: Ok, I was able to do this in SSMS with hardcoded values, but I'd like to make it dynamic. Maybe a better question would be: Given a select query or temp table of these batchnames: Month Begin 20141202 Month Begin 20150106 Month Begin 20150203 Month Begin 20150302 Month Begin 20150403 Month Begin 20150501 How can I dynamically come up with a loop or fill a temp table to look like this: Step tableABatch1 tableABatch2 tableTBatch1 tableTBatch2 1 Month Begin 20141202 Month Begin 20150106 Month Begin 20141202 Month Begin 20150203 2 NULL NULL Month Begin 20141202 Month Begin 20150302 3 NULL NULL Month Begin 20141202 Month Begin 20150403 4 NULL NULL Month Begin 20141202 Month Begin 20150501 5 Month Begin 20150106 Month Begin 20150203 Month Begin 20150106 Month Begin 20150302 6 NULL NULL Month Begin 20150106 Month Begin 20150403 7 NULL NULL Month Begin 20150106 Month Begin 20150501 8 Month Begin 20150203 Month Begin 20150302 Month Begin 20150203 Month Begin 20150403 9 NULL NULL Month Begin 20150203 Month Begin 20150501 10 Month Begin 20150302 Month Begin 20150403 Month Begin 20150302 Month Begin 20150501 11 Month Begin 20150403 Month Begin 20150501 NULL NULL The reason that I ask is because this is what I ended up doing (manually): for steps 1-4, above The big delete statements below are identical DECLARE @TempTableA TABLE(fields....) --Cumulative table DECLARE @TempTableT TABLE(fields....) --temporary temp table :) INSERT INTO @TempTableA EXEC stpLossOfMediCalDetail 'Month Begin 20141202','Month Begin 20150106' --Step 1 above INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail 'Month Begin 20141202', 'Month Begin 20150203' --Step 1 above DELETE @TempTableA FROM @TempTableA B LEFT JOIN (SELECT A.* FROM @TempTableA A INNER JOIN @TempTableT T ON A.EligNumber =T.EligNumber AND A.AccountNumb = T.AccountNumb AND A.FirstDate = T.FirstDate) C ON B.EligNumber =C.EligNumber AND B.AccountNumb = C.AccountNumb AND B.FirstDate = C.FirstDate WHERE C.AccountNumb IS NULL AND C.FirstDate IS NULL AND C.EligNumber IS NULL DELETE FROM @TempTableT INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail 'Month Begin 20141202', 'Month Begin 20150302' --Step2 DELETE @TempTableA FROM @TempTableA B LEFT JOIN (SELECT A.* FROM @TempTableA A INNER JOIN @TempTableT T ON A.EligNumber =T.EligNumber AND A.AccountNumb = T.AccountNumb AND A.FirstDate = T.FirstDate) C ON B.EligNumber =C.EligNumber AND B.AccountNumb = C.AccountNumb AND B.FirstDate = C.FirstDate WHERE C.AccountNumb IS NULL AND C.FirstDate IS NULL AND C.EligNumber IS NULL DELETE FROM @TempTableT INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail 'Month Begin 20141202', 'Month Begin 20150403' --step3 DELETE @TempTableA FROM @TempTableA B LEFT JOIN (SELECT A.* FROM @TempTableA A INNER JOIN @TempTableT T ON A.EligNumber =T.EligNumber AND A.AccountNumb = T.AccountNumb AND A.FirstDate = T.FirstDate) C ON B.EligNumber =C.EligNumber AND B.AccountNumb = C.AccountNumb AND B.FirstDate = C.FirstDate WHERE C.AccountNumb IS NULL AND C.FirstDate IS NULL AND C.EligNumber IS NULL DELETE FROM @TempTableT INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail 'Month Begin 20141202', 'Month Begin 20150501' --step4 DELETE @TempTableA FROM @TempTableA B LEFT JOIN (SELECT A.* FROM @TempTableA A INNER JOIN @TempTableT T ON A.EligNumber =T.EligNumber AND A.AccountNumb = T.AccountNumb AND A.FirstDate = T.FirstDate) C ON B.EligNumber =C.EligNumber AND B.AccountNumb = C.AccountNumb AND B.FirstDate = C.FirstDate WHERE C.AccountNumb IS NULL AND C.FirstDate IS NULL AND C.EligNumber IS NULL SET NOCOUNT OFF SELECT * FROM @TempTableA --Final Select From fhtapia at gmail.com Fri May 15 17:48:56 2015 From: fhtapia at gmail.com (fhtapia at gmail.com) Date: Fri, 15 May 2015 22:48:56 +0000 Subject: [AccessD] [dba-SQLServer] Looping through queries over and over In-Reply-To: References: Message-ID: Hey Dave, it sounds like what you are fishing for a sql server analysis cube. since you are loading data each week by batch, that data should be processed against your analysis cube so you can run the type of reports you wish to build. not only that you can easily convert from day > week > quarter and finally annually. this then provides the business with a quick snapshot of what the patterns are. if you haven't gotten into building cubes, you can start with this walk through: http://www.codeproject.com/Articles/658912/Create-First-OLAP-Cube-in-SQL-Server-Analysis-Serv or http://www.sqlshack.com/sql-server-business-intelligence-features-olap-cube-creating/ regards, Francisco On Fri, May 15, 2015 at 1:02 PM David McAfee wrote: > Ok, I was able to do this in SSMS with hardcoded values, but I'd like to > make it dynamic. > > Maybe a better question would be: > > Given a select query or temp table of these batchnames: > Month Begin 20141202 > Month Begin 20150106 > Month Begin 20150203 > Month Begin 20150302 > Month Begin 20150403 > Month Begin 20150501 > > How can I dynamically come up with a loop or fill a temp table to look like > this: > Step tableABatch1 tableABatch2 tableTBatch1 tableTBatch2 > 1 Month Begin 20141202 Month Begin 20150106 Month Begin 20141202 Month > Begin 20150203 > 2 NULL NULL Month Begin 20141202 Month Begin 20150302 > 3 NULL NULL Month Begin 20141202 Month Begin 20150403 > 4 NULL NULL Month Begin 20141202 Month Begin 20150501 > 5 Month Begin 20150106 Month Begin 20150203 Month Begin 20150106 Month > Begin 20150302 > 6 NULL NULL Month Begin 20150106 Month Begin 20150403 > 7 NULL NULL Month Begin 20150106 Month Begin 20150501 > 8 Month Begin 20150203 Month Begin 20150302 Month Begin 20150203 Month > Begin 20150403 > 9 NULL NULL Month Begin 20150203 Month Begin 20150501 > 10 Month Begin 20150302 Month Begin 20150403 Month Begin 20150302 Month > Begin 20150501 > 11 Month Begin 20150403 Month Begin 20150501 NULL NULL > > > The reason that I ask is because this is what I ended up doing (manually): > for steps 1-4, above > The big delete statements below are identical > > DECLARE @TempTableA TABLE(fields....) --Cumulative table > DECLARE @TempTableT TABLE(fields....) --temporary temp table :) > > INSERT INTO @TempTableA EXEC stpLossOfMediCalDetail 'Month Begin > 20141202','Month Begin 20150106' --Step 1 above > INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail 'Month Begin 20141202', > 'Month Begin 20150203' --Step 1 above > > DELETE @TempTableA > FROM @TempTableA B > LEFT JOIN > (SELECT A.* > FROM @TempTableA A > INNER JOIN @TempTableT T > ON A.EligNumber =T.EligNumber > AND A.AccountNumb = T.AccountNumb > AND A.FirstDate = T.FirstDate) C > ON B.EligNumber =C.EligNumber > AND B.AccountNumb = C.AccountNumb > AND B.FirstDate = C.FirstDate > WHERE C.AccountNumb IS NULL > AND C.FirstDate IS NULL > AND C.EligNumber IS NULL > > DELETE FROM @TempTableT > > INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail 'Month Begin 20141202', > 'Month Begin 20150302' --Step2 > > DELETE @TempTableA > FROM @TempTableA B > LEFT JOIN > (SELECT A.* > FROM @TempTableA A > INNER JOIN @TempTableT T > ON A.EligNumber =T.EligNumber > AND A.AccountNumb = T.AccountNumb > AND A.FirstDate = T.FirstDate) C > ON B.EligNumber =C.EligNumber > AND B.AccountNumb = C.AccountNumb > AND B.FirstDate = C.FirstDate > WHERE C.AccountNumb IS NULL > AND C.FirstDate IS NULL > AND C.EligNumber IS NULL > > DELETE FROM @TempTableT > > INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail 'Month Begin 20141202', > 'Month Begin 20150403' --step3 > > DELETE @TempTableA > FROM @TempTableA B > LEFT JOIN > (SELECT A.* > FROM @TempTableA A > INNER JOIN @TempTableT T > ON A.EligNumber =T.EligNumber > AND A.AccountNumb = T.AccountNumb > AND A.FirstDate = T.FirstDate) C > ON B.EligNumber =C.EligNumber > AND B.AccountNumb = C.AccountNumb > AND B.FirstDate = C.FirstDate > WHERE C.AccountNumb IS NULL > AND C.FirstDate IS NULL > AND C.EligNumber IS NULL > DELETE FROM @TempTableT > > INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail 'Month Begin 20141202', > 'Month Begin 20150501' --step4 > > DELETE @TempTableA > FROM @TempTableA B > LEFT JOIN > (SELECT A.* > FROM @TempTableA A > INNER JOIN @TempTableT T > ON A.EligNumber =T.EligNumber > AND A.AccountNumb = T.AccountNumb > AND A.FirstDate = T.FirstDate) C > ON B.EligNumber =C.EligNumber > AND B.AccountNumb = C.AccountNumb > AND B.FirstDate = C.FirstDate > WHERE C.AccountNumb IS NULL > AND C.FirstDate IS NULL > AND C.EligNumber IS NULL > > SET NOCOUNT OFF > > SELECT * FROM @TempTableA --Final Select > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From davidmcafee at gmail.com Fri May 15 19:28:54 2015 From: davidmcafee at gmail.com (David McAfee) Date: Fri, 15 May 2015 17:28:54 -0700 Subject: [AccessD] [dba-SQLServer] Looping through queries over and over In-Reply-To: References: Message-ID: I ended up doing in without cursors, using table variables and it does the whole year in less that 1 second: It could still use some clean up, but it's Friday and I am beat! CREATE PROCEDURE stpLossOfMediCal AS DECLARE @FirstBatch AS NVARCHAR(50), @SecondBatch AS NVARCHAR(50) SET @FirstBatch = 'Month Begin 20141130' --Will change this to pull from a table DECLARE @NumberRecords int, @RowCount int, @Batch AS NVARCHAR(50), @PreviousBatchName as NVARCHAR(50), @T CHAR(1) DECLARE @tblUniqueBatchNames TABLE(RowID int IDENTITY(1, 1), BatchName NVARCHAR(50)) DECLARE @tblBatchMatrix TABLE(RowID int IDENTITY(1, 1),T CHAR(1), B1 NVARCHAR(50), B2 NVARCHAR(50)) --Insert distinct batch names into temp table A INSERT INTO @tblUniqueBatchNames SELECT Provbatchname from tblCovivitas WITH (NOLOCK) WHERE ProvBatchName like 'Month Begin%' AND ProvBatchName>@FirstBatch GROUP BY ProvBatchName ORDER by ProvBatchName SET @NumberRecords = @@ROWCOUNT SET @RowCount = 1 --Create the Table Matrix for Temp table B: WHILE @RowCount <= @NumberRecords BEGIN SELECT @Batch = BatchName FROM @tblUniqueBatchNames WHERE RowID = @RowCount ORDER BY BatchName INSERT INTO @tblBatchMatrix SELECT @T, @Batch, batchname from @tblUniqueBatchNames WHERE BatchName>@Batch oRDER by BatchName SET @RowCount = @RowCount + 1 END --Update the first new batch record for b1 with an A, all other records with T UPDATE @tblBatchMatrix SET T = 'A' WHERE RowID IN (SELECT Min(RowID)FROM @tblBatchMatrix GROUP BY B1) UPDATE @tblBatchMatrix SET T = 'T' WHERE T IS NULL --Test Select --SELECT RowID, T,B1, B2 FROM @tblBatchMatrix ORDER BY B1, B2 --Now that we have the matrix made up, lets do the work: DECLARE @TempTableA TABLE(a bunch of Fields here) DECLARE @TempTableT TABLE(a bunch of Fields here) --Reset the Rowcount variable to 1 Set @RowCount = 1 WHILE @RowCount <= @NumberRecords BEGIN SELECT @T = T, @FirstBatch = B1, @SecondBatch = B2 FROM @tblBatchMatrix WHERE RowID = @RowCount ORDER BY RowID IF @T = 'A' BEGIN INSERT INTO @TempTableA EXEC stpLossOfMediCalDetail @FirstBatch, @SecondBatch END ELSE BEGIN INSERT INTO @TempTableT EXEC stpLossOfMediCalDetail @FirstBatch, @SecondBatch DELETE @TempTableA FROM @TempTableA B LEFT JOIN (SELECT A.* FROM @TempTableA A INNER JOIN @TempTableT T ON A.EligNumber =T.EligNumber AND A.AccountNumb = T.AccountNumb AND A.FirstDate = T.FirstDate) C ON B.EligNumber =C.EligNumber AND B.AccountNumb = C.AccountNumb AND B.FirstDate = C.FirstDate WHERE C.AccountNumb IS NULL AND C.FirstDate IS NULL AND C.EligNumber IS NULL DELETE FROM @TempTableT END SET @RowCount = @RowCount + 1 END SELECT * FROM @TempTableA --Not really * , I just put that to keep it smaller for the list order by EligNumber, LOCATION_NAME, RecipName, FirstDate, SecondDate I will look into the cube building for other projects that I am working on over here. Thanks, D From darryl at whittleconsulting.com.au Sun May 17 18:53:24 2015 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Sun, 17 May 2015 23:53:24 +0000 Subject: [AccessD] Fwd: Re: Is it better to call Excel Macro from access, or manipulate from Access? In-Reply-To: References: Message-ID: "...a simple CopyFromRecordset would avoid the need for creating and deleting header rows altogether." Sure, but this assumes that once you get the data to Excel you are not going to do much (or indeed, anything) else with it. And that might be fine and exactly the case. If you are just dumping data into cell A1 and leaving it, then copy from RS will work great and why bother with Excel VBA at all. But often getting the data into Excel is just the first step of a multi-step process. In my example where I prefer using the Excel template code, Excel does a lot of work with the downloaded data - and letting Excel do that work natively is a lot easier and faster to work with that trying to put it all into Access VBA. As I originally said, the real answer is "it depends". Those dependencies include your own personal coding style. I like having the Excel code separate as it is much easier to work with when debugging - but this is likely due to the Excel template in my example doing some complicated and tricky stuff - ergo it is easier to develop and test it 'stand-alone' - or at least I find it so. I can see pros and cons both ways and would use the best method for the task at hand. It is easy enough to establish an ADO connection between Excel and Access (or SQL Server) so Excel can control them back as well. This can be useful if you need to return data based on a result determined by Excel based on the original downloaded dataset. Good luck. If you need help with the Excel side feel free to email me offlist or try the Excel-L list. Looks like you could use a hand with that based on your example code provided. The VBA code recorder does an ok job and will give you the right idea, but the code it writes is barely functional and largely flaky and bothersome for regular use. As a rule of thumb you can usually clean it up by about 80%. Cheers Darryl -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson Sent: Friday, 15 May 2015 6:26 PM To: Access Developers discussion and problem solving Subject: [AccessD] Fwd: Re: Is it better to call Excel Macro from access, or manipulate from Access? Some opinions from additional excel experts David. I also by just gut feeling would have coded this from Access. On the flip side I might have treated Access like a backend and written similar queries and transformations you might be running in Access with ADO and put the project in Excel, if possible. ---------- Forwarded message ---------- From: "John Nurick" Date: May 15, 2015 4:22 AM Subject: Re: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? To: Cc: +1. Also, to my tidy mind it always feels neater to have all the code in +the same project (not counting add-ins). -----Original Message----- From: Microsoft Excel Developers List [mailto:EXCEL-L at PEACH.EASE.LSOFT.COM] On Behalf Of Rory Archibald Sent: 15 May 2015 09:18 To: EXCEL-L at PEACH.EASE.LSOFT.COM Subject: Re: [AccessD] Is it better to call Excel Macro from access, or manipulate from Access? Unless there is a need for the macros to exist in Excel (e.g. they may need to be run again separately to the original Access processing) I see no benefit in having them in Excel. I'd do everything in Access. The process itself sounds unnecessarily complicated to me - a simple CopyFromRecordset would avoid the need for creating and deleting header rows altogether. -------------------------------------------------------------------------- The EXCEL-L list is hosted on L-Soft international's LISTSERV(R) software running on Microsoft Windows Server 2008 R2. For subscription/signoff info and archives, see http://peach.ease.lsoft.com/archives/excel-l.html . COPYRIGHT INFO: http://peach.ease.lsoft.com/scripts/wa.exe?SHOWTPL=COPYRIGHT&L=EXCEL-L -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From pcs.accessd at gmail.com Thu May 21 12:45:08 2015 From: pcs.accessd at gmail.com (Borge Hansen) Date: Fri, 22 May 2015 01:45:08 +0800 Subject: [AccessD] Access2010 - Wait for Post Processing Message-ID: HI all, In the final stages of migrating an Access2003 application to Access2010. One of the Forms are pretty heavy on the Open and Timer events setting up the form and preparing data. In Access 2010 the Form breaks and says such and such query does not exist when attempting to hook up a record source.... I was pulling my hair, and in the end started going over the Form properties because I didn't know what else to do - case of looking for answers in the dark I guess... And suddenly I stumble over a Form property I've never paid attention to - simply because Access2003 has been the platform of choice up until recently - but not after July!! The form property is called : Wait for Post Processing Since the form does a lot on the initial run on the Timer Event I thought lets turn this property on... This was after I gave up on looking for information in MS's useless Help basket! Lo and behold - the form jumped back to it's old and tried well performing state... So, anyone who can throw some light on this property? I wonder why a Form in Access2003 could live without it but the same Form cannot in Access2010??? /borge From marksimms at verizon.net Fri May 22 17:20:04 2015 From: marksimms at verizon.net (Mark Simms) Date: Fri, 22 May 2015 18:20:04 -0400 Subject: [AccessD] Access2010 - Wait for Post Processing In-Reply-To: References: Message-ID: <056301d094dd$74605d20$5d211760$@net> Very impressive find....wow, such an interesting detail. From jimdettman at verizon.net Sat May 23 12:41:50 2015 From: jimdettman at verizon.net (Jim Dettman) Date: Sat, 23 May 2015 13:41:50 -0400 Subject: [AccessD] Access2010 - Wait for Post Processing In-Reply-To: References: Message-ID: <> It was added when data marco's were added...if yes, it waits for a macro to finish before continuing. <> Different features in 2010 and as a result, it executes slightly differently. This is no difference than in the past when you might take an app to a significantly faster/slower machine and all of a sudden it doesn't work right. Basically means your not doing things where/when you should. Jim. -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Borge Hansen Sent: Thursday, May 21, 2015 01:45 PM To: Access Developers discussion and problem solving Subject: [AccessD] Access2010 - Wait for Post Processing HI all, In the final stages of migrating an Access2003 application to Access2010. One of the Forms are pretty heavy on the Open and Timer events setting up the form and preparing data. In Access 2010 the Form breaks and says such and such query does not exist when attempting to hook up a record source.... I was pulling my hair, and in the end started going over the Form properties because I didn't know what else to do - case of looking for answers in the dark I guess... And suddenly I stumble over a Form property I've never paid attention to - simply because Access2003 has been the platform of choice up until recently - but not after July!! The form property is called : Wait for Post Processing Since the form does a lot on the initial run on the Timer Event I thought lets turn this property on... This was after I gave up on looking for information in MS's useless Help basket! Lo and behold - the form jumped back to it's old and tried well performing state... So, anyone who can throw some light on this property? I wonder why a Form in Access2003 could live without it but the same Form cannot in Access2010??? /borge -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jerbach.db at gmail.com Tue May 26 14:35:27 2015 From: jerbach.db at gmail.com (Janet Erbach) Date: Tue, 26 May 2015 14:35:27 -0500 Subject: [AccessD] Dropped records...Boatloads of them Message-ID: Hello all - I've corresponded with you all in the last couple of months about records dropping from an access database in a manufacturing environment. About once a week we'd find 1-2 dropped records in a tool crib database. We installed UPS's in the area where this was happening and...fingers crossed...so far so good. No dropped records since they went in 3 weeks ago. Today I learned that a manufacturing scrap database was missing records, too. 868,105 records to be exact: All records from 2014 and several months worth from 2015. Thankfully I was able to restore them from a shadow copy. The likelihood of an end-user deleting all that data manually is so slim that I don't even consider it a possibility. Can a noisy wireless network environment and/or power brown-outs cause such a large chunk of data to go missing like that? Janet Erbach From rockysmolin at bchacc.com Tue May 26 15:09:08 2015 From: rockysmolin at bchacc.com (Rocky Smolin) Date: Tue, 26 May 2015 13:09:08 -0700 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: References: Message-ID: <76C10580A3FB4607BEC0AA9237C2E1C1@HAL9007> IMHO it seems very unlikely. Without corrupting the database. I did have one incident years ago where thousands of records disappeared from a database. Turns out a na?ve user wanted a subset to the data so she wrote a query that retrieved all the records in the table and then just deleted the ones she wasn't interested in, assuming that the records were deleted from the query and not the table. It took a while to ferret out exactly what happened. R -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Janet Erbach Sent: Tuesday, May 26, 2015 12:35 PM To: Database Advisors Subject: [AccessD] Dropped records...Boatloads of them Hello all - I've corresponded with you all in the last couple of months about records dropping from an access database in a manufacturing environment. About once a week we'd find 1-2 dropped records in a tool crib database. We installed UPS's in the area where this was happening and...fingers crossed...so far so good. No dropped records since they went in 3 weeks ago. Today I learned that a manufacturing scrap database was missing records, too. 868,105 records to be exact: All records from 2014 and several months worth from 2015. Thankfully I was able to restore them from a shadow copy. The likelihood of an end-user deleting all that data manually is so slim that I don't even consider it a possibility. Can a noisy wireless network environment and/or power brown-outs cause such a large chunk of data to go missing like that? Janet Erbach -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From stuart at lexacorp.com.pg Tue May 26 15:48:29 2015 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Wed, 27 May 2015 06:48:29 +1000 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: References: Message-ID: <5564DC1D.16625.11CD7329@stuart.lexacorp.com.pg> Yes, that can happen through a dropped connection when data is being written. I've seen uit happen occasionally. You get a corrupt index. The data is still there, but Access can't find it. On 26 May 2015 at 14:35, Janet Erbach wrote: > Hello all - > > I've corresponded with you all in the last couple of months about > records dropping from an access database in a manufacturing > environment. About once a week we'd find 1-2 dropped records in a > tool crib database. We installed UPS's in the area where this was > happening and...fingers crossed...so far so good. No dropped records > since they went in 3 weeks ago. > > Today I learned that a manufacturing scrap database was missing > records, too. 868,105 records to be exact: All records from 2014 and > several months worth from 2015. Thankfully I was able to restore them > from a shadow copy. > > The likelihood of an end-user deleting all that data manually is so > slim that I don't even consider it a possibility. Can a noisy > wireless network environment and/or power brown-outs cause such a > large chunk of data to go missing like that? > > Janet Erbach > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From jerbach.db at gmail.com Tue May 26 16:03:13 2015 From: jerbach.db at gmail.com (Janet Erbach) Date: Tue, 26 May 2015 16:03:13 -0500 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: <5564DC1D.16625.11CD7329@stuart.lexacorp.com.pg> References: <5564DC1D.16625.11CD7329@stuart.lexacorp.com.pg> Message-ID: Wow. So are there any other solutions besides: 1) hardwire the network connections 2) install UPS at each workstation Both of which are due to be scheduled for the 12th of Never... On Tue, May 26, 2015 at 3:48 PM, Stuart McLachlan wrote: > Yes, that can happen through a dropped connection when data is being > written. I've seen uit > happen occasionally. > > You get a corrupt index. The data is still there, but Access can't find it. > > > > On 26 May 2015 at 14:35, Janet Erbach wrote: > > > Hello all - > > > > I've corresponded with you all in the last couple of months about > > records dropping from an access database in a manufacturing > > environment. About once a week we'd find 1-2 dropped records in a > > tool crib database. We installed UPS's in the area where this was > > happening and...fingers crossed...so far so good. No dropped records > > since they went in 3 weeks ago. > > > > Today I learned that a manufacturing scrap database was missing > > records, too. 868,105 records to be exact: All records from 2014 and > > several months worth from 2015. Thankfully I was able to restore them > > from a shadow copy. > > > > The likelihood of an end-user deleting all that data manually is so > > slim that I don't even consider it a possibility. Can a noisy > > wireless network environment and/or power brown-outs cause such a > > large chunk of data to go missing like that? > > > > Janet Erbach > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > 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 Tue May 26 16:12:14 2015 From: rockysmolin at bchacc.com (Rocky Smolin) Date: Tue, 26 May 2015 14:12:14 -0700 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: <5564DC1D.16625.11CD7329@stuart.lexacorp.com.pg> References: <5564DC1D.16625.11CD7329@stuart.lexacorp.com.pg> Message-ID: Would compact and repair restore you think? r -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan Sent: Tuesday, May 26, 2015 1:48 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Dropped records...Boatloads of them Yes, that can happen through a dropped connection when data is being written. I've seen uit happen occasionally. You get a corrupt index. The data is still there, but Access can't find it. On 26 May 2015 at 14:35, Janet Erbach wrote: > Hello all - > > I've corresponded with you all in the last couple of months about > records dropping from an access database in a manufacturing > environment. About once a week we'd find 1-2 dropped records in a > tool crib database. We installed UPS's in the area where this was > happening and...fingers crossed...so far so good. No dropped records > since they went in 3 weeks ago. > > Today I learned that a manufacturing scrap database was missing > records, too. 868,105 records to be exact: All records from 2014 and > several months worth from 2015. Thankfully I was able to restore them > from a shadow copy. > > The likelihood of an end-user deleting all that data manually is so > slim that I don't even consider it a possibility. Can a noisy > wireless network environment and/or power brown-outs cause such a > large chunk of data to go missing like that? > > Janet Erbach > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From stuart at lexacorp.com.pg Tue May 26 16:13:26 2015 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Wed, 27 May 2015 07:13:26 +1000 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: References: , <5564DC1D.16625.11CD7329@stuart.lexacorp.com.pg>, Message-ID: <5564E1F6.6781.11E44A08@stuart.lexacorp.com.pg> The only solution other than hardening your network connectivity is to change your BE to a proper RDBMS Server (SQL Server, MySQL or whatever) with fault tolerance built in. -- Stuart On 26 May 2015 at 16:03, Janet Erbach wrote: > Wow. So are there any other solutions besides: > > 1) hardwire the network connections > 2) install UPS at each workstation > > Both of which are due to be scheduled for the 12th of Never... > > On Tue, May 26, 2015 at 3:48 PM, Stuart McLachlan > wrote: > > > Yes, that can happen through a dropped connection when data is > > being written. I've seen uit happen occasionally. > > > > You get a corrupt index. The data is still there, but Access can't > > find it. > > > > > > > > On 26 May 2015 at 14:35, Janet Erbach wrote: > > > > > Hello all - > > > > > > I've corresponded with you all in the last couple of months about > > > records dropping from an access database in a manufacturing > > > environment. About once a week we'd find 1-2 dropped records in a > > > tool crib database. We installed UPS's in the area where this > > > was happening and...fingers crossed...so far so good. No dropped > > > records since they went in 3 weeks ago. > > > > > > Today I learned that a manufacturing scrap database was missing > > > records, too. 868,105 records to be exact: All records from 2014 > > > and several months worth from 2015. Thankfully I was able to > > > restore them from a shadow copy. > > > > > > The likelihood of an end-user deleting all that data manually is > > > so slim that I don't even consider it a possibility. Can a noisy > > > wireless network environment and/or power brown-outs cause such a > > > large chunk of data to go missing like that? > > > > > > Janet Erbach > > > -- > > > AccessD mailing list > > > AccessD at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > Website: http://www.databaseadvisors.com > > > > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > 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 May 26 16:18:39 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 26 May 2015 15:18:39 -0600 (MDT) Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: Message-ID: <438545340.82818297.1432675119210.JavaMail.root@shaw.ca> Hi Janet: An MS Access MDB demands a very stable and static environment. Wireless connection are always dropping signal, by their nature...some worse that others. Watch out for corruption and quite possibly lost records. Where at all possible use network cable and/or use a UPS. Maybe make an over-night batch file the exports, imports and re-index the offending tables...that may save some flaky records and/or tell you exactly when a record(s) was lost. Remove all cascading code from the application, updating or deleting. Use an unique key to identify a record when updating or deleting...there is less chance of falling victim to corrupted keys. Of course my recommendation is to use ADO and I believe you have all the code for that. HTH Jim ----- Original Message ----- From: "Janet Erbach" To: "Database Advisors" Sent: Tuesday, May 26, 2015 12:35:27 PM Subject: [AccessD] Dropped records...Boatloads of them Hello all - I've corresponded with you all in the last couple of months about records dropping from an access database in a manufacturing environment. About once a week we'd find 1-2 dropped records in a tool crib database. We installed UPS's in the area where this was happening and...fingers crossed...so far so good. No dropped records since they went in 3 weeks ago. Today I learned that a manufacturing scrap database was missing records, too. 868,105 records to be exact: All records from 2014 and several months worth from 2015. Thankfully I was able to restore them from a shadow copy. The likelihood of an end-user deleting all that data manually is so slim that I don't even consider it a possibility. Can a noisy wireless network environment and/or power brown-outs cause such a large chunk of data to go missing like that? Janet Erbach -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From accessd at shaw.ca Tue May 26 16:23:37 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 26 May 2015 15:23:37 -0600 (MDT) Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: Message-ID: <1396250758.82821243.1432675417371.JavaMail.root@shaw.ca> ADO. :-) Jim ----- Original Message ----- From: "Janet Erbach" To: "Access Developers discussion and problem solving" Sent: Tuesday, May 26, 2015 2:03:13 PM Subject: Re: [AccessD] Dropped records...Boatloads of them Wow. So are there any other solutions besides: 1) hardwire the network connections 2) install UPS at each workstation Both of which are due to be scheduled for the 12th of Never... On Tue, May 26, 2015 at 3:48 PM, Stuart McLachlan wrote: > Yes, that can happen through a dropped connection when data is being > written. I've seen uit > happen occasionally. > > You get a corrupt index. The data is still there, but Access can't find it. > > > > On 26 May 2015 at 14:35, Janet Erbach wrote: > > > Hello all - > > > > I've corresponded with you all in the last couple of months about > > records dropping from an access database in a manufacturing > > environment. About once a week we'd find 1-2 dropped records in a > > tool crib database. We installed UPS's in the area where this was > > happening and...fingers crossed...so far so good. No dropped records > > since they went in 3 weeks ago. > > > > Today I learned that a manufacturing scrap database was missing > > records, too. 868,105 records to be exact: All records from 2014 and > > several months worth from 2015. Thankfully I was able to restore them > > from a shadow copy. > > > > The likelihood of an end-user deleting all that data manually is so > > slim that I don't even consider it a possibility. Can a noisy > > wireless network environment and/or power brown-outs cause such a > > large chunk of data to go missing like that? > > > > Janet Erbach > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From stuart at lexacorp.com.pg Tue May 26 16:25:36 2015 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Wed, 27 May 2015 07:25:36 +1000 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: References: , <5564DC1D.16625.11CD7329@stuart.lexacorp.com.pg>, Message-ID: <5564E4D0.1554.11EF6CE3@stuart.lexacorp.com.pg> Sometimes! I've also had situations where only opening the table in code, stepping through the records and writing them out to a linked table in another database worked. On 26 May 2015 at 14:12, Rocky Smolin wrote: > Would compact and repair restore you think? > > r > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf > Of Stuart McLachlan Sent: Tuesday, May 26, 2015 1:48 PM To: Access > Developers discussion and problem solving Subject: Re: [AccessD] > Dropped records...Boatloads of them > > Yes, that can happen through a dropped connection when data is being > written. I've seen uit happen occasionally. > > You get a corrupt index. The data is still there, but Access can't > find it. > > > > On 26 May 2015 at 14:35, Janet Erbach wrote: > > > Hello all - > > > > I've corresponded with you all in the last couple of months about > > records dropping from an access database in a manufacturing > > environment. About once a week we'd find 1-2 dropped records in a > > tool crib database. We installed UPS's in the area where this was > > happening and...fingers crossed...so far so good. No dropped > > records since they went in 3 weeks ago. > > > > Today I learned that a manufacturing scrap database was missing > > records, too. 868,105 records to be exact: All records from 2014 > > and several months worth from 2015. Thankfully I was able to > > restore them from a shadow copy. > > > > The likelihood of an end-user deleting all that data manually is so > > slim that I don't even consider it a possibility. Can a noisy > > wireless network environment and/or power brown-outs cause such a > > large chunk of data to go missing like that? > > > > Janet Erbach > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > 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 May 26 16:30:19 2015 From: accessd at shaw.ca (Jim Lawrence) Date: Tue, 26 May 2015 15:30:19 -0600 (MDT) Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: <5564E1F6.6781.11E44A08@stuart.lexacorp.com.pg> Message-ID: <627084154.82825014.1432675819870.JavaMail.root@shaw.ca> Bingo... :-) Jim ----- Original Message ----- From: "Stuart McLachlan" To: "Access Developers discussion and problem solving" Sent: Tuesday, May 26, 2015 2:13:26 PM Subject: Re: [AccessD] Dropped records...Boatloads of them The only solution other than hardening your network connectivity is to change your BE to a proper RDBMS Server (SQL Server, MySQL or whatever) with fault tolerance built in. -- Stuart On 26 May 2015 at 16:03, Janet Erbach wrote: > Wow. So are there any other solutions besides: > > 1) hardwire the network connections > 2) install UPS at each workstation > > Both of which are due to be scheduled for the 12th of Never... > > On Tue, May 26, 2015 at 3:48 PM, Stuart McLachlan > wrote: > > > Yes, that can happen through a dropped connection when data is > > being written. I've seen uit happen occasionally. > > > > You get a corrupt index. The data is still there, but Access can't > > find it. > > > > > > > > On 26 May 2015 at 14:35, Janet Erbach wrote: > > > > > Hello all - > > > > > > I've corresponded with you all in the last couple of months about > > > records dropping from an access database in a manufacturing > > > environment. About once a week we'd find 1-2 dropped records in a > > > tool crib database. We installed UPS's in the area where this > > > was happening and...fingers crossed...so far so good. No dropped > > > records since they went in 3 weeks ago. > > > > > > Today I learned that a manufacturing scrap database was missing > > > records, too. 868,105 records to be exact: All records from 2014 > > > and several months worth from 2015. Thankfully I was able to > > > restore them from a shadow copy. > > > > > > The likelihood of an end-user deleting all that data manually is > > > so slim that I don't even consider it a possibility. Can a noisy > > > wireless network environment and/or power brown-outs cause such a > > > large chunk of data to go missing like that? > > > > > > Janet Erbach > > > -- > > > AccessD mailing list > > > AccessD at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > Website: http://www.databaseadvisors.com > > > > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jerbach.db at gmail.com Tue May 26 17:06:33 2015 From: jerbach.db at gmail.com (Janet Erbach) Date: Tue, 26 May 2015 17:06:33 -0500 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: <627084154.82825014.1432675819870.JavaMail.root@shaw.ca> References: <5564E1F6.6781.11E44A08@stuart.lexacorp.com.pg> <627084154.82825014.1432675819870.JavaMail.root@shaw.ca> Message-ID: Alright. Thank you all. I'll look into the options that I may have with this particular database - I haven't worked with it at all yet, so have no idea how the code is structured. And if it's just a matter of having one or 2 users set up with a wired connection and UPS I may be able to make that happen. On Tue, May 26, 2015 at 4:30 PM, Jim Lawrence wrote: > Bingo... :-) > > Jim > > ----- Original Message ----- > From: "Stuart McLachlan" > To: "Access Developers discussion and problem solving" < > accessd at databaseadvisors.com> > Sent: Tuesday, May 26, 2015 2:13:26 PM > Subject: Re: [AccessD] Dropped records...Boatloads of them > > The only solution other than hardening your network connectivity is to > change your BE to a > proper RDBMS Server (SQL Server, MySQL or whatever) with fault tolerance > built in. > > -- > Stuart > > > On 26 May 2015 at 16:03, Janet Erbach wrote: > > > Wow. So are there any other solutions besides: > > > > 1) hardwire the network connections > > 2) install UPS at each workstation > > > > Both of which are due to be scheduled for the 12th of Never... > > > > On Tue, May 26, 2015 at 3:48 PM, Stuart McLachlan > > wrote: > > > > > Yes, that can happen through a dropped connection when data is > > > being written. I've seen uit happen occasionally. > > > > > > You get a corrupt index. The data is still there, but Access can't > > > find it. > > > > > > > > > > > > On 26 May 2015 at 14:35, Janet Erbach wrote: > > > > > > > Hello all - > > > > > > > > I've corresponded with you all in the last couple of months about > > > > records dropping from an access database in a manufacturing > > > > environment. About once a week we'd find 1-2 dropped records in a > > > > tool crib database. We installed UPS's in the area where this > > > > was happening and...fingers crossed...so far so good. No dropped > > > > records since they went in 3 weeks ago. > > > > > > > > Today I learned that a manufacturing scrap database was missing > > > > records, too. 868,105 records to be exact: All records from 2014 > > > > and several months worth from 2015. Thankfully I was able to > > > > restore them from a shadow copy. > > > > > > > > The likelihood of an end-user deleting all that data manually is > > > > so slim that I don't even consider it a possibility. Can a noisy > > > > wireless network environment and/or power brown-outs cause such a > > > > large chunk of data to go missing like that? > > > > > > > > Janet Erbach > > > > -- > > > > AccessD mailing list > > > > AccessD at databaseadvisors.com > > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > > Website: http://www.databaseadvisors.com > > > > > > > > > > > > > -- > > > AccessD mailing list > > > AccessD at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > Website: http://www.databaseadvisors.com > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From jamesbutton at blueyonder.co.uk Tue May 26 17:31:46 2015 From: jamesbutton at blueyonder.co.uk (James Button) Date: Tue, 26 May 2015 23:31:46 +0100 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: <627084154.82825014.1432675819870.JavaMail.root@shaw.ca> References: <5564E1F6.6781.11E44A08@stuart.lexacorp.com.pg> <627084154.82825014.1432675819870.JavaMail.root@shaw.ca> Message-ID: Yes - Basic premise has to be that the system will fail to properly process actions on any multi-access database, and especially a distributed one - where the update (insert modify and delete) actions are apparently performed by programs running on attached devices. So that means fault tolerance with confirmation of actions on the data verified after any change - As in terminate the updating transaction connection (but not necessarily the actual LAN/WAN connection) and then re-access the server store to validate the update actually occurred. On the basis that you should Have an audit log. And a re-do updates facility to bring a backup save up-to-date. Then it is probably easier to have update actions passed back to the BE/server for that to action the updates, and then pass out a confirmation that the update request entry has been: Recorded on the redo store queue. Recorded on the audit log. And the update entry has been actioned. - as in from the B/E facility "Coo-ee remote program":- See, here is a re-extract (data, including the audit detail and deleted status) from the new dataset. UPS and hard-wired will reduce the frequency of problems - but you still need to code for the possibility. (Sort of like having your valuables in a vault - with guards and all sorts of alarm systems - not truly effective unless the guards can actually - physically check the vault, and somebody can get the police to turn up and check properly when the alarms have gone off. See UK news re. Hatton Garden.) JimB -----Original Message----- From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Tuesday, May 26, 2015 10:30 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Dropped records...Boatloads of them Bingo... :-) Jim ----- Original Message ----- From: "Stuart McLachlan" To: "Access Developers discussion and problem solving" Sent: Tuesday, May 26, 2015 2:13:26 PM Subject: Re: [AccessD] Dropped records...Boatloads of them The only solution other than hardening your network connectivity is to change your BE to a proper RDBMS Server (SQL Server, MySQL or whatever) with fault tolerance built in. -- Stuart On 26 May 2015 at 16:03, Janet Erbach wrote: > Wow. So are there any other solutions besides: > > 1) hardwire the network connections > 2) install UPS at each workstation > > Both of which are due to be scheduled for the 12th of Never... > > On Tue, May 26, 2015 at 3:48 PM, Stuart McLachlan > wrote: > > > Yes, that can happen through a dropped connection when data is > > being written. I've seen uit happen occasionally. > > > > You get a corrupt index. The data is still there, but Access can't > > find it. > > > > > > > > On 26 May 2015 at 14:35, Janet Erbach wrote: > > > > > Hello all - > > > > > > I've corresponded with you all in the last couple of months about > > > records dropping from an access database in a manufacturing > > > environment. About once a week we'd find 1-2 dropped records in a > > > tool crib database. We installed UPS's in the area where this > > > was happening and...fingers crossed...so far so good. No dropped > > > records since they went in 3 weeks ago. > > > > > > Today I learned that a manufacturing scrap database was missing > > > records, too. 868,105 records to be exact: All records from 2014 > > > and several months worth from 2015. Thankfully I was able to > > > restore them from a shadow copy. > > > > > > The likelihood of an end-user deleting all that data manually is > > > so slim that I don't even consider it a possibility. Can a noisy > > > wireless network environment and/or power brown-outs cause such a > > > large chunk of data to go missing like that? > > > > > > Janet Erbach > > > -- > > > AccessD mailing list > > > AccessD at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > Website: http://www.databaseadvisors.com > > > > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com From jackandpat.d at gmail.com Tue May 26 19:33:13 2015 From: jackandpat.d at gmail.com (jack drawbridge) Date: Tue, 26 May 2015 20:33:13 -0400 Subject: [AccessD] Dropped records...Boatloads of them In-Reply-To: References: <5564E1F6.6781.11E44A08@stuart.lexacorp.com.pg> <627084154.82825014.1432675819870.JavaMail.root@shaw.ca> Message-ID: Stuart, Regarding the corrupt index --assuming you could identify that was the issue - could you drop the index and re-index? Not sure how you would determine the index is corrupt, any ideas? jack On Tue, May 26, 2015 at 6:31 PM, James Button wrote: > Yes - > Basic premise has to be that the system will fail to properly process > actions on > any multi-access database, and especially a distributed one - where the > update > (insert modify and delete) actions are apparently performed by programs > running > on attached devices. > > So that means fault tolerance with confirmation of actions on the data > verified > after any change - > As in terminate the updating transaction connection (but not necessarily > the > actual LAN/WAN connection) and then re-access the server store to validate > the > update actually occurred. > > On the basis that you should > Have an audit log. > And a re-do updates facility to bring a backup save up-to-date. > Then it is probably easier to have update actions passed back to the > BE/server > for that to action the updates, and then pass out a confirmation that the > update > request entry has been: > Recorded on the redo store queue. > Recorded on the audit log. > And the update entry has been actioned. - as in from the B/E facility > "Coo-ee remote program":- See, here is a re-extract (data, including the > audit > detail and deleted status) from the new dataset. > > UPS and hard-wired will reduce the frequency of problems - but you still > need to > code for the possibility. > (Sort of like having your valuables in a vault - with guards and all sorts > of > alarm systems - not truly effective unless the guards can actually - > physically > check the vault, and somebody can get the police to turn up and check > properly > when the alarms have gone off. See UK news re. Hatton Garden.) > > JimB > > > -----Original Message----- > From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > Jim > Lawrence > Sent: Tuesday, May 26, 2015 10:30 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Dropped records...Boatloads of them > > Bingo... :-) > > Jim > > ----- Original Message ----- > From: "Stuart McLachlan" > To: "Access Developers discussion and problem solving" > > Sent: Tuesday, May 26, 2015 2:13:26 PM > Subject: Re: [AccessD] Dropped records...Boatloads of them > > The only solution other than hardening your network connectivity is to > change > your BE to a > proper RDBMS Server (SQL Server, MySQL or whatever) with fault tolerance > built > in. > > -- > Stuart > > > On 26 May 2015 at 16:03, Janet Erbach wrote: > > > Wow. So are there any other solutions besides: > > > > 1) hardwire the network connections > > 2) install UPS at each workstation > > > > Both of which are due to be scheduled for the 12th of Never... > > > > On Tue, May 26, 2015 at 3:48 PM, Stuart McLachlan > > wrote: > > > > > Yes, that can happen through a dropped connection when data is > > > being written. I've seen uit happen occasionally. > > > > > > You get a corrupt index. The data is still there, but Access can't > > > find it. > > > > > > > > > > > > On 26 May 2015 at 14:35, Janet Erbach wrote: > > > > > > > Hello all - > > > > > > > > I've corresponded with you all in the last couple of months about > > > > records dropping from an access database in a manufacturing > > > > environment. About once a week we'd find 1-2 dropped records in a > > > > tool crib database. We installed UPS's in the area where this > > > > was happening and...fingers crossed...so far so good. No dropped > > > > records since they went in 3 weeks ago. > > > > > > > > Today I learned that a manufacturing scrap database was missing > > > > records, too. 868,105 records to be exact: All records from 2014 > > > > and several months worth from 2015. Thankfully I was able to > > > > restore them from a shadow copy. > > > > > > > > The likelihood of an end-user deleting all that data manually is > > > > so slim that I don't even consider it a possibility. Can a noisy > > > > wireless network environment and/or power brown-outs cause such a > > > > large chunk of data to go missing like that? > > > > > > > > Janet Erbach > > > > -- > > > > AccessD mailing list > > > > AccessD at databaseadvisors.com > > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > > Website: http://www.databaseadvisors.com > > > > > > > > > > > > > -- > > > AccessD mailing list > > > AccessD at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > Website: http://www.databaseadvisors.com > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > From gustav at cactus.dk Wed May 27 01:57:42 2015 From: gustav at cactus.dk (Gustav Brock) Date: Wed, 27 May 2015 06:57:42 +0000 Subject: [AccessD] Dropped records...Boatloads of them Message-ID: Hi Janet As already noted, WiFi connections to your backend is a no-no. In fact, it could be the single source for your trouble. So reschedule #1 to high priority. If some users require WiFi connection to the LAN, move these to Remote Desktop and use a terminal server. Or, of course, move the backend to SQL Server, but that is another project. /gustav -----Oprindelig meddelelse----- Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] P? vegne af Janet Erbach Sendt: 26. maj 2015 23:03 Til: Access Developers discussion and problem solving Emne: Re: [AccessD] Dropped records...Boatloads of them Wow. So are there any other solutions besides: 1) hardwire the network connections 2) install UPS at each workstation Both of which are due to be scheduled for the 12th of Never... From Chester_Kaup at kindermorgan.com Thu May 28 16:14:42 2015 From: Chester_Kaup at kindermorgan.com (Kaup, Chester) Date: Thu, 28 May 2015 21:14:42 +0000 Subject: [AccessD] FW: Query not using criteria Message-ID: <8E16E03987F1FD4FB0A9BEBF7CC160CB07E368D3@HOUEX11.kindermorgan.com> I have a query that does not appear to be using the criteria. Below is the SQL for the query. Certain ChildPID's should be excluded but they are not being excluded. What am I missing? Thanks. SELECT ConfigMaster.PID, Constants.SDate, ConfigMaster.ChildPID, ConfigMaster.WellName FROM ([tbl Injectors in All Patterns and Factor] INNER JOIN ConfigMaster ON [tbl Injectors in All Patterns and Factor].PID = ConfigMaster.PID) INNER JOIN Constants ON ConfigMaster.PID = Constants.PID WHERE (((ConfigMaster.ChildPID)<>[tbl Injectors in All Patterns and Factor]![ChildPID])) GROUP BY ConfigMaster.PID, Constants.SDate, ConfigMaster.ChildPID, ConfigMaster.WellName HAVING (((ConfigMaster.PID)="PAT 109-1A")); This is what should be excluded PID ChildPID Well_Name Sdate Factor1 Factor2 PAT 109-1A 42415034110000 109-1 8/1/2006 1 1 PAT 109-1A 42415046190000 156-1 8/1/2006 .25 .25 PAT 109-1A 42415307260000 109-7 8/1/2006 .333333 .333333 PAT 109-1A 42415342080000 109-1A 8/1/2006 1 1 And here are the query results PID SDate ChildPID WellName PAT 109-1A 8/1/2006 42415017570000 111-2 PAT 109-1A 8/1/2006 42415034110000 109-1 PAT 109-1A 8/1/2006 42415034130000 109-3 PAT 109-1A 8/1/2006 42415046190000 156-1 PAT 109-1A 8/1/2006 42415307260000 109-7 PAT 109-1A 8/1/2006 42415341260000 111-7 PAT 109-1A 8/1/2006 42415341770000 156-1A PAT 109-1A 8/1/2006 42415341880000 109-3A PAT 109-1A 8/1/2006 42415342080000 109-1A