[AccessD] Second pair of eyes

Sorry Arthur,
Getting late here.  Mixed my email up.
Max dot wanadoo @ gmail dot com


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: 10 November 2008 20:35
To: Access Developers discussion and problem solving
Subject: [AccessD] Second pair of eyes

Hi all,

I have one and possibly two outstanding issues with a simple Access app that
I wrote, and cannot seem to locate the problem. It should have been a
brain-dead-simple app to deliver, but I can't quite deliver the baby. I am
in the throes of some medical issues that I fear are non-trivial, and I just
don't have the energy to continue to address these problems.

The general scenario is this: there is a form bound to a table. The form
contains two comboboxes which I call Finders. They show the list of Sites by
Site Name and Site Number respectively, and as you navigate they refresh to
show the current Site.

So far, so good.

1. Create a New Site. This is not so simple as to just add a new row. The PK
for a site is based on a couple of other fields and also the date the site
was created. Assume that the Region is 101 and the year the site was opened
was 2007, then what we need to do is a dLookup for "10107*". If there are no
hits, this one gets numbered "10107A001". If there are hits, we grab the max
match, shave the tail and increment it and put it back, so it becomes
"10107A002". (Don't ask why the "A" is in there. Government.

Once a number has been assigned it can never under any circumstances be
changed.

I have the algorithm proved and re-proved and re-proved regarding the
generation of new site numbers. That's not the issue. The issue is that
there is a button on the form to create a new site, whose first command goes
to acNewRec or whatever it's called (I'm not at home as I write this), then
it pops up this dialog box which requests the Region number and the year and
then manufactures the new site number for insertion into the new record. All
that works lovely. Then it falls over, and I cannot figure out why, and I'm
currently too sick to deal with it.

2. Filter by Form. There is a set of buttons on said form that allow the
user to filter by form, then eventually cancel the filter, and so on. The
"Finders" need to keep in synch with this. I have code that I think does
this (by grabbing me.Filter and amending the rowsources of the two Finders)
but I've been so sick for the past month that I am unconfident that I've
tested it enough.

I need a second pair of eyes on these issues to make sure they work so I can
finally put this puppy to bed.

Any volunteers? I will send the FE and BE off-list in RAR or ZIP format. I
am willing to pay for services rendered. Meanwhile, I just  need to go back
to bed.

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