Hello all,

I have been reading and using this group for a while now and for most
of my questions I usually find my answer by searching through the
threads. So, thank you to all.

That is why I'm asking this question.

I have a business need. And I don't know whether I can use MS software
or should I look at a different software (which would not be ideal, due
to company security practices).

In our business, we purchasing a large amount of items. We work with
vendors to identify an appropriate initial piece price, initial tooling
costs, and initial development costs (there are a variety of other
costs which we also track). These prices and costs can and WILL change
multiple times during the development period of that product. We have
approximately five teams which develop products (with outside vendors).
Each team can have up to or exceed 40 sub-products during any given
time. Which means tracking becomes some what of a problem, when we have
an MS Access dB for each team, each team's sub-products, and each
sub-products products.

Reporting and data editing becomes a mission...

In the past, teams have used excel to produce pricing. But that meant
that when a new price came along (i.e. tooling cost increase/decreases)
the previous cost would be deleted. No historic tracking. So, a dB was
created...basically, bad design has allowed for the same problem. Plus,
the fact that Access has a negative appeal within our department. No
one wants to use Access because it's "difficult" to use; they are
comfortable with Excel.

With that said, it leads me to my question; We basically want to be
able to give our teams the ability to continue using Excel (because
they are comfortable with it), but we want to gather that data (which
is ALWAYS in a different format depending on the team, product, and/or
vendor). We basically want a real time connection between Excel and
Access, going both ways. If anyone is brave enough to use Access and
make a change, we would like the appropriate worksheet (which I have no
idea how to ID) to be updated with the change. And at the same time we
want Access to track those changes over time.

Do you all think this is something that I can do? Or do you think its
something where we need a consultant? If so, what kind of price are we
looking at to solve this issue?

Any and all help is greatly appreciated!!

Thanks!
Ernesto

Can you do it? Depends on your time and your experience with Access. I
don't think anyone here can answer that question for you.

As for cost? Depends on your location and the rate a consultant can get
elsewhere. In other words, if you are competing with financial
firms/investment banks for Access consultants you will pay more. If you're
competing with other industrial firms for Access consultants, you may not
have to pay as much.

Dave
--
Brevity is the soul of wit.


"Ernesto" wrote:

> Hello all,
>
> I have been reading and using this group for a while now and for most
> of my questions I usually find my answer by searching through the
> threads. So, thank you to all.
>
> That is why I'm asking this question.
>
> I have a business need. And I don't know whether I can use MS software
> or should I look at a different software (which would not be ideal, due
> to company security practices).
>
> In our business, we purchasing a large amount of items. We work with
> vendors to identify an appropriate initial piece price, initial tooling
> costs, and initial development costs (there are a variety of other
> costs which we also track). These prices and costs can and WILL change
> multiple times during the development period of that product. We have
> approximately five teams which develop products (with outside vendors).
> Each team can have up to or exceed 40 sub-products during any given
> time. Which means tracking becomes some what of a problem, when we have
> an MS Access dB for each team, each team's sub-products, and each
> sub-products products.
>
> Reporting and data editing becomes a mission...
>
> In the past, teams have used excel to produce pricing. But that meant
> that when a new price came along (i.e. tooling cost increase/decreases)
> the previous cost would be deleted. No historic tracking. So, a dB was
> created...basically, bad design has allowed for the same problem. Plus,
> the fact that Access has a negative appeal within our department. No
> one wants to use Access because it's "difficult" to use; they are
> comfortable with Excel.
>
> With that said, it leads me to my question; We basically want to be
> able to give our teams the ability to continue using Excel (because
> they are comfortable with it), but we want to gather that data (which
> is ALWAYS in a different format depending on the team, product, and/or
> vendor). We basically want a real time connection between Excel and
> Access, going both ways. If anyone is brave enough to use Access and
> make a change, we would like the appropriate worksheet (which I have no
> idea how to ID) to be updated with the change. And at the same time we
> want Access to track those changes over time.
>
> Do you all think this is something that I can do? Or do you think its
> something where we need a consultant? If so, what kind of price are we
> looking at to solve this issue?
>
> Any and all help is greatly appreciated!!
>
> Thanks!
> Ernesto
>
>

Excel is ideal for financial calculations - particularly where you want to
change one value and have it roll thru out an elaborate financial plan - -
-such as the annual budget assumptions or project cost estimating etc.

A database is better for tracking information. I fully understand that the
comfort level is there now for Excel, that is not uncommon, but it will be
painfull in the long run in terms of productivity and historic data tracking
to attempt to use Excel to do what is a database function.

Whether it is Access, mySQL, or any other SQL system - if it is perceived as
"hard" means it is not well designed from the user experience, or lack of
user training or both. So I don't think that should be layed at the feet of
Access vs mySQL vs some other database system.

Correctly designed Access Forms are typically used to shield the users from
having to actually learn Access or databases in general.

The only question Is whether your application too big in terms of potential
file size or transaction size - - not sure from your description but it
doesn't sound like it would be.....
--
NTC


"Ernesto" wrote:

> Hello all,
>
> I have been reading and using this group for a while now and for most
> of my questions I usually find my answer by searching through the
> threads. So, thank you to all.
>
> That is why I'm asking this question.
>
> I have a business need. And I don't know whether I can use MS software
> or should I look at a different software (which would not be ideal, due
> to company security practices).
>
> In our business, we purchasing a large amount of items. We work with
> vendors to identify an appropriate initial piece price, initial tooling
> costs, and initial development costs (there are a variety of other
> costs which we also track). These prices and costs can and WILL change
> multiple times during the development period of that product. We have
> approximately five teams which develop products (with outside vendors).
> Each team can have up to or exceed 40 sub-products during any given
> time. Which means tracking becomes some what of a problem, when we have
> an MS Access dB for each team, each team's sub-products, and each
> sub-products products.
>
> Reporting and data editing becomes a mission...
>
> In the past, teams have used excel to produce pricing. But that meant
> that when a new price came along (i.e. tooling cost increase/decreases)
> the previous cost would be deleted. No historic tracking. So, a dB was
> created...basically, bad design has allowed for the same problem. Plus,
> the fact that Access has a negative appeal within our department. No
> one wants to use Access because it's "difficult" to use; they are
> comfortable with Excel.
>
> With that said, it leads me to my question; We basically want to be
> able to give our teams the ability to continue using Excel (because
> they are comfortable with it), but we want to gather that data (which
> is ALWAYS in a different format depending on the team, product, and/or
> vendor). We basically want a real time connection between Excel and
> Access, going both ways. If anyone is brave enough to use Access and
> make a change, we would like the appropriate worksheet (which I have no
> idea how to ID) to be updated with the change. And at the same time we
> want Access to track those changes over time.
>
> Do you all think this is something that I can do? Or do you think its
> something where we need a consultant? If so, what kind of price are we
> looking at to solve this issue?
>
> Any and all help is greatly appreciated!!
>
> Thanks!
> Ernesto
>
>

The easiest way of buying a failure is to buy it for cheap (you can also buy
one for a high price but that's another story).

If your people find the database difficult to use in comparaison to Excel
then it's because it has been badly designed. A weel designed database
should not only be as easy as Excel but even be easier. It should also
offers you functionalities that you can't have actually with Excel, like an
history over the years and lot of useful reports.

However, a database is not some big calculator like Excel where you can put
everything everywhere you want (and by the same occasion, create new bugs,
errors and problems anytime): in a database, everything that you want to do
must be precisely determined and taken into account; down to the last minute
detail. So it's many times more difficult to design and create a database
than to simply use Excel. However, when the database is finished and
debugged, then it's finished for good. It will not be a roller-coaster like
Excel where the results might be good one week but the following week, will
require many days of work before findind the *error* that someone has
created when editing some formula on some obscur datasheet (if you ever find
it).

You must evaluate how much time your teams are passing each week working
with Excel to know if your company will benefit from paying the necessary $
to upgrade the whole system to a database. In my opinion, anyone trying to
use Excel for any long term tracking of data always finish to burry himself
below a big pile of spreadsheets. When you pass many days per week fighting
with Excel, then it's time to pass to something else.(And to pay for it:
like a good car, a good consultant is not free. You always get what you pay
for. Sometime you might get less but you will never get more.)

For the possibility of having a connection between Access and Excel, it's
possible; however, it's probably a bad solution to a badly defined problem.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Ernesto" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello all,
>
> I have been reading and using this group for a while now and for most
> of my questions I usually find my answer by searching through the
> threads. So, thank you to all.
>
> That is why I'm asking this question.
>
> I have a business need. And I don't know whether I can use MS software
> or should I look at a different software (which would not be ideal, due
> to company security practices).
>
> In our business, we purchasing a large amount of items. We work with
> vendors to identify an appropriate initial piece price, initial tooling
> costs, and initial development costs (there are a variety of other
> costs which we also track). These prices and costs can and WILL change
> multiple times during the development period of that product. We have
> approximately five teams which develop products (with outside vendors).
> Each team can have up to or exceed 40 sub-products during any given
> time. Which means tracking becomes some what of a problem, when we have
> an MS Access dB for each team, each team's sub-products, and each
> sub-products products.
>
> Reporting and data editing becomes a mission...
>
> In the past, teams have used excel to produce pricing. But that meant
> that when a new price came along (i.e. tooling cost increase/decreases)
> the previous cost would be deleted. No historic tracking. So, a dB was
> created...basically, bad design has allowed for the same problem. Plus,
> the fact that Access has a negative appeal within our department. No
> one wants to use Access because it's "difficult" to use; they are
> comfortable with Excel.
>
> With that said, it leads me to my question; We basically want to be
> able to give our teams the ability to continue using Excel (because
> they are comfortable with it), but we want to gather that data (which
> is ALWAYS in a different format depending on the team, product, and/or
> vendor). We basically want a real time connection between Excel and
> Access, going both ways. If anyone is brave enough to use Access and
> make a change, we would like the appropriate worksheet (which I have no
> idea how to ID) to be updated with the change. And at the same time we
> want Access to track those changes over time.
>
> Do you all think this is something that I can do? Or do you think its
> something where we need a consultant? If so, what kind of price are we
> looking at to solve this issue?
>
> Any and all help is greatly appreciated!!
>
> Thanks!
> Ernesto
>

how dare you talk **** about Excel in an Access newsgroup

go play in the freeway, ****tard


NetworkTrade wrote:
> Excel is ideal for financial calculations - particularly where you want to
> change one value and have it roll thru out an elaborate financial plan - -
> -such as the annual budget assumptions or project cost estimating etc.
>
> A database is better for tracking information. I fully understand that the
> comfort level is there now for Excel, that is not uncommon, but it will be
> painfull in the long run in terms of productivity and historic data tracking
> to attempt to use Excel to do what is a database function.
>
> Whether it is Access, mySQL, or any other SQL system - if it is perceived as
> "hard" means it is not well designed from the user experience, or lack of
> user training or both. So I don't think that should be layed at the feet of
> Access vs mySQL vs some other database system.
>
> Correctly designed Access Forms are typically used to shield the users from
> having to actually learn Access or databases in general.
>
> The only question Is whether your application too big in terms of potential
> file size or transaction size - - not sure from your description but it
> doesn't sound like it would be.....
> --
> NTC
>
>
> "Ernesto" wrote:
>
> > Hello all,
> >
> > I have been reading and using this group for a while now and for most
> > of my questions I usually find my answer by searching through the
> > threads. So, thank you to all.
> >
> > That is why I'm asking this question.
> >
> > I have a business need. And I don't know whether I can use MS software
> > or should I look at a different software (which would not be ideal, due
> > to company security practices).
> >
> > In our business, we purchasing a large amount of items. We work with
> > vendors to identify an appropriate initial piece price, initial tooling
> > costs, and initial development costs (there are a variety of other
> > costs which we also track). These prices and costs can and WILL change
> > multiple times during the development period of that product. We have
> > approximately five teams which develop products (with outside vendors).
> > Each team can have up to or exceed 40 sub-products during any given
> > time. Which means tracking becomes some what of a problem, when we have
> > an MS Access dB for each team, each team's sub-products, and each
> > sub-products products.
> >
> > Reporting and data editing becomes a mission...
> >
> > In the past, teams have used excel to produce pricing. But that meant
> > that when a new price came along (i.e. tooling cost increase/decreases)
> > the previous cost would be deleted. No historic tracking. So, a dB was
> > created...basically, bad design has allowed for the same problem. Plus,
> > the fact that Access has a negative appeal within our department. No
> > one wants to use Access because it's "difficult" to use; they are
> > comfortable with Excel.
> >
> > With that said, it leads me to my question; We basically want to be
> > able to give our teams the ability to continue using Excel (because
> > they are comfortable with it), but we want to gather that data (which
> > is ALWAYS in a different format depending on the team, product, and/or
> > vendor). We basically want a real time connection between Excel and
> > Access, going both ways. If anyone is brave enough to use Access and
> > make a change, we would like the appropriate worksheet (which I have no
> > idea how to ID) to be updated with the change. And at the same time we
> > want Access to track those changes over time.
> >
> > Do you all think this is something that I can do? Or do you think its
> > something where we need a consultant? If so, what kind of price are we
> > looking at to solve this issue?
> >
> > Any and all help is greatly appreciated!!
> >
> > Thanks!
> > Ernesto
> >
> >

