DB size?

[Mile-O]

Don't feel guilty, Frank.....


Mike's database will never see the light of day outwith his own sphere of employment because:

• It is poorly designed;
• It is an ancient version of Access that, once converted to a later version of Access, won't stand up to scrutiny and will have many errors;
• Has no error handling;
• Requires numerous man hours when alterations are required;
• Is slow;
• Is too specific to a specific insurance company;
• Is too specific to an insurance type.

 

[WayneRyan]

Jeepers!

This thread is interesting (shouldn't it be in the WaterCooler?).

When I first started with computers ... Rule #1 was that if
automating the app saved you time/effort then it was worthwhile.
Otherwise, forget it. To Mike, this obviously saves him time/effort,
he's happy with it, therefore it must be GOOD!

Whether his DB is normalized, abnormalized, or a complete travesty
of everything that we hold near and dear is beside the point.

Granted, it may be better designed, but it surely does the job
that he intends, he is familiar with it... so let's move on.

Now, if we can get him to post it, maybe some of (us/you) can show
him just how really sweet life can be!

Wayne

 

[Mile-O]

Now, if we can get him to post it, maybe some of (us/you) can show him just how really sweet life can be!

That would be nice.

As for the "if it works for him then that's okay" part, he's talked about selling the bloody monster which, from what we've heard of it is wrong - nobody in their right mind would buy it.

 

[Franknstuff]

Oh yea!

Please don't try to make me fell less guilty. Picked a bad time to quit drinking!

 

[WayneRyan]

WOW!

I read this thread earlier, but waited about 4 hours to post.
A lot sure transpired right before I posted.

First of all; If this was a software design meeting, I'd be
swimming back to shore right now. Don't think much positive
tech info will come out of this enterprise.

Frankenstein - Boy did you create a monster!

Mike - Your s/w works for you. Great!

"We develop an application and move on. The applications ultimately
need to be understood and maintained by others. We also cannot be
creating maintenance nightmares. Our clients need to be able to add
a new salesperson or department or customer or whatever without
calling on us to create a slew of new objects."

Your software is the opposite of that. You need intervention
constantly in your app. I don't have the faintest idea what
that dialog was meant to accomplish.

Pat & Mile (Mile & Pat?) spent a bit of their time here to give you
some thoughts about how to structure your data. I just hope
other readers of this thread can benefit from it.

The fact that you can sort your data sideways doesn't mean you
have to define it in such a high-maintenance way.

My original thought on this was that if Mike's software saved
him more time/effort than it took to develop THEN it is good.
If he's happy, so am I.

I'm moving on ... see ya
Wayne

 

[Mike375]

That would be nice.

As for the "if it works for him then that's okay" part, he's talked about selling the bloody monster which, from what we've heard of it is wrong - nobody in their right mind would buy it.

Mile,

The reason people people buy data bases like this one or part of it is due to the design, not the computer design of course. Invariably "parts" of it are bought. The main thing I have to weigh up are the negatives of my competitors having it if the whole "system" was sold.

About 3 years ago I sold part of it to a life insurance company and I can assure you they could not care less whether it had a macro or a code running something or whether it was on Access 95 or whatever. Their main interest is in the whats and whys of what it does and especially the "whys" and in particular the screens.

The problem that continually arises is that the people in the insurance company or outside contactors don't make something that suits the life insurance selling environment. Input they get from insurance agents is usually just this side of useless because the agents don't really use the data base stuff very much because whatever they get is too hard to use and so their input is frequently way off base. Financial planning and General insurance tends to be somewhat different as it does not have the same sort of selling environment as does life and disability insurance.

Mike

 

[ChrisO]

In my opinion, not that that should make any difference, this is a great thread.

Rightly or wrongly, people have stuck to their convictions.

It is refreshing to me to see someone that is prepared to take on the establishment.

Mike375.
I applaud your efforts, even though I think you are wrong.

Pat
If I may quote you…(It is not my place.)
“Don't be so sure about that. Lots of people have bought SAP and spent 10's of millions to install it!!”

My last brush with SAP (and the SAP’s that try to run it in my opinion) desperately tried to offload the ‘detail’ to something else… namely Access.

SAP = Good.
Detail = Good.
SAP = Not Detail.

There is a lot more to that story but, for the moment, would simply muddy the waters.

Regards,
Chris.

 

[The Stoat]

Hi all,

Mike your knowledge of your environment may be indepth/unique etc however a competent systems analyst would be able to transfer your knowledge into a structure that a database developer would understand. Most developers who post on this board do their own systems analysis and development. For big projects it is often necessary for the company to employ a systems analyst or team of analysts if they don't already have one/them. There is a distinct profession of systems analyst. They are able to decipher the complexities of business systems regardless of the environment. That is not to say that some don't specialize but the tools used are good for 99% of all industries/military etc. In the UK contracts for the Government are expected to be run using PRINCE 2 project managment and Structured Systems and Design Methodology (SSADM). I use both.

A true story:

I went to college in the evenings to "learn" IT. My first course was on database implementation. I understood nothing. Fortunatley the course work said "Create a system that is able to do x,y and z" at the end of the module i designed an Excel system and argued in my write up that function should take precedent over implementation. I got a good grade purely because "You have designed a system that works". A year later i did systems analysis. Within 5 minutes I realised that they had got the 2 modules in the wrong order. Even knowing very little about Access at the time, I was able to take the systems analysis and create a complex database in 2 weeks. The systems analysis took 8 weeks!

I honestly don't think this discussion can really be resolved. A well designed database structure does not necessarily mean a well implemented interface. A poorly designed database structure may have a fantastic interface. But a poorly designed structure will always take up more space, be slower, take more maintainence and be less efficient. To be honest i would find it 10 times easier to teach someone good database design than good interface design. If you have a good understanding of interface design then learning how to properly design the relationships and structures will lead you to develop even more useful, simple interfaces. And i will guarantee that you will do the whole process in less than half the time.

TS

 

[Mike375]

TS

You covered much of it in your last paragraph.

When you make the data base like I do much of it is done on the run. Contrary to much of what has been posted, for me, being able to change things very quickly is of prime importance and it is often done under poor conditions.

As an example (and this might be incorrect but is based on my current knowledge) I would not touch coding with OnClick attached to labels. The reason is that sometimes we make some changes while calls are being made and with a macro I just bring the data base forward and make the changes with the data base fully open and ready for the next call. I think with code I would have to close down and go to design view on the form.

Having said that I don't for one moment think that several people on this thread can't make the data base better than myself.

In fact there are several things I would change but simply don't get around to it. For example there are about 8 or 9 combo boxes that do a Setvalue on AfterUpdate for a time drop down list. Australia has a 3 hour time gap during daylight saving from East to West and 1 hour South to North and we telemarket right across Australia while doing all calls in Sydney. When we come off daylight saving the time zones are the same for South to North and drop to two hours for East to West.

So..if we are calling someone in the West and during daylight saving and they say...can you call back at 3pm...then the data base sticks in 6pm, which will be the time in Sydney.

In my case I have a set value action for the West of

[Forms]![2ProspectT]![RingT5]+(0.0208333333*6)

And that sets the value for [RingT5]. When daylight saving finishes I have to go back and change (0.0208333333*6) to (0.0208333333*4)

Since it is only twice a year I never get around to having the setvalue reference a field. Might do it tonight

PS, if I get a moment a bit later I will try and call. Must be just after lunch in good old mother England.

Regards,

Mike

 

[Mile-O]

So..if we are calling someone in the West and during daylight saving and they say...can you call back at 3pm...then the data base sticks in 6pm, which will be the time in Sydney.

In my case I have a set value action for the West of

[Forms]![2ProspectT]![RingT5]+(0.0208333333*6)

And that sets the value for [RingT5]. When daylight saving finishes I have to go back and change (0.0208333333*6) to (0.0208333333*4)

I'd keep all my times as the same Time format but, for locations have a GMT offset within the locations table.

It would remove the need to hard code time conversions into the database.

 

[Mike375]

I'd keep all my times as the same Time format but, for locations have a GMT offset within the locations table.

As I said above I don't have any reservations about you and others being able to make the stuff better.

But we do get down to time involved for change.

For example that field [RingT5] has a lot of things that hang off it. Also consider it probably takes me about 2 minutes a year to change for the daylight saving. Of course I also acknowledge that as simple as the change is it is way above what someone without Access knowledge could do.

Mike

 

[Mile-O]

Would I be right in guessing that you don't even have this database split into a front and backend?

 

[Mike375]

Would I be right in guessing that you don't even have this database split into a front and backend?

You are 10000% right

I have done that before just to do it!! I am assuming you mean that all the forms, queries etc are in one .mdb file and the tables other in another .mdb file.

Mike

 

[Mile-O]

I am assuming you mean that all the forms, queries etc are in one .mdb file and the tables other in another .mdb file.

Yes, I am.

 

[Rich]

Yes, I am.

...therefore I must be ?

 

[Mile-O]

...therefore I must be ?

cogito cogito ergo cogito sum

 

[Mike375]

Yes, I am.

I can't see any point to it, at least for the way things run here.

Firstly, while we have computers networked each computer runs the data base as a stand alone item and with its own set of records. One computer runs 5 salesman and basically covers the various things that happen from an initial cold call through interviews where a first appointment was obtained plus the various administration and various product comparison letters.

The data base is backed up as whole unit to a CD ROM about every 60 to 90 minutes as are about 50 letters that are stored which are run from the data base.

My limited understanding is that by having front and back end that someone can do work on the data base while it is being used.

Mike

 

[Kevin_S]

The problem that continually arises is that the people in the insurance company or outside contactors don't make something that suits the life insurance selling environment. Input they get from insurance agents is usually just this side of useless because the agents don't really use the data base stuff very much because whatever they get is too hard to use and so their input is frequently way off base. Financial planning and General insurance tends to be somewhat different as it does not have the same sort of selling environment as does life and disability insurance.

Mike - you are probably right by saying that "outsiders" to the insurance companies don't understand the processes and environment well enough and, therefore, design interfaces that do not meet the needs of the business. Also - it sounds like your understanding of the environment and need allows you to create interfaces that are valuable to your chosen professiona and that is great so.... I think it would be really valuable to you and possibly a career designing these systems for sale in the future if you did some studying on normalization, the normal forms, and relational database design. There is a TON of info on this website on these topics and you can gain a lot of knowledge from here...

Please DO NOT interpret this as an attack on you as that is not my intention - I'm simply trying to suggest to you what I and others here feel would benefit you... There are also a large number of books available on Amazon that deal with this topic - My Suggestion: The first book I read on the subject of database normalization was titled: Information Modeling and Relational Databases - from cenceptual analysis to logical design by Haplin, Morgan, & Kaufmann. It covers all the basics and some of the more advanced theory as well...

HTH and good luck to you...

p.s. I would suggestion splitting the database and having all FE w/ interface on each terminal with one backend - this way there is no data reconciliate the data at a later date - but this is your choice...

Kevin

 

[Franknstuff]

This got me

"My limited understanding is that by having front and back end that someone can do work on the data base while it is being used.

Mike"

Am I reading this right?

If anybody wants to make me feel better I have a question under forms that I could use an answer.

 

[Rakier]

Mike,

I understand your point of view...if it ain't broke, then why fix it. It works for you and that is the most important thing. However, you have to understand that the folks here are trying to help, not attack. Just because something works doesn't make it right.

I have one big database that I first created several years ago using macros and stuff because that was how I first learned things. Then I discovered this forum and the wonders of code. I completely redesigned the db and it worked much...much...much better after that, mainly due to things I found out on this forum. Did the old version work...yes. Was it right....no. Did the new version work better....yes. Since that time, I have redesigned sections of the db and am in the process of doing a complete redesign. Like I said...it has been working for 3 years and working well. But...I have learned new and better ways of doing things during that time and want the dB to take advantage of those new things.

Like Pat said earlier...it is about learning. I constantly am learning new ways to do this or that and try to take advantage of them. I have learned ways to change my 20 lines of code into 10. Even though things work, it doesn't mean that they should stay static. Everything must change over time.

I am not a "professional" developer by any stretch of the imagination. But...that doesn't mean that I don't respect those who are and listen to their ideas and bits of wisdom. Is everything they say taken as the absolute best way? No...but it never hurts to try their ideas out.

Remember, you must evolve...learn new ways. I really do not think that the way that you have designed your dB is the best way to do it. I think that you could benefit from the advice given by Pat, Miles and Rich. I know that I have benefited many times over from their words of wisdom. I know that this would involve a huge paradigm shift for you...as well as a large amount of work to redesign the dB. This may not be of any interest to you. After all, it works. But...in the long run, the advice given by all here would give you a system that worked better and faster and would be way easier to maintain.
I know this from past experience. I took their advice and have a system that works lightyears better than what I had before.

Just my two cents.