DB size?
- Thread starter Franknstuff
- Start date
M
Mike375
Guest
KenHigg said:
It has over 2000 macros, about 700 forms, 1200 queries and 300 tables. About 1/3rd is no longer used.
A prospect category has 22 queries, 12 macros, 2 tables (plus some common to all categories of prospects) and 13 forms. So there are 980 objects there for the 20 categories plus quite a lot more that is a common to each category.
It also has heaps of objects for product comparisons plus heaps more for various gov't compliance requirments. Then there are all the objects for premiun rate/quote system for different companies. The fact that we make ourt rate/quote systems rather than the ones the insurance company will supply might tell you something.
However there is more than one data base
One data base is used to reformat phone numbers on prospect lists we buy. It will remove any number spaces and any keyboard character. I have it set for the common ones that go with phone numbers such as ( ) - _ etc and I can enter any character in another field and will remove that character from the phone numbers.
Then there are other data bases that bring in client policy details each month from insurance companies. The reason these are all in differnt data bases is the process to bring each company is very similar but by adding another data base as a copy it only takes me a couple of minutes to make the DB for another insurance company. to it one data base I would of course need different form names etc. When the data base runs through the results are then put in the main data based.
Then there are other data bases which are simply a couple of tables and these hold bulk listings of prospects.
Then there is another set of data bases that brings in the commission statements from the insurance companies on Excel. After the data base converts it all over to the form we need then the data goes to the main data base.
Then there is another set of data bases that have propsects names which we have taken through the telemarketing/sales process but where we have not been successful. Many of these names are sold to people outside the life insurance business\nad the main data base put these names in various tables depending on the results of the phone call.
We also sell names back to the name list suppliers since our calling process has "cleaned up" the names.
And there is one other set of DBs. These are used for entering prospect names such as medical specialists, lawyers and dentists. These data bases allow for ease of entry with such things as the specialists qualifications. They also have quite a bit of text manipulation fucntions so that the person entering can type in
William J mcdonald as opposed to to entering in different fields. Same deal for Suburb, State and postcode. These data bases also fix things like mc into Mc and so on.
So in the main data base is really a processing unti and 99% of the records are either heading into the data base and then in most cases being tossed out the other end.
Mike
Pauldohert
Something in here
- Local time
- Today, 14:19
- Joined
- Apr 6, 2004
- Messages
- 2,097
Rich I apologise! I didn't say anything against you, just questioned your previous post, which I think you have succesfully answered - the way I would have done , and Mike would have done and everyone else. You just seemed to imply you did things right first time and that was that.
As we now agree the worlds unfortunatley not that simple.
Are you a Insurance Salesmen?
- or is your only reply (to date) to Mikes Oracle question as uphelpful and insulting as it seems.
If I am wrong - I apologise again.
Mike is here to learn too - like you and me and everyone else.
http://www.access-programmers.co.uk/forums/showthread.php?t=68229
Ken - I hope my calculation is right.
Paul
As we now agree the worlds unfortunatley not that simple.
Are you a Insurance Salesmen?
- or is your only reply (to date) to Mikes Oracle question as uphelpful and insulting as it seems.
If I am wrong - I apologise again.
Mike is here to learn too - like you and me and everyone else.
http://www.access-programmers.co.uk/forums/showthread.php?t=68229
Ken - I hope my calculation is right.
Paul
R
Rich
Guest
now I think that's where we differ if Mike's replies to those who tried to offer help are taken into accountPauldohert said:
M
Mike375
Guest
Rich said:now I think that's where we differ if Mike's replies to those who tried to offer help are taken into account
Rich,
You are quite wrong.
Firstly, I did not post on this thread with "my data base has lots of macros etc, how do I fix it"
Amost everyone is saying "fix it" and then Pat Hartman produces an article where the chosen author says it is better for the developer to start from scratch if encountering a data base of this type.
It has been said a few times it will "crash" but when I ask for elaboration none is posted.
If I become an overnight coding sensation then what do I do.....take a lot a of time out of my business and at the end of the process when I click on something the same data displays.
Yesterday I added another insurance company for the product comparison part of the data base and that took me about 10 minutes. Are you suggesting that I should have set aside a few days to learn the coding etc. and etc Or do you think I was better off doing it in 10 minutes and then spending the day entering the policy wording information so it is functional and can be used. But it would be much worse than that because I would need to change the product comparison part of the data base. After I had learnt all of that and then made it all I would still have the same output.
I do learn by looking at the site and have copied and kept some of the coding in a separate data base. A couple of days ago Mile O Phile gave me the code to duplicate a Setvalue macro for change of recordsource. I tried it and it worked. Now do you think I should take the time to change all the macros that run a recordsource SetValue. Well, to do that I would have to learn some more because several SetValue recordsource macros are run by other macros or the Setvalue actions are part of other large macros.
Mike
Rakier
Registered User.
- Local time
- Today, 22:19
- Joined
- Mar 21, 2002
- Messages
- 75
It's been said before and I'll say it again.
If it works...it works. Doesn't matter how it get's done, as long as Mike is happy with it and it works for him then that is all that matters.
Mike, I think the article that Pat posted the link to is pretty much what I was trying to say. I redesigned my old dB because it was basically impossible to figure out/remember what I had done when I first designed it. I started from the ground up and rebuilt it over a period of a year. Like you, my job is not computer related and I built my dB to use to help me in my job. It has ended up being used by 12 different supervisory people too. It took me a long time to build because of my workload at work and the fact that I have 5 small kids at home didn't leave me much spare time. But I did rebuild it. It has been used for 3 years now with no problems. Besides that fact, I am currently building it again because I have learned much in those three years and expect the dB to be bigger, badder and faster than it is now when I am done.
I'm not doing this because it doesn't work...or because it's required, but because I want to improve upon my old design and make it better. In one of your earlier replies to my reply, you said "My database is not a piece of shit." I never said it was. It is your way of accomplishing a task that you needed to accomplish. It works...so that's great. You have probably done more with the program than 80% of the people out there. It's true that you did not ask anyone to "fix" it or "how can I fix it", but I've found that the people that populate this forum are usually quick to comment on how to do something different (better in their opinions
) and rarely mean it in a condescending or negative way.
That said, again, I do redesigns not because the dB doesn't work (or won't work in the future), but because I learn and like to learn new things about Access, VBA, etc... all the time. It is that hunger to learn and improve my skills that drives me. My dB may still be crap, but it keeps getting better all the time, mainly because of the information that I gain from this and other sites.
I think that most of my concerns with your dB lie in what Miles said regarding the upgrading from Access95. I know that I had some issues from 97 to 2000 because of macros (there are none in my current dB) so I'm sure that you may encounter some of those conversion errors.
In conclusion...keep on keepin' on.
If it works...it works. Doesn't matter how it get's done, as long as Mike is happy with it and it works for him then that is all that matters.
Mike, I think the article that Pat posted the link to is pretty much what I was trying to say. I redesigned my old dB because it was basically impossible to figure out/remember what I had done when I first designed it. I started from the ground up and rebuilt it over a period of a year. Like you, my job is not computer related and I built my dB to use to help me in my job. It has ended up being used by 12 different supervisory people too. It took me a long time to build because of my workload at work and the fact that I have 5 small kids at home didn't leave me much spare time. But I did rebuild it. It has been used for 3 years now with no problems. Besides that fact, I am currently building it again because I have learned much in those three years and expect the dB to be bigger, badder and faster than it is now when I am done.
I'm not doing this because it doesn't work...or because it's required, but because I want to improve upon my old design and make it better. In one of your earlier replies to my reply, you said "My database is not a piece of shit." I never said it was. It is your way of accomplishing a task that you needed to accomplish. It works...so that's great. You have probably done more with the program than 80% of the people out there. It's true that you did not ask anyone to "fix" it or "how can I fix it", but I've found that the people that populate this forum are usually quick to comment on how to do something different (better in their opinions
) and rarely mean it in a condescending or negative way. That said, again, I do redesigns not because the dB doesn't work (or won't work in the future), but because I learn and like to learn new things about Access, VBA, etc... all the time. It is that hunger to learn and improve my skills that drives me. My dB may still be crap, but it keeps getting better all the time, mainly because of the information that I gain from this and other sites.
I think that most of my concerns with your dB lie in what Miles said regarding the upgrading from Access95. I know that I had some issues from 97 to 2000 because of macros (there are none in my current dB) so I'm sure that you may encounter some of those conversion errors.
In conclusion...keep on keepin' on.
R
Rich
Guest
but you're missing the point Mike, your db as is, is alread taking a lot of time out of your business, how mayn 10minutes a week do you spend on maintaining it? It takes me 13.2 seconds to add another customer to my db
Rakier
Registered User.
- Local time
- Today, 22:19
- Joined
- Mar 21, 2002
- Messages
- 75
That is true Rich. Never thought of it that way. Takes me about that long to add items, vendor or customer information to my dB also. I agree that the time savings are huge.
Also Mike, another point about this that I think someone else brought up a while back. It's the issue of survivability. If something happened to you and you were unable to work for awhile, could someone else step in and keep the dB running. With mine, they could and do (when I'm on vacation, etc...) Just a thought.
Also Mike, another point about this that I think someone else brought up a while back. It's the issue of survivability. If something happened to you and you were unable to work for awhile, could someone else step in and keep the dB running. With mine, they could and do (when I'm on vacation, etc...) Just a thought.
M
Mike375
Guest
Rich said:
Rich,
As I said on another posting 99% of the time I spend doing something to this data base is entering policy wording.
But I don't think you have the correct picture on the 10 minutes for the other insurance company to be added. That is table with about 30 records. Basically each record has a field for Policy Feature, then a memo field for the wording on that feature for Company A and another memo field for Company B and then a memo field for Key Differences. There are some other fileds for times, dates ID numbers etc.
Now if I had one table with 20 companies and the 600 records then I will need to select with a query when a particular comparison is done and so I eliminate that query. In reality the product compartitor uses one table but deletes and appends to that table from one of the insurance company tables. I select the company to be used for the comparison from a list and then runsa macro that runs the correct append query. It does that way because sometimes we a change in the Key Difference for different one off circumstances...but that does not change the original.
For me, it would also be messier adding the records to one table rather than just copying one of the other tables and giving it the appropriate name and then hooking it up to the system and then changing the policy wording for the other insurance company.
But the bottom line is that to add that the other company is about two days to get the final result and 47 hours and 50 minutes is the data entry and doing the key differences on policy wording and checking different things with some legal people.
Mike
M
Mike375
Guest
Rakier said:
The one part that needs me is the entering of policy wording but that is not a computer issue.
Adding another insurance company as I mentioned in my previous posting is a once in a blue moon deal.
Adding a new record is also 10 seconds like yours. You click a label New Record and then you are given the screen and the usual stuff with required fields etc. But that is only a very odd time. Most records in this data base are placed in a holding table in bulk and taken from other .mdb files. As the calls are make then mames are consumed. A macro runs and knows which category of prospect and how many of those names need to be placed in the MainTable.
Just for fun, i converted that macro to code and here it is. This runs 32 categories of prospects. 12 of these categories are treated differently the group of 20 I have mentioned earlier.....Mike
PS. I cut the middle out of it as it is long for the system to accept. It is 26682 characters
'------------------------------------------------------------
' GetNewNamesQuery
'
'------------------------------------------------------------
Function GetNewNamesQuery()
On Error GoTo GetNewNamesQuery_Err
DoCmd.Echo True, ""
DoCmd.SetWarnings False
DoCmd.OpenForm "CatSelector", acNormal, "", "", acEdit, acNormal
Forms!CatSelector!CatSelect = 1
DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Form, Records, Save Record
Forms!CatSelector.RecordSource = "Query209"
DoCmd.OpenForm "NamesUsed", acNormal, "", "", acEdit, acNormal
DoCmd.SelectObject acForm, "CatSelector", False
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.RunMacro "ProspectCounter", Forms!NamesUsed!CountOfParents, ""
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query206", acNormal, acEdit
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query207", acNormal, acEdit
End If
DoCmd.Close acForm, "NamesUsed"
DoCmd.Echo True, ""
DoCmd.OpenForm "CatSelector", acNormal, "", "", acEdit, acNormal
Forms!CatSelector!CatSelect = 2
DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Form, Records, Save Record
Forms!CatSelector.RecordSource = "Query209"
DoCmd.OpenForm "NamesUsed", acNormal, "", "", acEdit, acNormal
DoCmd.SelectObject acForm, "CatSelector", False
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.RunMacro "ProspectCounter", Forms!NamesUsed!CountOfParents, ""
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query206", acNormal, acEdit
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query207", acNormal, acEdit
End If
DoCmd.Close acForm, "NamesUsed"
DoCmd.Echo True, ""
DoCmd.OpenForm "CatSelector", acNormal, "", "", acEdit, acNormal
Forms!CatSelector!CatSelect = 3
DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Form, Records, Save Record
Forms!CatSelector.RecordSource = "Query209"
DoCmd.OpenForm "NamesUsed", acNormal, "", "", acEdit, acNormal
DoCmd.SelectObject acForm, "CatSelector", False
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.RunMacro "ProspectCounter", Forms!NamesUsed!CountOfParents, ""
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query206", acNormal, acEdit
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query207", acNormal, acEdit
End If
DoCmd.Close acForm, "NamesUsed"
DoCmd.OpenForm "CatSelector", acNormal, "", "", acEdit, acNormal
Forms!CatSelector!CatSelect = 29
DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Form, Records, Save Record
Forms!CatSelector.RecordSource = "Query209"
DoCmd.OpenForm "NamesUsed", acNormal, "", "", acEdit, acNormal
DoCmd.SelectObject acForm, "CatSelector", False
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.RunMacro "ProspectCounter", Forms!NamesUsed!CountOfParents, ""
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query206", acNormal, acEdit
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query207", acNormal, acEdit
End If
DoCmd.Close acForm, "NamesUsed"
DoCmd.OpenForm "CatSelector", acNormal, "", "", acEdit, acNormal
Forms!CatSelector!CatSelect = 30
DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Form, Records, Save Record
Forms!CatSelector.RecordSource = "Query209"
DoCmd.OpenForm "NamesUsed", acNormal, "", "", acEdit, acNormal
DoCmd.SelectObject acForm, "CatSelector", False
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.RunMacro "ProspectCounter", Forms!NamesUsed!CountOfParents, ""
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query206", acNormal, acEdit
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query207", acNormal, acEdit
End If
DoCmd.Close acForm, "NamesUsed"
DoCmd.OpenForm "CatSelector", acNormal, "", "", acEdit, acNormal
Forms!CatSelector!CatSelect = 31
DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Form, Records, Save Record
Forms!CatSelector.RecordSource = "Query209"
DoCmd.OpenForm "NamesUsed", acNormal, "", "", acEdit, acNormal
DoCmd.SelectObject acForm, "CatSelector", False
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.RunMacro "ProspectCounter", Forms!NamesUsed!CountOfParents, ""
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query206", acNormal, acEdit
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query207", acNormal, acEdit
End If
DoCmd.Close acForm, "NamesUsed"
DoCmd.OpenForm "CatSelector", acNormal, "", "", acEdit, acNormal
Forms!CatSelector!CatSelect = 32
DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Form, Records, Save Record
Forms!CatSelector.RecordSource = "Query209"
DoCmd.OpenForm "NamesUsed", acNormal, "", "", acEdit, acNormal
DoCmd.SelectObject acForm, "CatSelector", False
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.RunMacro "ProspectCounter", Forms!NamesUsed!CountOfParents, ""
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query206", acNormal, acEdit
End If
If (Forms!NamesUsed!CountOfParents > 0) Then
DoCmd.OpenQuery "Query207", acNormal, acEdit
End If
DoCmd.Close acForm, "NamesUsed"
DoCmd.OpenQuery "Query62Append", acNormal, acEdit
DoCmd.OpenQuery "Query62Delete", acNormal, acEdit
DoCmd.OpenForm "SRCancel", acNormal, "", "", acEdit, acNormal
DoCmd.RunMacro "Macro135SR", , ""
DoCmd.Close acForm, "SRCancel"
DoCmd.OpenForm "TransferNumbers", acNormal, "", "", acEdit, acNormal
DoCmd.RunMacro "Macro910", , ""
GetNewNamesQuery_Exit:
Exit Function
GetNewNamesQuery_Err:
MsgBox Error$
Resume GetNewNamesQuery_Exit
End Function
R
Rich
Guest
your converted macro shows some of the limitations of macros and their conversion. Oh and DoMenuItem should be replaced with the RunCommand equiv.
M
Mike375
Guest
Rich said:
Isn't the DoMenuItem as a macro replaced by Runcommand macro action in later versions of Access.
Rakier
Registered User.
- Local time
- Today, 22:19
- Joined
- Mar 21, 2002
- Messages
- 75
One other thing to consider Mike. Eventually, you will run out of room. I'm not sure, but I think Access has a limit on the number of objects that can be in a database. Again, I'm not sure about that...but I thought I saw it somewhere. Also, each object takes up space and even if there is no limit to the maximum number of objects, you will eventually push against the size limits for a dB in Access95 which I believe has some effect on performance and reliability.
Like Pat though, I can see that no number of arguments are ever going to change your mind or position. You are content with the way things are and have no desire to change them. I hope that you don't encounter any problems. I know that you are tired of all the nebulous warnings that have been given, but believe me....Pat, Miles, Rich, etc... know quite a bit more about Access than I do, and probably more than you will ever know. You may have the knowledge of the insurance industry, but when it comes to developing databases, these people are the best. I would advise you to heed their warnings and learn from them. Best of luck.
I know...I know... "Yes, but..."
Like Pat though, I can see that no number of arguments are ever going to change your mind or position. You are content with the way things are and have no desire to change them. I hope that you don't encounter any problems. I know that you are tired of all the nebulous warnings that have been given, but believe me....Pat, Miles, Rich, etc... know quite a bit more about Access than I do, and probably more than you will ever know. You may have the knowledge of the insurance industry, but when it comes to developing databases, these people are the best. I would advise you to heed their warnings and learn from them. Best of luck.
I know...I know... "Yes, but..."
M
Mike375
Guest
Pat Hartman,
That code was converted by Access, not me.
When that macro was made I made two sections then tested. When it worked then simply copy and paste and then run down the page and change the category number.
From your post:
I suspect though that if your partner had any clue what you have done, he would disagree strongly because of the jeopardy to your joint business should you become unable to continue as primary developer.
If you took the time to read what people say you would see that 99% of the work on this data base is entering policy wording to reflect changes by the insurance companies.
What you also fail to realise is that if something happens to me the business would no longer continue to exist and that has nothing to do with the computer program.
Another thing you fail to realise is that both of us will probably retire in 2 or 3 years and sell this business.
If you spent more time making data bases and using them and getting yourself out and about instead of make a mammoth number of postings you would know that a business like this when sold will be to a larger group and they could not care less whether there was Dloop or whatever. It is what the data base does and why it does and the screen designs.
I might also add that the obvious extreme frustrattion my data bases causes you only illustrates your limitations and if a potential customer was reading this thread they would not want your services.
Mike
That code was converted by Access, not me.
When that macro was made I made two sections then tested. When it worked then simply copy and paste and then run down the page and change the category number.
From your post:
I suspect though that if your partner had any clue what you have done, he would disagree strongly because of the jeopardy to your joint business should you become unable to continue as primary developer.
If you took the time to read what people say you would see that 99% of the work on this data base is entering policy wording to reflect changes by the insurance companies.
What you also fail to realise is that if something happens to me the business would no longer continue to exist and that has nothing to do with the computer program.
Another thing you fail to realise is that both of us will probably retire in 2 or 3 years and sell this business.
If you spent more time making data bases and using them and getting yourself out and about instead of make a mammoth number of postings you would know that a business like this when sold will be to a larger group and they could not care less whether there was Dloop or whatever. It is what the data base does and why it does and the screen designs.
I might also add that the obvious extreme frustrattion my data bases causes you only illustrates your limitations and if a potential customer was reading this thread they would not want your services.
Mike
R
Rich
Guest
Mike375 said:
now you really are taking the piss
M
Mike375
Guest
Rakier,
One other thing to consider Mike. Eventually, you will run out of room. I'm not sure, but I think Access has a limit on the number of objects that can be in a database. Again, I'm not sure about that...but I thought I saw it somewhere. Also, each object takes up space and even if there is no limit to the maximum number of objects, you will eventually push against the size limits for a dB in Access95 which I believe has some effect on performance and reliability.
The books say 1GB. I have some here that are 300mb but they are only a bunch of tables that are storing a lot of records.
I don't know about the number of objects but I could easily knock out 1/3rd of them and export them to another .mdb file as they are no longer used except sometimes I refer back to them.
Like Pat though, I can see that no number of arguments are ever going to change your mind or position. You are content with the way things are and have no desire to change them.
The desire I have to make changes to the data base is small and that small desire is completely squashed by the time factor involved.
I hope that you don't encounter any problems. I know that you are tired of all the nebulous warnings that have been given, but believe me....Pat, Miles, Rich, etc... know quite a bit more about Access than I do, and probably more than you will ever know.
I am very aware that they know a 100 times more about Access than I do but there is nothing I can do about the problems they say will come, at least not at the present time. However, the message does not seem to get across that is a data base that is basically static.
I know...I know... "Yes, but..."
That keeps getting said because some people are only focused on what they want to say and appear to be unable to grasp the simple idea that time is a totally prohibitive factor and that this data base is not one that is under development.
All this lose talk about.....use code etc is all fine but how long would it take me to learn what is required and then how long would it take to change not just this data base but all the smaller surrounding data bases, all of which would need to be changed.
It is not a case of me not accepting what they say but a case of not being able to do it due to time.
Mie
One other thing to consider Mike. Eventually, you will run out of room. I'm not sure, but I think Access has a limit on the number of objects that can be in a database. Again, I'm not sure about that...but I thought I saw it somewhere. Also, each object takes up space and even if there is no limit to the maximum number of objects, you will eventually push against the size limits for a dB in Access95 which I believe has some effect on performance and reliability.
The books say 1GB. I have some here that are 300mb but they are only a bunch of tables that are storing a lot of records.
I don't know about the number of objects but I could easily knock out 1/3rd of them and export them to another .mdb file as they are no longer used except sometimes I refer back to them.
Like Pat though, I can see that no number of arguments are ever going to change your mind or position. You are content with the way things are and have no desire to change them.
The desire I have to make changes to the data base is small and that small desire is completely squashed by the time factor involved.
I hope that you don't encounter any problems. I know that you are tired of all the nebulous warnings that have been given, but believe me....Pat, Miles, Rich, etc... know quite a bit more about Access than I do, and probably more than you will ever know.
I am very aware that they know a 100 times more about Access than I do but there is nothing I can do about the problems they say will come, at least not at the present time. However, the message does not seem to get across that is a data base that is basically static.
I know...I know... "Yes, but..."
That keeps getting said because some people are only focused on what they want to say and appear to be unable to grasp the simple idea that time is a totally prohibitive factor and that this data base is not one that is under development.
All this lose talk about.....use code etc is all fine but how long would it take me to learn what is required and then how long would it take to change not just this data base but all the smaller surrounding data bases, all of which would need to be changed.
It is not a case of me not accepting what they say but a case of not being able to do it due to time.
Mie
M
Mike375
Guest
Rich said:now you really are taking the piss
I simply reponded in like
Hey Mikey,
I knew from reading the start of this thread that it wasn't going to be very
productive with respect to software development.
HOWEVER, if I had a company that needed an application developed., I
would SURELY contact Pat/Rich. They would definitely provide a software configuration that they could LEAVE. They wouldn't have to be on retainer
or much less a full time employee.
This is an educational forum. The threads here serve to enhance the
member's knowledge of Access and the nuances that certain applications
require.
Granted, your software works for you, and you are willing to constantly
modify it to keep it in "synch" with the real world. GREAT!
It has been an interesting thread (Location should have been WaterCooler),
but I've had enough.
Wayne
p.s. The guidance provided by the people you slammed is invaluable to the
members here. I don't appreciate (respect or condone) you trying to
degrade them because of your deficiencies.
I knew from reading the start of this thread that it wasn't going to be very
productive with respect to software development.
HOWEVER, if I had a company that needed an application developed., I
would SURELY contact Pat/Rich. They would definitely provide a software configuration that they could LEAVE. They wouldn't have to be on retainer
or much less a full time employee.
This is an educational forum. The threads here serve to enhance the
member's knowledge of Access and the nuances that certain applications
require.
Granted, your software works for you, and you are willing to constantly
modify it to keep it in "synch" with the real world. GREAT!
It has been an interesting thread (Location should have been WaterCooler),
but I've had enough.
Wayne
p.s. The guidance provided by the people you slammed is invaluable to the
members here. I don't appreciate (respect or condone) you trying to
degrade them because of your deficiencies.
M
Mike375
Guest
Dear Wayne,
You will note that my role on this thread has been one of response. You will also see it is Pat Hatrman who has raised the stakes at different points, including her first posting on the thread.
From your posting:
Granted, your software works for you, and you are willing to constantly
modify it to keep it in "synch" with the real world. GREAT!
Well I would really like to see how a Pat Hartman data base needs nothing done when:
1) Policy wording must be changed when the insurance company changes its policies and or policy wordings.
2) When the insurance company changes its premium rating methods and especially the larger policy discounting system and switches from a discount based on pemium size to a discount based on sum insured or benefit size. Or it changes the combination in which various benefits can be combined.
3) When an insurance company changes the format in which it sends commission statements on Excel.
4) When the insurance company changes completely the format in which they send the base premium rate for the various policies.
5) When one of the companies that we buy lists of names from changes their format or we buy from another supplier.
Now here is a question or a scenario.
At present if the insurance company does any of the above then I can make the changes here myself, on the spot and quickly. Policy wording is an exceptions as that can involve a lot of typing and time with legal people.
Now lets say we can click our fingers and instantly my data base looks like a Part Hartman special. What do I do when the insurance company makes some of the above changes. Well I will tell you what I would have to do and that is what other groups have to do....."we won't be able to use that section of our software for a while as the ABC insurance company has made some changes and the computer people will be coming down next week etc. and etc."
Now why would I want to put myself through all of that. Tell me what I am missing?
She accuses me with a look down her nose attitude that will I go on using macros. So if I am a victim of one of the changes I listed above do I:
1) Use my dreaded macros and be in business the day of the day of the change or do I
2) Not use macros etc and then learn all the coding she or yourself knows and let the data base sit idle while I learn.
Mike
You will note that my role on this thread has been one of response. You will also see it is Pat Hatrman who has raised the stakes at different points, including her first posting on the thread.
From your posting:
Granted, your software works for you, and you are willing to constantly
modify it to keep it in "synch" with the real world. GREAT!
Well I would really like to see how a Pat Hartman data base needs nothing done when:
1) Policy wording must be changed when the insurance company changes its policies and or policy wordings.
2) When the insurance company changes its premium rating methods and especially the larger policy discounting system and switches from a discount based on pemium size to a discount based on sum insured or benefit size. Or it changes the combination in which various benefits can be combined.
3) When an insurance company changes the format in which it sends commission statements on Excel.
4) When the insurance company changes completely the format in which they send the base premium rate for the various policies.
5) When one of the companies that we buy lists of names from changes their format or we buy from another supplier.
Now here is a question or a scenario.
At present if the insurance company does any of the above then I can make the changes here myself, on the spot and quickly. Policy wording is an exceptions as that can involve a lot of typing and time with legal people.
Now lets say we can click our fingers and instantly my data base looks like a Part Hartman special. What do I do when the insurance company makes some of the above changes. Well I will tell you what I would have to do and that is what other groups have to do....."we won't be able to use that section of our software for a while as the ABC insurance company has made some changes and the computer people will be coming down next week etc. and etc."
Now why would I want to put myself through all of that. Tell me what I am missing?
She accuses me with a look down her nose attitude that will I go on using macros. So if I am a victim of one of the changes I listed above do I:
1) Use my dreaded macros and be in business the day of the day of the change or do I
2) Not use macros etc and then learn all the coding she or yourself knows and let the data base sit idle while I learn.
Mike
Pauldohert
Something in here
- Local time
- Today, 14:19
- Joined
- Apr 6, 2004
- Messages
- 2,097
I hope we all continue to offer Mike the benefit of our experiences however valuable they may be. Whether or not Mike heeds the advice (for whatever reason) is not really the point - only Mike can decide what is best for him to do.
- Mike should be congratulated with getting such an unconventional database to work, and what an impact he has made since he arrived.
Importantly the answers serve as a resource for all, and I am sure we have all learned something from this thread ( though I don't know what! )
I look forward to Mike starting a new thread and learning from him and the replys!
paul
- Mike should be congratulated with getting such an unconventional database to work, and what an impact he has made since he arrived.
Importantly the answers serve as a resource for all, and I am sure we have all learned something from this thread ( though I don't know what! )
I look forward to Mike starting a new thread and learning from him and the replys!
paul
Similar threads
