Whe is a D Base too complex ?

[Guest]

Hi

Has anyone come across a situation where they look at a screen and think –
enough is enough, that’s too complex – and what made you think this.

I have been asked to “add†some functionality to an existing database.
Basically this is to add the option of hiring equipment from a group of shops
that already use access to run virtually the entire operation (stock control,
accounts, invoicing, staff management, etc,etc). I wrote the application.

My question.
I can add the “Hire†facility to the existing “Sales†and stock controlâ€
functions (there is little different other than the stock is floating).
There will be a (non-technical word) “bloody great heap†of new forms (due
to touch screen size limitations most of which are popup) and queries - only
one table though.
So
Does anyone have any very general advice or tips on when to simply “stop
adding to†and create another database. There is nothing wrong with adding
this new functionality but what I am thinking is that it “may†be better to
create a stand alone application with linking options. I have added "stuff"
to DB's before but never on this scale - as shops tend to "sell" things this
means I need to contructs the function or selling with the stock release and
floating (in and out same items) stock.

I know it’s unusual question, but this is at least 3 months work so I would
like to start off right – (would be the 1st time LoL). It would be
problematical to either have to combine or separate the new application later
(maybe I’m just being lazy).

I am not asking for the "how to do it" but simply "where to" - combined or
seperate.

Any tips or hints would be really helpful.

Many thanks

 

[John Nurick]

Hi Wayne,

You need to distinguish carefully here between the data store and the
front end.

If the new functionality requires data that's in the existing data
store, then (for me at least) ceteribus paribus there's a presumption in
favour of using it and adding whatever new tables are needed.

On the other hand there's sometimes a case for dividing the
functionality between two or more front ends that use the same data
store, especially if different groups of users do quite different
things, or if some functionality is only provided for some groups of
users. I've done that in one system: it currently has three front ends:
one for everyday CRM use; one to retrieve statistical information; and
one for maintenance and ad-hoc queries not available in the GUI-based
CRM.

I think you may be in that situation. The shops and invoicing and staff
and all will presumably be the same in the hiring option as in existing
operations, so you'll want to use the same data store. But it may make
maintenance easier if you split the overall functionality into two or
more front ends (e.g. one for admin, one for sales and hires).

 

[Guest]

Good points thanks.

At the moments I am just sitting here looking at the "dream sheet" that I
been given. ie. we want it to do this and that and .........
I am thinking of spilting the stock functions so that the hire and sales
both have access to it but adding one simple field ([floating]) which should
get around the .... is it for for hire and sale or just sale (a loaf of bread
can be sold but not hired, etc - bad example I know).

The back end is on MS Server so I "should" be able to split the hire and
sales just to the face to face staff's front ends and leave the rest as is.
Oh well will think about it for a while and see what crops up into my head
(hopefully it will agree with the dream sheet ??)

Oh yes (English is not my 1st language) so hope I understood but this case
is deff. not ceteribus paribus - would be much simpler if it was.

Thank you for your tips they are a great help

 

[John Nurick]

Obviously I don't know your structures. But I think it may take more
than one field. Assuming you have one entity to track the various
products you sell or hire, and another to track the various items that
you actually have in stock:

-some products can be sold but not hired, others can be hired but not
sold and some can be either.

-individual items can be held for sale, for hire, or either ... but once
an item has been hired it can't be sold ... until a decision is taken to
dispose of it at a discount (comparable to selling demonstrator or
shopsoiled stock).

both have access to it but adding one simple field ([floating]) which should
get around the .... is it for for hire and sale or just sale (a loaf of bread
can be sold but not hired, etc - bad example I know).

 

[Guest]

Hi John

Thanks for your imput. This situation is slightly different. Items that
have been hired in the past are (at the end of the "life") donated to
charity.

The extra field will work as it will simply be an indication of if the item
can be hired. Of course if not it will by default simply be an item of sale
stock. The whole idea to is to simple hire out some items that are normally
sold (thus float back to stock after income). I may have misexplained - the
extra field will be in the stock table. There will (as I put) be another new
table for the hire details date out/in cost/ etc etc. BUT the vast majority
of these will be "free" rental as they will be included in other costs.

As I said the situation is strange so it is not possible to look around for
other DB's as no-one else has ever or will ever do this (on this scale). The
hire has worked for the past 20 years but recorded on paper. I have been
asked to try and bring this process into the 21st century. Of course it is
complecated by item being lost stolen broken etc etc also lifespan
maintainence, etc etc etc need to be looked at and included - it's quite a
large project.

Oh and I have already thought about the relationships between the functions
and you are right that one table will not do. Ha Ha Ha - I told you was
being lazy.

LoL - Maybe Microsoft will reinvent the typewriter and filing cabinet then
my life would be simpler (but I think I would need a larger office)




--
Wayne
Manchester, England.

Obviously I don't know your structures. But I think it may take more
than one field. Assuming you have one entity to track the various
products you sell or hire, and another to track the various items that
you actually have in stock:

-some products can be sold but not hired, others can be hired but not
sold and some can be either.

-individual items can be held for sale, for hire, or either ... but once
an item has been hired it can't be sold ... until a decision is taken to
dispose of it at a discount (comparable to selling demonstrator or
shopsoiled stock).

both have access to it but adding one simple field ([floating]) which should
get around the .... is it for for hire and sale or just sale (a loaf of bread
can be sold but not hired, etc - bad example I know).

 

[Tony Toews]

Has anyone come across a situation where they look at a screen and think –
enough is enough, that’s too complex – and what made you think this.

So long as the menus and such are organized so that users have a
minimum of "layers" to get to their forms then go for it.

One app I worked on for about a year and a half had 450 forms and 350
reports.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm