Thanks for the reply. It helped me a bit, but didn't solve all my
problems.
(I unified my naming convention, now it should conform the universal
norms)
1. Everything is clean and simple, up to the moment of setting up a
default
order. When I try to do it from a form (it doesn't matter which one, and
how
it was made, they all act in same way), then the field can't be updated.
then the field can't be updated.
....hum...what field?? the above is rather vague..don't you think?
Fact is, I thought the idea here was that we have a button to create a new
blank order. If we leave the problem alone of default orders here, and we
can't even get a simple button to create a blank order...then we are of sunk
here...are we not??
I would first think that you create something that lets you add a new
client. You then create something that lets you create a blank order for
that client. We got to at least get a basic functioning system BEFORE we
even being to worry about defaults from the "default" tables we talked
about. (and, worry later about some process we run that will generate these
orders).
So, #1, we got to be able to create a simple order first.
Then, #2, lets get the defaults stuff from the defaults table to this order
working.
Then, #3, lets eventually build a process that does the above for us each
day.
So I
thought, that I might add an empty default order (placeholder in
tblDefaultOrder) the moment that client is added.
Well, you could create a empty default order...but why not have the user do
this. Why have the system create empty orders when you add a new client?
Just have a nice form that displays the client. You then have a button to
add a "default" order. You set the day of the week, and the rest of the
design of the default order is likely to be the SAME as the orders forms. (a
human has to setup and enter the "default" orders one by one anyway...so
saving one mouse click to add a default order is not some big issue here).
You should be able to add one client, or two clients or as many as you wish
to the system. Gee, perhaps you are going to do a mail out to some of these
people. I don't think the mere fact of adding a client should force, or
create a bunch of default orders. You can use the same code, forms etc that
you use to make orders for the default orders (you will copy these screens
designs....and likely the tables designs also! So, for the sake of training
and ease of use, that process to create a default orders is going to look
VERY MUCH like the same process you use to create actual orders. (after
all..they both have nearly the same information).
I would assume that after you add a client, then those clients in the system
are available for general use. I mean, you could then search, and bring up a
client. If you need a order for that client, then you could have a button on
the form that you whack, and up comes a blank order. This is a good design,
since then you never have to re-type, or re-enter the client data. Also, you
would need a button on that client form to edit/view/add default orders.
(and, as mentioned..they will likely look like orders...except in place of a
order date...you have a order dayofWeek).
So, sure...you might eventually want some test's to ensure that default
orders exist for a client...but if there are none for the particular
day...then no orders need be generated from the default that don't exist.
Maybe some clients don't accept deliveries on Thursday..and some do on
Saturday...why hard code this requirements? If you don't enter a default for
a day of the week...then that client don't get a order generated (when we
*eventually* built that process that will generate the orders for each day).
The problem is, that I
might do it via form. But then - what in case if I didn't manage to
completely foolproof the database? Then the program should automagicaly
perform a sanity check and add the missing records.
Well, perhaps some companies don't accept delivers on a particular day. You
should be free to leave out particular days. Some companies might want
delivers on Saturdays..and others not. By you not entering a default order
for a given day of the week..then you system will thus not create orders for
that day (once again...I may be complete off mark...but it seems rather
flexible to not have certain "default" days entered for some clients).
So I'd like to write a script that would for every record in tblClients
check if the client has all seven entries in tblDefaultOrders, and in the
other case - it would insert the missing placeholders.
As mentioned, do you really need to force the above? Perhaps you don't have
the schedules from the client yet. Or, perhaps you don't have all the
"default" information entered. (you create a real mess here..and reduce
flexibility if you start throwing a bunch of blank default orders out
there).
I mean, you can eventually start putting in some code to test and scan and
inform you that some clients don't have some default days (sure, that
makes sense). I mean, sure, you could certainly work on this well after
the database is in production. I think the problem here is that you are
fixed on "5" or "7" place day holders. My view is that you add default
orders to
the system as you need, and some fixed concept about place holders don't
apply. I mean, why not generate all the invoices for the next two years...so
you can't forget anything? (fact is..things change). The same can be
said for clients...why not generate enough blank records for all the
new clients you will get next year?
I mean, is it better to create a bunch of orders with no defaults set yet?
Why do that? Now, someone has to find all these orders..and deal
with each one. (a human has to do this). So,...your process generates
blank place holders...but they are not yet filled? I don't think that
helps
anyone at all. You still got to eventually fill these things out..so don't
generate them until you can in fact fill them out!!
If you need some report, or something that tells you some clients don't have
orders for today (or defaults are not entered), then sure..run a report that
tells you this...but generating blank place holders only makes a mess.
If this problem is solved, then the other would be automatically solved as
well. It's the same situation with automated transferring DefaultOrders to
PracticalOrders - in case an order exists, then don't overwrite it. If it
doesn't exist - create it with values taken from tblDefaultOrdersDetails.
Well, as said, why not have a button to bring up a blank new order. When
that new order gets made, you either automatically populate the details with
the defaults table, or you give the user a option to populate for defaults.
With this approach, you don't worry about overwriting an existing order
Of course, this is talking about a one by one basis, but either way,
once the order is populated...you are still free to further add,
or edit, or enhance this order. And, if the order already exists, you simply
display it.
So, I am again at a loss about the concern about overwriting existing
orders?
If you run a process to do this (in place of the user working order by
order), then simply run this via the date. If a order is already generated
for today...then just don't generate a new one (again, I see no problem
here???).
I mean, how are you going to deal with having run the processing the
morning..and then during the day you need to add a new client? How will you
generate orders for this new client? I mean,
you enter a new client...how you going to generate orders for that client if
you run your process already? The simply solution is to allow user
interaction and some buttons to do this. Further, as mentioned, if a order
has been generated for today already..then you can safely run the process
again (you might need to run the process again if you add new clients for
example). So,
just use today's date as the check for this.
Of course..what happens when you already run the process..and now you need
to
change a order??
Well, you can either:
a) simply bring up the he order for that client today and modify it,
and
then modify the defaults so that next time, the order will show these
changes (assuming this is supposed to be a permanent change).
or
b) delete the existing order for today, modify the default order (for
this day), and then re-run your process to generate orders (since you
deleted the order for today..then a new one would get created....since as
mentioned...the process would ONLY create orders that don't exist for
today).
Which of the above approaches is going to depend on how you use your system
now...but it is up to you how you do this. It seems flexible enough to me.
The third problem is of something totaly different. Both of the above
scripts should be run at ceratin intervals of time
I would still implement and get working the manual system (i.e.: press
button to create blank order, and then autopopoulate it). Once you get the
code working to copy "one" order for a given client, then you can take
that code that works (and is battle tested), and move that code to a process
that does this for ALL clients in a given day.
So, get the several steps working manually. Get this working FOR ONE CLIENT
ORDER AT A TIME!!!
You THEN CAN work on a "process" that you run that goes through all the
clients, and generates a new order for the day (of course..only clients that
have a "default" setup for this day of the week would be included in this
processes....after all...some companies might not accept delivery on a
particular day!).
Windows Scheduler (to be honest I prefer cron...) , so I would like to set
it
up in the program. But I haven't comen across an ActiveX control "Timer".
Timer events are built into ms-access. You can setup a form and use the You
can setup a form in ms-access.
Here is some examples on how to kick out users after a given amount of
time...
I have successfully used it in several applications.
a97
http://support.microsoft.com/default.aspx?scid=kb;en-us;128814
a2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;210297
However, if you don't use the windows scheduler...then you have to leave
ms-access running. I would consider coming up with a separate mdb that has
no UI...and runs your process to update those tables, generate orders etc
(and perhaps updates some log table on how this went). (you database is
likely split now anyway..and you are used to having the code separate from
the data now anyway..right???).
I think for things like re-boots etc, you are much better off to use the
scheduler and write a windows script to launch your ms-access process
(windows scripting is easy...since it is like VB, but a lot of Unix types
find windows scripting difficult..since it is so much more powerful then
unix scripts).
Anyway, you can as mentioned use the timer event...but that only works if
YOUR application is running (a bit lame of a requirement, and any kind
of re-boot will mean that your process don't get run). Further, ms-access
is a rather large system and uses a tremendous amount of system resources
(again, using the windows scheduler will thus free up having to run this
large
resource intensive system called ms-access at all times).