Per Ernesto:
>Do you all think this is something that I can do? Or do you think its
>something where we need a consultant? If so, what kind of price are we
>looking at to solve this issue?

I would make a distinction between "Can" and "Should".

You probably can do it, but one's first efforts in any endeavor are not usually
their best... and application development has a way of taking over your life.

The application description, as stated, sounds reasonably simple and
straightforward.

But,as somebody once said "The important things are simple. The simple things
are hard, and the easy path is always mined."


For a ballpark number for a minimally-complex system I think 400 hours * $75 per
hour = $30,000. Once you get into it, things just tend to pyramid.

Somebody's going to chime in and say they can do it for half that - or even a
tenth of that. Maybe they can. Maybe I could...

Ok.... $15,000... or $3,000.... But you get the idea.... It's not going to be
$99.95.

OTOH, if you do it as your first development project, it's going to take a *lot*
more man hours than if a pro does it... and the results might be another
abomination.

OTOOH, it might be worth some of your time to search for an off-the-shelf
product that does 85% of what you want to do for just a few hundred dollars.
--
PeteCresswell

First off thank you to all for replying so quickly...second off...i'm
not talking down on excel...i love excel, its one of my fave
software...so i dont know where that comment came off...ok.

to try to answer some questions,

"The only question Is whether your application too big in terms of
potential
file size or transaction size - - not sure from your description but it

doesn't sound like it would be..... "

I think its more about transaction size. The amount of details that
needs to be taken into consideration is BIG!! We have mulitple part #s
which make up a kit which goes into one product with multiple
iterations. If that makes any sense congrats!! =)

I'm trying to construct a dB from scratch...to try to encompass all
needs...but our needs are changing on a daily basis. So i need to build
something that is almost "bullet-proof".

How would I go about finding a consultant. And would I need to pay from
posing the question/problem to him/her (generally speaking)?

Thanks again!
Ernesto


Sylvain Lafontaine (fill the blanks, no spam please) wrote:
> The easiest way of buying a failure is to buy it for cheap (you can also buy
> one for a high price but that's another story).
>
> If your people find the database difficult to use in comparaison to Excel
> then it's because it has been badly designed. A weel designed database
> should not only be as easy as Excel but even be easier. It should also
> offers you functionalities that you can't have actually with Excel, like an
> history over the years and lot of useful reports.
>
> However, a database is not some big calculator like Excel where you can put
> everything everywhere you want (and by the same occasion, create new bugs,
> errors and problems anytime): in a database, everything that you want to do
> must be precisely determined and taken into account; down to the last minute
> detail. So it's many times more difficult to design and create a database
> than to simply use Excel. However, when the database is finished and
> debugged, then it's finished for good. It will not be a roller-coaster like
> Excel where the results might be good one week but the following week, will
> require many days of work before findind the *error* that someone has
> created when editing some formula on some obscur datasheet (if you ever find
> it).
>
> You must evaluate how much time your teams are passing each week working
> with Excel to know if your company will benefit from paying the necessary $
> to upgrade the whole system to a database. In my opinion, anyone trying to
> use Excel for any long term tracking of data always finish to burry himself
> below a big pile of spreadsheets. When you pass many days per week fighting
> with Excel, then it's time to pass to something else.(And to pay for it:
> like a good car, a good consultant is not free. You always get what you pay
> for. Sometime you might get less but you will never get more.)
>
> For the possibility of having a connection between Access and Excel, it's
> possible; however, it's probably a bad solution to a badly defined problem.
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
>
> "Ernesto" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Hello all,
> >
> > I have been reading and using this group for a while now and for most
> > of my questions I usually find my answer by searching through the
> > threads. So, thank you to all.
> >
> > That is why I'm asking this question.
> >
> > I have a business need. And I don't know whether I can use MS software
> > or should I look at a different software (which would not be ideal, due
> > to company security practices).
> >
> > In our business, we purchasing a large amount of items. We work with
> > vendors to identify an appropriate initial piece price, initial tooling
> > costs, and initial development costs (there are a variety of other
> > costs which we also track). These prices and costs can and WILL change
> > multiple times during the development period of that product. We have
> > approximately five teams which develop products (with outside vendors).
> > Each team can have up to or exceed 40 sub-products during any given
> > time. Which means tracking becomes some what of a problem, when we have
> > an MS Access dB for each team, each team's sub-products, and each
> > sub-products products.
> >
> > Reporting and data editing becomes a mission...
> >
> > In the past, teams have used excel to produce pricing. But that meant
> > that when a new price came along (i.e. tooling cost increase/decreases)
> > the previous cost would be deleted. No historic tracking. So, a dB was
> > created...basically, bad design has allowed for the same problem. Plus,
> > the fact that Access has a negative appeal within our department. No
> > one wants to use Access because it's "difficult" to use; they are
> > comfortable with Excel.
> >
> > With that said, it leads me to my question; We basically want to be
> > able to give our teams the ability to continue using Excel (because
> > they are comfortable with it), but we want to gather that data (which
> > is ALWAYS in a different format depending on the team, product, and/or
> > vendor). We basically want a real time connection between Excel and
> > Access, going both ways. If anyone is brave enough to use Access and
> > make a change, we would like the appropriate worksheet (which I have no
> > idea how to ID) to be updated with the change. And at the same time we
> > want Access to track those changes over time.
> >
> > Do you all think this is something that I can do? Or do you think its
> > something where we need a consultant? If so, what kind of price are we
> > looking at to solve this issue?
> >
> > Any and all help is greatly appreciated!!
> >
> > Thanks!
> > Ernesto
> >

> OTOOH, it might be worth some of your time to search for an off-the-shelf
> product that does 85% of what you want to do for just a few hundred dollars.
> --
> PeteCresswell

What kind of "off-the-shelf" products would you suggest?

thanks!
ernesto

Per Ernesto:
>What kind of "off-the-shelf" products would you suggest?

I don't have a clue. That's why somebody would have to do some digging....
--
PeteCresswell

It's a good thing that you trying to construct the DB from scratch; as this
will give an opportunity to grasp the amount of work required. Here's the
bemol: when you will think that you have probably 90% of the work done, then
probably the real number will be closer to 10% instead of 90%.

As for the fact of paying or not the consultant; why should he or she work
for you for free? Will you do the same, working for someone else for free?

If youe ask your dentist if he can make a root treatment, the answer will be
free; however, if you're asking him if one of your teeth need a root
treatment, then the exam will not be free. Same thing for the consultant.
Probably that casual phone call of a few minutes will be free; however, I
don't see why one (or many) professional phone call over a length of many
hours should also be free.

For Excel, it's a free format: you can put anything anywhere you want.
There lies its strength but also its weakness. You cannot use these free
format worksheets to generate any useful reports/trends/historical data over
many projects, months, etc. You cannot also guarantee that there is no
error: the process of copying worksheets from an old project then update
them to a new project is probably very time consuming and source of a great
number of errors each time this process is repeated.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Ernesto" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> First off thank you to all for replying so quickly...second off...i'm
> not talking down on excel...i love excel, its one of my fave
> software...so i dont know where that comment came off...ok.
>
> to try to answer some questions,
>
> "The only question Is whether your application too big in terms of
> potential
> file size or transaction size - - not sure from your description but it
>
> doesn't sound like it would be..... "
>
> I think its more about transaction size. The amount of details that
> needs to be taken into consideration is BIG!! We have mulitple part #s
> which make up a kit which goes into one product with multiple
> iterations. If that makes any sense congrats!! =)
>
> I'm trying to construct a dB from scratch...to try to encompass all
> needs...but our needs are changing on a daily basis. So i need to build
> something that is almost "bullet-proof".
>
> How would I go about finding a consultant. And would I need to pay from
> posing the question/problem to him/her (generally speaking)?
>
> Thanks again!
> Ernesto
>
>
> Sylvain Lafontaine (fill the blanks, no spam please) wrote:
>> The easiest way of buying a failure is to buy it for cheap (you can also
>> buy
>> one for a high price but that's another story).
>>
>> If your people find the database difficult to use in comparaison to Excel
>> then it's because it has been badly designed. A weel designed database
>> should not only be as easy as Excel but even be easier. It should also
>> offers you functionalities that you can't have actually with Excel, like
>> an
>> history over the years and lot of useful reports.
>>
>> However, a database is not some big calculator like Excel where you can
>> put
>> everything everywhere you want (and by the same occasion, create new
>> bugs,
>> errors and problems anytime): in a database, everything that you want to
>> do
>> must be precisely determined and taken into account; down to the last
>> minute
>> detail. So it's many times more difficult to design and create a
>> database
>> than to simply use Excel. However, when the database is finished and
>> debugged, then it's finished for good. It will not be a roller-coaster
>> like
>> Excel where the results might be good one week but the following week,
>> will
>> require many days of work before findind the *error* that someone has
>> created when editing some formula on some obscur datasheet (if you ever
>> find
>> it).
>>
>> You must evaluate how much time your teams are passing each week working
>> with Excel to know if your company will benefit from paying the necessary
>> $
>> to upgrade the whole system to a database. In my opinion, anyone trying
>> to
>> use Excel for any long term tracking of data always finish to burry
>> himself
>> below a big pile of spreadsheets. When you pass many days per week
>> fighting
>> with Excel, then it's time to pass to something else.(And to pay for it:
>> like a good car, a good consultant is not free. You always get what you
>> pay
>> for. Sometime you might get less but you will never get more.)
>>
>> For the possibility of having a connection between Access and Excel, it's
>> possible; however, it's probably a bad solution to a badly defined
>> problem.
>>
>> --
>> Sylvain Lafontaine, ing.
>> MVP - Technologies Virtual-PC
>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>
>>
>> "Ernesto" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > Hello all,
>> >
>> > I have been reading and using this group for a while now and for most
>> > of my questions I usually find my answer by searching through the
>> > threads. So, thank you to all.
>> >
>> > That is why I'm asking this question.
>> >
>> > I have a business need. And I don't know whether I can use MS software
>> > or should I look at a different software (which would not be ideal, due
>> > to company security practices).
>> >
>> > In our business, we purchasing a large amount of items. We work with
>> > vendors to identify an appropriate initial piece price, initial tooling
>> > costs, and initial development costs (there are a variety of other
>> > costs which we also track). These prices and costs can and WILL change
>> > multiple times during the development period of that product. We have
>> > approximately five teams which develop products (with outside vendors).
>> > Each team can have up to or exceed 40 sub-products during any given
>> > time. Which means tracking becomes some what of a problem, when we have
>> > an MS Access dB for each team, each team's sub-products, and each
>> > sub-products products.
>> >
>> > Reporting and data editing becomes a mission...
>> >
>> > In the past, teams have used excel to produce pricing. But that meant
>> > that when a new price came along (i.e. tooling cost increase/decreases)
>> > the previous cost would be deleted. No historic tracking. So, a dB was
>> > created...basically, bad design has allowed for the same problem. Plus,
>> > the fact that Access has a negative appeal within our department. No
>> > one wants to use Access because it's "difficult" to use; they are
>> > comfortable with Excel.
>> >
>> > With that said, it leads me to my question; We basically want to be
>> > able to give our teams the ability to continue using Excel (because
>> > they are comfortable with it), but we want to gather that data (which
>> > is ALWAYS in a different format depending on the team, product, and/or
>> > vendor). We basically want a real time connection between Excel and
>> > Access, going both ways. If anyone is brave enough to use Access and
>> > make a change, we would like the appropriate worksheet (which I have no
>> > idea how to ID) to be updated with the change. And at the same time we
>> > want Access to track those changes over time.
>> >
>> > Do you all think this is something that I can do? Or do you think its
>> > something where we need a consultant? If so, what kind of price are we
>> > looking at to solve this issue?
>> >
>> > Any and all help is greatly appreciated!!
>> >
>> > Thanks!
>> > Ernesto
>> >
>