By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,656 Members | 920 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,656 IT Pros & Developers. It's quick & easy.

Lowest cost migration of VBA -Access '97 accounting source code? To what?

P: n/a
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.

Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.

I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!

Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]

[P.S. Will "heads up" regarding whether VBA for Access will ever
migrate to VTSO versionX ?]
Nov 13 '05 #1
Share this Question
Share on Google+
41 Replies


P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are 3 accounting packages in Access provided by

www.accountingsuccess.com

Look at the comparison chart for more info. It doesn't seem to have a
job-cost module.

--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQQRwFIechKqOuFEgEQIerwCcDyZgVYekxqJfjBIvH3Qwb1 3cjKoAoJlM
ZrZSPY0N6021OStq/MBPlVkK
=yW8V
-----END PGP SIGNATURE-----

Matt Alanzo wrote:
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.

Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.

I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!

Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]

[P.S. Will "heads up" regarding whether VBA for Access will ever
migrate to VTSO versionX ?]


Nov 13 '05 #2

P: n/a
On Sun, 25 Jul 2004 21:05:50 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.
Actually, although Quickbooks is a closed storage architecture, they've
finally provided a good programmer API, so you don't have to import and export
files in bizzare formats to interpoerate with it and extend it.
Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.
Upgrade to SQL Server, sure, if there's a reason to do so. Is there a
requirement you have that the MDB engine is not able to meet? As for VBA
2003, from what I can tell, the 2003 development tools are not yet ready for
prime time, so I'd do it in 2002. Once they fix 2003, everything should port
just fine.

As for VBA being discontinued, actually, Microsoft seems to be marketing VBA
heavily for 3rd party use, has listed some neat high-end features for the next
release of VBA, so there's no sign of it being discontinued by any means.
I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!
Worse than that, the customizations usually cost almost as much as it would
cost you to do it from scartch, and then the customizations usually interfere
with upgrading. If you can do what you want using a program with a supported
external API such as Quickbooks, at least, the API is not likely to change,
and you won't be touching the internals of the provided code, so the upgrade
issues are vastly smaller. Of course, you'll have to do some research to see
if you can or can't do what you want with some product's public API.
Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]


I have helped clients wrestle with the exact same issues multiple times, and
there's just no easy answer. If you're a 2-person outfit, or a 10 million
gross per year corporation, there are lots of decent options. Otherwise, it's
a problem.

Personally, I've always thought that there should be a consortium of
medium-small businesses that maintain an open source small ERP/MRP
application. This would be similar to the Apache Web Server project. None of
the companies make money by selling Web servers, so it's better for all
concerned to go ahead and share the cost for professional work on a product
they all need to support their various core businesses, and share the rewards
of the combined effort.
Nov 13 '05 #3

P: n/a

"Matt Alanzo" <ac**********@emailias.com> wrote in message
news:ld********************************@4ax.com...
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.

Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.

I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!

Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]

[P.S. Will "heads up" regarding whether VBA for Access will ever
migrate to VTSO versionX ?]

It sounds like you need a bank loan more than anything.


Nov 13 '05 #4

P: n/a
On Sun, 25 Jul 2004 21:23:54 -0600, "XMVP" <ac***********@hotmail.com> wrote:

....

It sounds like you need a bank loan more than anything.


Resident troll - ignore.
Nov 13 '05 #5

P: n/a
Matt Alanzo <ac**********@emailias.com> wrote:
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry.
For his convenience. Which he might have a point. Can he definitely state that his
fees will drop $x per year in which case he has a financial case which will save you
money? What about annual upgrade and mtce fees?
Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.
Agreed.
Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA.
Why? Two person company doesn't need SQL Server. As far as Office 2003 what does
it get you over Access 97? Likely not much. The conversion to A2003 isn't that
difficult but conceivably could take an experienced person a day or two depending on
the number of forms and reports which require testing and combing through.
My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.
MS has done an excellent job of providing upgradability in the past. Access is the
most heavily used development environment on the planet. They will not be dropping
VBA support any time soon.

One of the very interesting points of the recent leak of Windows source code was to
what lengths MS would ensure buggy software from other vendors would still work on
newer versions of the OS.

Besides A97 works just fine on Win XP and should work just fine for the conceivable
future.
I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!
Sounds about right.
Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]

[P.S. Will "heads up" regarding whether VBA for Access will ever
migrate to VTSO versionX ?]


There are no plans to drop VBA. MS can't drop VBA as there are way too many apps
which require VBA now.

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
Nov 13 '05 #6

P: n/a
On Mon, 26 Jul 2004 02:51:53 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
On Sun, 25 Jul 2004 21:05:50 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.
Actually, although Quickbooks is a closed storage architecture, they've
finally provided a good programmer API, so you don't have to import and export
files in bizzare formats to interpoerate with it and extend it.


I've already spoken to the QODBC folks (based on the QB API) but that
option appears to be a case of trying to make a silk purse out of a
sows ear. Why revert to a flat file with a ODBC kludge interface ...
that bogs down after three tables linked..
Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.


Upgrade to SQL Server, sure, if there's a reason to do so. Is there a
requirement you have that the MDB engine is not able to meet? As for VBA
2003, from what I can tell, the 2003 development tools are not yet ready for
prime time, so I'd do it in 2002. Once they fix 2003, everything should port
just fine.


The SQL Server 2005 Express Edition includes numerous XML interface
which hopefully, will help dramatically on data input from future web
site, web service apps, etc. If both MSDE and SQL Server 2005
Express Edition cost the same (FREE) and cost about the same to target
new VBA code then the SQL Server 2005 Express Edition offers a better
value. [I'm not a programmer so this is very speculative on my part.]
As for VBA being discontinued, actually, Microsoft seems to be marketing VBA
heavily for 3rd party use, has listed some neat high-end features for the next
release of VBA, so there's no sign of it being discontinued by any means.

Ken Getz's article gave me great assurance on this point. (Just
tripped across it.)
http://www.advisor.com/doc/13516
I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!


Worse than that, the customizations usually cost almost as much as it would
cost you to do it from scartch, and then the customizations usually interfere
with upgrading. If you can do what you want using a program with a supported
external API such as Quickbooks, at least, the API is not likely to change,
and you won't be touching the internals of the provided code, so the upgrade
issues are vastly smaller. Of course, you'll have to do some research to see
if you can or can't do what you want with some product's public API.
Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]


I have helped clients wrestle with the exact same issues multiple times, and
there's just no easy answer. If you're a 2-person outfit, or a 10 million
gross per year corporation, there are lots of decent options. Otherwise, it's
a problem.

Personally, I've always thought that there should be a consortium of
medium-small businesses that maintain an open source small ERP/MRP
application. This would be similar to the Apache Web Server project. None of
the companies make money by selling Web servers, so it's better for all
concerned to go ahead and share the cost for professional work on a product
they all need to support their various core businesses, and share the rewards
of the combined effort.


Some of the open source repositories that focus on Linux claim to
offer ERP but I am reluctant to switch OS's this late in life. Too
much invested in Windows apps both from a $oftware and a learning
curve standpoint.
there are lots of decent options.


Could you elaborate on those "decent options"?

Nov 13 '05 #7

P: n/a
On Mon, 26 Jul 2004 00:22:59 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:
On Mon, 26 Jul 2004 02:51:53 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
On Sun, 25 Jul 2004 21:05:50 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.


Actually, although Quickbooks is a closed storage architecture, they've
finally provided a good programmer API, so you don't have to import and export
files in bizzare formats to interpoerate with it and extend it.


I've already spoken to the QODBC folks (based on the QB API) but that
option appears to be a case of trying to make a silk purse out of a
sows ear. Why revert to a flat file with a ODBC kludge interface ...
that bogs down after three tables linked..


No, I don't mean you should use a faked database library interface. There's
just a plain ol' COM library interface. Forget direct SQL queries. If you
need to work with data in a database format, just copy it into and out of your
own normalized database format that meets the needs of your own code
components.
Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.


Upgrade to SQL Server, sure, if there's a reason to do so. Is there a
requirement you have that the MDB engine is not able to meet? As for VBA
2003, from what I can tell, the 2003 development tools are not yet ready for
prime time, so I'd do it in 2002. Once they fix 2003, everything should port
just fine.


The SQL Server 2005 Express Edition includes numerous XML interface
which hopefully, will help dramatically on data input from future web
site, web service apps, etc. If both MSDE and SQL Server 2005
Express Edition cost the same (FREE) and cost about the same to target
new VBA code then the SQL Server 2005 Express Edition offers a better
value. [I'm not a programmer so this is very speculative on my part.]

If there's a reason to do it, it's not usually to bad of an upsizing process.
If the original UI is not designed in a C/S freindly way, some forms may need
optimizing, and some queries might need to be partially converted to views, or
converted to stored procedures. Most usually won't.

....
Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]


I have helped clients wrestle with the exact same issues multiple times, and
there's just no easy answer. If you're a 2-person outfit, or a 10 million
gross per year corporation, there are lots of decent options. Otherwise, it's
a problem.

Personally, I've always thought that there should be a consortium of
medium-small businesses that maintain an open source small ERP/MRP
application. This would be similar to the Apache Web Server project. None of
the companies make money by selling Web servers, so it's better for all
concerned to go ahead and share the cost for professional work on a product
they all need to support their various core businesses, and share the rewards
of the combined effort.


Some of the open source repositories that focus on Linux claim to
offer ERP but I am reluctant to switch OS's this late in life. Too
much invested in Windows apps both from a $oftware and a learning
curve standpoint.


I know. I think the GNUe effor runs on Mono, and should be able to run on
..NET, but I don't know if that ever went anywhere. I always thought it had
too ambitious of an initial goal, and was an overengineered design, but I
could be wrong.
there are lots of decent options.


Could you elaborate on those "decent options"?


Well, if you're really small, you probably don't need anything other than
what's built in to Quickbooks, and some excel spreasheets you can hack
together from CSV exports. If you are a big corporation, there's Peoplesoft,
SAP, the Oracle products, etc.

In the mid-range, there are mostly some poorly engineered Access apps (well
engineered Access apps are certainly possible, but no one seems to be selling
one in this area), and there's a product from Computer Associates that I can't
remember the name of. The problem with the CA product is that the affordable
version is not customizable, and you pay a -lot- more to get it with source
code. For all I know, there's some good, modular, affordable product for
medium sized businesses hiding under the leaves somewhere, but it's either new
since I last searched, or I've never found it.
Nov 13 '05 #8

P: n/a
Follow-up reply...

I just realized you said you are a 2-person company. From the nature of your
question, I had assumed you were a larger company. I presume that there is
something about your structure or industry that makes your companies needs
more like those of a larger, 10-30 person company? If so, read my previous
replies in that context.

If not, I encourage you to try to live with off-the-shelf offerings as much as
possible for now, and use a few losely coupled external apps for custom
requirements. By the time you need something more integrated, it's likely
that the commercial products will cover it somewhat. Otherwise, you'll know
the real requirement better then than now.

Regarding data entry costs, don't do that. I'm 90% sure you could pay a
programmer a modest fee to write code to push your existing data into
Quickbooks via the COM API.

On Sun, 25 Jul 2004 21:05:50 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.

Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.

I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!

Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]

[P.S. Will "heads up" regarding whether VBA for Access will ever
migrate to VTSO versionX ?]


Nov 13 '05 #9

P: n/a
On Mon, 26 Jul 2004 06:24:04 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
Follow-up reply...

I just realized you said you are a 2-person company. From the nature of your
question, I had assumed you were a larger company. I presume that there is
something about your structure or industry that makes your companies needs
more like those of a larger, 10-30 person company? If so, read my previous
replies in that context.

I've grown to depend heavily on our custom created job "gross margin"
components report, , i.e. total "gross margin", then by "gross margin"
job, then within job by vendor, then within vendor by purchase order.
These each have columns for each phase, i.e. order entry (customer PO
net of vendor POs), invoiced (invoices to customers net of invoices
from vendors [again by job, by po]), cashflow (cash payments from
customers net of our payments to vendors [again by job, buy po]), job
completion/audit (after all POs, invoices, payments, retainage, etc.)
..

Beyond that we have a bunch of ad hoc reports based on SQL queries.
QB's reporting doesn't even come close. Guess I'm spoiled.

Nov 13 '05 #10

P: n/a
On Sun, 25 Jul 2004 21:05:50 -0500, Matt Alanzo
<ac**********@emailias.com> wrote:

I just posted this project as a bid on RentACoder. Hopefully they
will have it "listed" tomorrow.
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total).

Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.


Nov 13 '05 #11

P: n/a
On Mon, 26 Jul 2004 06:24:04 GMT, Steve Jorgensen <no****@nospam.nospam>
wrote:
Follow-up reply... ....Regarding data entry costs, don't do that. I'm 90% sure you could pay a
programmer a modest fee to write code to push your existing data into
Quickbooks via the COM API.


I wanted to add more detail to that. I've talked to customers who have paid
for data entry into a new application, and it never goes as planned, or costs
what it should.

First, don't -ever- have anyone do somthing like this without having your own
backup of your complete data set that you have actually restored from to make
sure you can get it all back, both code and data, in a usable form. There's a
fairly large, finite chance, that whoever is doing the input will find a way
to trash whatever copy of your data they have. This is actually true of
either manual inputters or programmers creating an automated transfer.

Next, the estimate is low. That's often true of the programmer, too, but just
to be aware. In my experience, the programmer's estimate is usually closer,
particularly if the programmer does a lot of data translation work for a
living, and is familliar with the product the data is being transferred to.

Finally, the quality of your original data matters a lot. If your data is
reasonably well normalized, and lacks inconsistencies, the job will go pretty
smoothly. Otherwise, someone's going to spend a lot of time figuring out
where an inconsistency comes from and asking you how it needs to be resolved
to be correct. Each time this happens, some work stops until the problem is
identified, you can be reached, you can figure out what to do, you can
communicate your answer back, and they can implement the solution or
work-around.
Nov 13 '05 #12

P: n/a
Steve Jorgensen <no****@nospam.nospam> wrote in message news:<qf********************************@4ax.com>. ..
Personally, I've always thought that there should be a consortium of
medium-small businesses that maintain an open source small ERP/MRP
application. This would be similar to the Apache Web Server project. None of
the companies make money by selling Web servers, so it's better for all
concerned to go ahead and share the cost for professional work on a product
they all need to support their various core businesses, and share the rewards
of the combined effort.


I have found that as a small developer the largest weaknesses I have
are with Accounting software and electronic Medicare billing software.
Both areas require keeping up with changes in current law or practice.
I don't have problems with the Medicare billing software anymore
because when the client went to Great Plains Accounting for their
accounting, GPA gladly offered to handle that too along with all
database development work and web design. It's their right to do so,
but it's also my right to decide who gets future accounting software
recommendations :-). That client was my primary client at the time so
it did hurt a little. It worked out though. I got a new client just
before then and they were delighted that I would be able to do more
work for them. That new client gives me more work than they did so
everyone is happy. Almost. The old client paid $120,000 to GPA for
the new software package along with $5,000 per month for software
maintenance (not counting new features). It now takes up to a month
for them to get new forms added. Since ten other companies are also
using the same software, if a new feature is not one that they all can
use they aren't even allowed to have the new feature.

Now, I am given exclusive rights to repackage and sell any software
developed for the new client provided they get a copy of the source
code they are using and that any similar company owned by the same
owner can use the software. It's a pretty sweet deal. They love the
custom business software I've created for them so much that the idea
of having a CPA, who I met while working for the old client :-), to
help me create custom accounting software for their companies is very
appealing. The CPA has seen what Access can do and would really enjoy
having her vision of accounting put into code. She has a small team
of financial researchers who can keep up with the latest changes in
tax laws. Plus, besides getting paid to do it, we will have a
starting point to do the same thing with other companies. Current
clients who are using accounting software like Quickbooks can stay
with that or switch to a custom solution. A consortium like you are
suggesting would enable small developers to keep everything in Access
or at least in something that talks well with Access without having to
recode from scratch.

James A. Fortune
Nov 13 '05 #13

P: n/a
On 26 Jul 2004 00:49:18 -0700, ja******@oakland.edu (James Fortune) wrote:
Steve Jorgensen <no****@nospam.nospam> wrote in message news:<qf********************************@4ax.com>. ..
Personally, I've always thought that there should be a consortium of
medium-small businesses that maintain an open source small ERP/MRP
application. This would be similar to the Apache Web Server project. None of
the companies make money by selling Web servers, so it's better for all
concerned to go ahead and share the cost for professional work on a product
they all need to support their various core businesses, and share the rewards
of the combined effort.


I have found that as a small developer the largest weaknesses I have
are with Accounting software and electronic Medicare billing software.
Both areas require keeping up with changes in current law or practice.
I don't have problems with the Medicare billing software anymore
because when the client went to Great Plains Accounting for their
accounting, GPA gladly offered to handle that too along with all
database development work and web design. It's their right to do so,
but it's also my right to decide who gets future accounting software
recommendations :-). That client was my primary client at the time so
it did hurt a little. It worked out though. I got a new client just
before then and they were delighted that I would be able to do more
work for them. That new client gives me more work than they did so
everyone is happy. Almost. The old client paid $120,000 to GPA for
the new software package along with $5,000 per month for software
maintenance (not counting new features). It now takes up to a month
for them to get new forms added. Since ten other companies are also
using the same software, if a new feature is not one that they all can
use they aren't even allowed to have the new feature.

Now, I am given exclusive rights to repackage and sell any software
developed for the new client provided they get a copy of the source
code they are using and that any similar company owned by the same
owner can use the software. It's a pretty sweet deal. They love the
custom business software I've created for them so much that the idea
of having a CPA, who I met while working for the old client :-), to
help me create custom accounting software for their companies is very
appealing. The CPA has seen what Access can do and would really enjoy
having her vision of accounting put into code. She has a small team
of financial researchers who can keep up with the latest changes in
tax laws. Plus, besides getting paid to do it, we will have a
starting point to do the same thing with other companies. Current
clients who are using accounting software like Quickbooks can stay
with that or switch to a custom solution. A consortium like you are
suggesting would enable small developers to keep everything in Access
or at least in something that talks well with Access without having to
recode from scratch.

James A. Fortune


So, are you saying you'd want to do work for such a consortium, and try to
sell clients on paying us to do work on such a project? Perhaps, we should
start a project site on Sourceforge, or something.

Actually, I have one client right now who could really benefir from something
like that, and stubbornly refuses to consider it. For some reason, he wants
everything about his software to be as closed as possible. he doesn;t even
want me to take copies of the code I work on for him off site. He never
explained his motivation, and it's not at all clear to me.
Nov 13 '05 #14

P: n/a
On Mon, 26 Jul 2004 06:17:56 GMT, Steve Jorgensen <no****@nospam.nospam>
wrote:

....
Some of the open source repositories that focus on Linux claim to
offer ERP but I am reluctant to switch OS's this late in life. Too
much invested in Windows apps both from a $oftware and a learning
curve standpoint.


I know. I think the GNUe effor runs on Mono, and should be able to run on
.NET, but I don't know if that ever went anywhere. I always thought it had
too ambitious of an initial goal, and was an overengineered design, but I
could be wrong.


I just checked again, and I was wrong about one thing - GNUe runs on Python,
not Mono, and it uses wxPython as the native GUI. The good news is, that
works just great on Windows or Linux, or any number of other wierd things.
I'm working for a client right now that is using Python for some of its C/S
applications, and having pretty good results.

The bad news is, it looks like GNUe has gotten just about as fas as I thought
it had - not very far yet. Perhaps, eventually, this will be a useful tool,
but not today.
Nov 13 '05 #15

P: n/a
>So, are you saying you'd want to do work for such a consortium, and try to
sell clients on paying us to do work on such a project? Perhaps, we should
start a project site on Sourceforge, or something.


If any of you all (good "Southern" expression) are willing to take on
this project via Sourceforge I will contribute the VBA-Access '97
source and docs from our package for what that's worth.

Nov 13 '05 #16

P: n/a
Matt,

What is the name of your company and where are you located?

Harold
"Matt Alanzo" <ac**********@emailias.com> wrote in message
news:ld********************************@4ax.com...
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.

Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.

I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!

Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]

[P.S. Will "heads up" regarding whether VBA for Access will ever
migrate to VTSO versionX ?]

Nov 13 '05 #17

P: n/a
Earthlink bounced your e-mail address. Please e-mail your phone number
and I'll be glad to discuss: ac**********@emailias.com

On Mon, 26 Jul 2004 16:48:31 GMT, "Harold" <hr******@earthlink.net>
wrote:
Matt,

What is the name of your company and where are you located?

Harold


Nov 13 '05 #18

P: n/a

"XMVP" <ac***********@hotmail.com> wrote in message
news:-J********************@vnet-inc.com...

"Matt Alanzo" <ac**********@emailias.com> wrote in message
news:ld********************************@4ax.com...
Our SOHO 2 person compay sells furniture (not programmers). In '98 we
paid $,$$$ for a VBA -Access '97 accounting application, including VBA
source code .... an huge investment for us then (and now!). The
application publisher went belly up years ago. Over time we've made a
number of VBA code changes (< 500 lines total). Now our CPA is urging
us to switch to Quickbooks Premier for Contractors at a cost of $,$$$
plus data entry. Argh, no more access to .mdb and Access' report
writer. [QB is a flat file proprietary "closed database".] Alternately
we can pay 3,$$$ to safechoice.com but we're back to VBA '97 code
(though with a much more substantial publisher.) Questionable value.

Another option? We might solicit some offshore outfit to "upgrade"
the backend references to SQL Server 2005 Express Edition [free] and
then modify the progamming to Office 2003's VBA. My fear is that
Microsoft will discontinue VBA after Office 2003 and then we will have
just paid $,$$$ to upgrade to an ["non-managed" code] "end of life"
technology. This is a daunting option for two guys who prefer to sell
furniture than to hassle with software and contract programmers.

I have search diligently for an SQL based accounting package with a
decent job cost module but they are all mid-market solutions with
runtimes costing 2x-5x more than we can afford BEFORE installation
costs. No hope for any source code and customization except at
$100+/hour. Mercy!

Can anyone provide any strategic insight. [obviously any decisions are
ours alone; no risk on your part :>) ]

[P.S. Will "heads up" regarding whether VBA for Access will ever
migrate to VTSO versionX ?]

It sounds like you need a bank loan more than anything.


That's probably true! The guy's just cheap. I've seen a thousand of 'em.
Always trying to get some database work for nothing. That's why he's here.

Its like the old saying "if you gotta ask how much then you can't afford
it!"


Nov 13 '05 #19

P: n/a
"Kim Walker" <kj***@gaslight.net> wrote
in response to XMVP's inane trolling
That's probably true!


Kim W. may be another sockpuppet like XMVP (posted from a newsserver used by
other sockpuppets in the same family) or just a tagalong troll. In any case,
Kim's comments arent't to be taken seriously... they are just more trolling.
Nov 13 '05 #20

P: n/a

"Larry Linson" <bo*****@localhost.not> wrote in message
news:By******************@nwrddc01.gnilink.net...
"Kim Walker" <kj***@gaslight.net> wrote
in response to XMVP's inane trolling
> That's probably true!
Kim W. may be another sockpuppet like XMVP (posted from a newsserver used

by other sockpuppets in the same family) or just a tagalong troll. In any case, Kim's comments arent't to be taken seriously... they are just more trolling.


Oh okay Larry if you say so! Be sure to let us know when to take YOU
seriously!

(BTW do you have any purpose around here at all?)
Nov 13 '05 #21

P: n/a
Steve Jorgensen <no****@nospam.nospam> wrote in message news:<fe********************************@4ax.com>. ..
So, are you saying you'd want to do work for such a consortium, and try to
sell clients on paying us to do work on such a project? Perhaps, we should
start a project site on Sourceforge, or something.

Actually, I have one client right now who could really benefir from something
like that, and stubbornly refuses to consider it. For some reason, he wants
everything about his software to be as closed as possible. he doesn;t even
want me to take copies of the code I work on for him off site. He never
explained his motivation, and it's not at all clear to me.


I guess what I'm saying is that when most of my code is done I would
strongly consider a Sourceforge style mechanism as a way of aiding
developers who want to start with something that's already good and
OpenSource. I'd rather not start yet another accounting software
company. I'm still in the process of developing ideas about how to go
about it. As far as your stubborn client, maybe he feels that if he
has to dish out a lot for custom software then it's only fair that his
competitors have to dish out an equal amount. That's not how it works
in the software business. After you've done your first E-Commerce
site, you and your competitors are all going to charge less for the
next one.

James A. Fortune
Nov 13 '05 #22

P: n/a
On 27 Jul 2004 00:25:43 -0700, ja******@oakland.edu (James Fortune) wrote:
Steve Jorgensen <no****@nospam.nospam> wrote in message news:<fe********************************@4ax.com>. ..
So, are you saying you'd want to do work for such a consortium, and try to
sell clients on paying us to do work on such a project? Perhaps, we should
start a project site on Sourceforge, or something.

Actually, I have one client right now who could really benefir from something
like that, and stubbornly refuses to consider it. For some reason, he wants
everything about his software to be as closed as possible. he doesn;t even
want me to take copies of the code I work on for him off site. He never
explained his motivation, and it's not at all clear to me.


I guess what I'm saying is that when most of my code is done I would
strongly consider a Sourceforge style mechanism as a way of aiding
developers who want to start with something that's already good and
OpenSource. I'd rather not start yet another accounting software
company. I'm still in the process of developing ideas about how to go
about it. As far as your stubborn client, maybe he feels that if he
has to dish out a lot for custom software then it's only fair that his
competitors have to dish out an equal amount. That's not how it works
in the software business. After you've done your first E-Commerce
site, you and your competitors are all going to charge less for the
next one.


Well, so far, there's nothing good and open source in this area, though
perhaps, there's ennough in Matt's software to be a 1/2 way decent starting
point. Also, I wasn't suggesting that anyone start a separate company, the
companies that want the software would contribute development time to the
software. As for benefitting the competitors, this is a case much like the
Apache situation. Lot's of people need a mid-range ERP/MRP program, but few
of them are direct competitors. Just like with Apache, where all the
companies needed a decent Web server, but few had any direct competition with
each other in their primary markets.

Heck, I know this is just pie in the sky idealism, but it's fun.
Nov 13 '05 #23

P: n/a
Should we create an ADP with a SQL backend?
If so which of the three options make the most sense? (see article
Using Access to build a front end for SQL Server
http://techrepublic.com.com/5102-6329-5065669.html ).

All the while our goal is to
1) keep the conversion costs to $,$$$ in lieu of $$,$$$,
2) not unduely handicapping the program and
3) maintain super-users' ability to make modest program changes
(example: changed forms, reports, ad hoc quiries) without becoming
database experts.

My first blush preference is option #3: Upsize data to SQL Server by
creating an entirely new database on SQL Server without making changes
to the actual MDB file. As a super-user (but by no means a
programmer) I have deeply valued the ability to make local "last
minute" changes to our existing VBA forms, reports and queries.
Evenso, I also like the expected benefits of keeping our data on SQL
Server 2005 Express Edition. Then down the road maybe our CPA can
remotely access our accounting data without corruption issues. More
importantly, with SQL, web services (and an XML interface?) maybe we
can begin the process of tying with our our numerous vendor OEMs and
our web site customers (each project typically last several months).
[Just because we are SOHO doesn't mean our vision and our desires are
mundane.]

So back to the original question, should we create an ADP with a SQL
backend and if so which of the three options make the most sense?
Your (constructive) comments are greatfully appreciated!.

For reference see:
SQL: Access to SQL Server
http://www.apress.com/book/bookDisplay.html?bID=70
http://www.amazon.com/exec/obidos/AS...005717-2516050

Nov 13 '05 #24

P: n/a
I have used both MDBs and ADPs for client-server applications, and IMO,
Microsoft has as of yet failed to make ADPs a viable technology. It is
particularly not a good idea to try to convert a significant existing
application from an MDB to an ADP. For one thing, almost everything is going
to need to be changed to one extent or another. For another thing, IMO,
that's putting in a lot of effort for a net loss of reliability and
performance.

On Tue, 27 Jul 2004 06:41:57 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:
Should we create an ADP with a SQL backend?
If so which of the three options make the most sense? (see article
Using Access to build a front end for SQL Server
http://techrepublic.com.com/5102-6329-5065669.html ).

All the while our goal is to
1) keep the conversion costs to $,$$$ in lieu of $$,$$$,
2) not unduely handicapping the program and
3) maintain super-users' ability to make modest program changes
(example: changed forms, reports, ad hoc quiries) without becoming
database experts.

My first blush preference is option #3: Upsize data to SQL Server by
creating an entirely new database on SQL Server without making changes
to the actual MDB file. As a super-user (but by no means a
programmer) I have deeply valued the ability to make local "last
minute" changes to our existing VBA forms, reports and queries.
Evenso, I also like the expected benefits of keeping our data on SQL
Server 2005 Express Edition. Then down the road maybe our CPA can
remotely access our accounting data without corruption issues. More
importantly, with SQL, web services (and an XML interface?) maybe we
can begin the process of tying with our our numerous vendor OEMs and
our web site customers (each project typically last several months).
[Just because we are SOHO doesn't mean our vision and our desires are
mundane.]

So back to the original question, should we create an ADP with a SQL
backend and if so which of the three options make the most sense?
Your (constructive) comments are greatfully appreciated!.

For reference see:
SQL: Access to SQL Server
http://www.apress.com/book/bookDisplay.html?bID=70
http://www.amazon.com/exec/obidos/AS...005717-2516050


Nov 13 '05 #25

P: n/a
Steve,

What would you recommend? [I've come to your same conclusion about
ADP being a non-starter technology.]

Assuming we stear clear of ADP can we still use MDB (Access 2002/2003)
to contain the VBA code, queries, forms and reports but "upsize" the
accounting tables to SQL? I deeply valued the ability to make ad hoc
changes to table definitions, queries and reports in Access. Is there
a "middle ground"?

Also, what bearing, if any, does the above choice have on staying with
DAO or recoding to ADO? [In my case I fear "A little knowledge is a
dangerous thing." :>) ] Your thoughts.

Steve, I really appreciate your insights. Any hope we could
communicate one one one via e-mail. If so, please send a hi message
to: vb**************@emailias.com . :>)

Matt

On Tue, 27 Jul 2004 15:21:09 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
I have used both MDBs and ADPs for client-server applications, and IMO,
Microsoft has as of yet failed to make ADPs a viable technology. It is
particularly not a good idea to try to convert a significant existing
application from an MDB to an ADP. For one thing, almost everything is going
to need to be changed to one extent or another. For another thing, IMO,
that's putting in a lot of effort for a net loss of reliability and
performance.

On Tue, 27 Jul 2004 06:41:57 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:


Nov 13 '05 #26

P: n/a
Rats! A while back Microsoft announced a conversion tool would come
with SP1 to Office 2003

http://accessadvisor.net/Articles.ns...256EA200489CE6

but SP1 to Office 2003 was announced today

http://www.microsoft.com/downloads/d...displaylang=en

and there is no mention of the conversion tool. ARGH!

Matt

Nov 13 '05 #27

P: n/a
On Tue, 27 Jul 2004 11:39:12 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:
Steve,

What would you recommend? [I've come to your same conclusion about
ADP being a non-starter technology.]

Assuming we stear clear of ADP can we still use MDB (Access 2002/2003)
to contain the VBA code, queries, forms and reports but "upsize" the
accounting tables to SQL? I deeply valued the ability to make ad hoc
changes to table definitions, queries and reports in Access. Is there
a "middle ground"?
Absoultely, you can up-size the tables, and there's absolutely a middle ground
if you want to go there, however, it's usually better to convert all or almost
all tables to SQL Server if you're going to bother upsizing at all.

Your biggest issue is going to be any forms or code that open unrestricted
recordsets on large tables. That's a practice that works find with an MDB
back-end and will cause you problems with client-server. Note that this
includes linked subforms since they actually are queries of the entire
back-end table, filtered to show just the rows related to the parent.

Any UI elements that use unfltered, unaggregated lists will need to be updated
to use some kind of drill-down, selectable filter, etc. Subform master,
detail links need to be replaced with parameter queries in the subforms that
use master form controls as filters. Use the OnCurrent handler on the master
forms to requery the subforms.

Regarding the upsizing of queries, IMO, don't upsize them for the most part.
Access does a pretty good job of converting queries to server-side syntax and
executing them on the server-side for you, even queries with joins. For the
query here or there that's not optimal, try first upsizing the join logic and
parameter-free computations to a view, then if you're still not having any
luck, upsize the query to a stored procedure, but this will often require some
tricky work on the front-end.
Also, what bearing, if any, does the above choice have on staying with
DAO or recoding to ADO? [In my case I fear "A little knowledge is a
dangerous thing." :>) ] Your thoughts.
Well, you're pretty much going to be interacting with JET, and DAO is still
the more mature API for JET, but ADO and DAO both work pretty well, and you
can even mix and match if you don't mind the cognitive dissonance. Just
remember that the recordsets Access creates (e.g. <form>.RecordsetClone are
DAO, so the code must be aware, and treat them as such. ADO vs DAO is pretty
much irrelevant in an MDB.
Steve, I really appreciate your insights. Any hope we could
communicate one one one via e-mail. If so, please send a hi message
to: vb**************@emailias.com . :>)

Matt

On Tue, 27 Jul 2004 15:21:09 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
I have used both MDBs and ADPs for client-server applications, and IMO,
Microsoft has as of yet failed to make ADPs a viable technology. It is
particularly not a good idea to try to convert a significant existing
application from an MDB to an ADP. For one thing, almost everything is going
to need to be changed to one extent or another. For another thing, IMO,
that's putting in a lot of effort for a net loss of reliability and
performance.

On Tue, 27 Jul 2004 06:41:57 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:


Nov 13 '05 #28

P: n/a
Going from 97, to 2000 and up, the conversion issues are just not that big a
deal, for the most part. There are a few database settings to change to
maintain good performance, but 98% of everything converts with no problem, and
most of the rest can be fixed by trying to compile the code, and fixing the
things that don't compile.

On Tue, 27 Jul 2004 11:51:06 -0500, Matt Alanzo <ac**********@emailias.com>
wrote:
Rats! A while back Microsoft announced a conversion tool would come
with SP1 to Office 2003

http://accessadvisor.net/Articles.ns...256EA200489CE6

but SP1 to Office 2003 was announced today

http://www.microsoft.com/downloads/d...displaylang=en

and there is no mention of the conversion tool. ARGH!

Matt


Nov 13 '05 #29

P: n/a
Matt Alanzo <ac**********@emailias.com> wrote in message news:<sh********************************@4ax.com>. ..
On Mon, 26 Jul 2004 02:51:53 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote: Ken Getz's article gave me great assurance on this point. (Just
tripped across it.)
http://www.advisor.com/doc/13516


This is a very interesting article. After looking at the Advisor
Events, three things stuck out. The graphic functions in ASP.NET
called GDI+ seem to be a logical extension of creating a Device
Context using API functions and using the built-in graphics objects
for rendering. I'm very impressed that .NET has built-in classes for
data structures such as queues, linked lists, etc. I've always wanted
to play around with N-Tier but haven't had the right situation come up
for implementing it. I'm looking forward to seeing if the combination
Getz talks about in that article of OS, FS and .NET will produce a new
paradigm for Access style development. .NET is definitely something I
want to consider as a possible tool and know how to use. I wonder if
the .NET stuff that got added by the 26 meg or so MS OS update will
allow some of that functionality without forcing everyone to get the
hottest release of windows.

James A. Fortune
Nov 13 '05 #30

P: n/a
Steve Jorgensen <no****@nospam.nospam> wrote in message news:<l6********************************@4ax.com>. ..
Well, so far, there's nothing good and open source in this area, though
perhaps, there's ennough in Matt's software to be a 1/2 way decent starting
point. Also, I wasn't suggesting that anyone start a separate company, the
companies that want the software would contribute development time to the
software. As for benefitting the competitors, this is a case much like the
Apache situation. Lot's of people need a mid-range ERP/MRP program, but few
of them are direct competitors. Just like with Apache, where all the
companies needed a decent Web server, but few had any direct competition with
each other in their primary markets.
It's not hard for me to go beyond accounting. For instance, I have an
Access application that allows users to create purchase reqs and IDO's
and post the basic and details information. The IDO's do double duty
as interdepartmental labor charges and as labor for outsourced jobs. A
purchase req admin and an IDO admin have the power to select user
submissions for automatic creation of material entries and time
tickets. The material costs and IDO costs come directly off the
project budget just like normal labor from time tickets. The budget
and costs are broken down for each department in the company. The
current profit for each job is recalculated from the time ticket and
material entries whenever that job is selected on the job form or when
someone chooses to update all the active jobs. The admins have a form
that allows them to reconcile the amounts when the final paperwork
shows up. The fact that the program outputs the purchase reqs and
IDO's as PDF files doesn't hurt either. It turns out that most of the
work I do involves quotes and job costing. Bringing up an old job and
seeing the final profit numbers and how each department affected the
bottom line really helps to refine new quotes. That company grosses
over $20 million per year. Their sister company had a programmer try
to keep up with what I was doing in Access with an accounting program
module. No contest.
Heck, I know this is just pie in the sky idealism, but it's fun.


I solve most of my programming problems before a single line is coded.
It's cheaper that way :-). I think now is the best time to toss these
ideas about. The more information I have up front about possible end
uses the less unplanned bandaids have to be tacked on. I think there
is a great win-win situation here somewhere.

James A. Fortune
Nov 13 '05 #31

P: n/a
James Fortune wrote:
Matt Alanzo <ac**********@emailias.com> wrote in message news:<sh********************************@4ax.com>. ..
On Mon, 26 Jul 2004 02:51:53 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:


Ken Getz's article gave me great assurance on this point. (Just
tripped across it.)
http://www.advisor.com/doc/13516

This is a very interesting article. After looking at the Advisor
Events, three things stuck out. The graphic functions in ASP.NET
called GDI+ seem to be a logical extension of creating a Device
Context using API functions and using the built-in graphics objects
for rendering. I'm very impressed that .NET has built-in classes for
data structures such as queues, linked lists, etc. I've always wanted
to play around with N-Tier but haven't had the right situation come up
for implementing it. I'm looking forward to seeing if the combination
Getz talks about in that article of OS, FS and .NET will produce a new
paradigm for Access style development. .NET is definitely something I
want to consider as a possible tool and know how to use. I wonder if
the .NET stuff that got added by the 26 meg or so MS OS update will
allow some of that functionality without forcing everyone to get the
hottest release of windows.

James A. Fortune

James,

In answer to your question about the .NET framework, yes. You don't need
Win XP or 2003 to use .NET programs. There are more stringent
requirements for the developer machine, I believe.

If you're interested, MS is offering free downloads for some new tools. See:

http://lab.msdn.microsoft.com/vs2005/

for info. In particular, you can get Visual Studio Express (will replace
Web matrix) and SQL Server 2005 Express (will eplaces MSDE) for free.
I've played with both, and it seems clear that MS is trying to push more
RAD features into .NET development. At least, they want to make more
available.

--

Peter
Nov 13 '05 #32

P: n/a
On 27 Jul 2004 15:04:57 -0700, ja******@oakland.edu (James Fortune) wrote:
Steve Jorgensen <no****@nospam.nospam> wrote in message news:<l6********************************@4ax.com>. ..
Well, so far, there's nothing good and open source in this area, though
perhaps, there's ennough in Matt's software to be a 1/2 way decent starting
point. Also, I wasn't suggesting that anyone start a separate company, the
companies that want the software would contribute development time to the
software. As for benefitting the competitors, this is a case much like the
Apache situation. Lot's of people need a mid-range ERP/MRP program, but few
of them are direct competitors. Just like with Apache, where all the
companies needed a decent Web server, but few had any direct competition with
each other in their primary markets.
It's not hard for me to go beyond accounting. For instance, I have an
Access application that allows users to create purchase reqs and IDO's
and post the basic and details information. The IDO's do double duty
as interdepartmental labor charges and as labor for outsourced jobs. A
purchase req admin and an IDO admin have the power to select user
submissions for automatic creation of material entries and time
tickets. The material costs and IDO costs come directly off the
project budget just like normal labor from time tickets. The budget
and costs are broken down for each department in the company. The
current profit for each job is recalculated from the time ticket and
material entries whenever that job is selected on the job form or when
someone chooses to update all the active jobs. The admins have a form
that allows them to reconcile the amounts when the final paperwork
shows up. The fact that the program outputs the purchase reqs and
IDO's as PDF files doesn't hurt either. It turns out that most of the
work I do involves quotes and job costing. Bringing up an old job and
seeing the final profit numbers and how each department affected the
bottom line really helps to refine new quotes. That company grosses
over $20 million per year. Their sister company had a programmer try
to keep up with what I was doing in Access with an accounting program
module. No contest.


It sounds like you've successfully come up with a very simple design that's
also very powerful and flexible. I salute you.
Heck, I know this is just pie in the sky idealism, but it's fun.


I solve most of my programming problems before a single line is coded.
It's cheaper that way :-). I think now is the best time to toss these
ideas about. The more information I have up front about possible end
uses the less unplanned bandaids have to be tacked on. I think there
is a great win-win situation here somewhere.


On the other hand, half the requirments are never actually known even by the
customer until after they see how your initial effort doesn't meet them.
Therefore, it's nice to get that initial effort out ASAP, knowing that the
desing is definitely not complete. It's easier to make changes to the design
at that stage than after a lot of code is invested in a "completed" design.

James A. Fortune


Nov 13 '05 #33

P: n/a
Steve Jorgensen <no****@nospam.nospam> wrote in message news:<ib********************************@4ax.com>. ..
On 27 Jul 2004 15:04:57 -0700, ja******@oakland.edu (James Fortune) wrote: I solve most of my programming problems before a single line is coded.It's cheaper that way :-). I think now is the best time to toss theseideas about. The more information I have up front about possible enduses the less unplanned bandaids have to be tacked on. I think thereis a great win-win situation here somewhere.


On the other hand, half the requirments are never actually known even by the
customer until after they see how your initial effort doesn't meet them.
Therefore, it's nice to get that initial effort out ASAP, knowing that the
desing is definitely not complete. It's easier to make changes to the design
at that stage than after a lot of code is invested in a "completed" design.


I totally agree. You need to get as much information as possible up
front. Then you need to get feedback often. Even after all that,
they won't realize what they really want until after you give them
what they said they wanted.

James A. Fortune
Nov 13 '05 #34

P: n/a
"Kim Walker" <kj***@gaslight.net> wrote
(BTW do you have any purpose around here at all?)


Yes, unlike the resident troll and his muliplicity of sockpuppets, I
actually answer questions that people post here.
Nov 13 '05 #35

P: n/a
ja******@oakland.edu (James Fortune) wrote:
On the other hand, half the requirments are never actually known even by the
customer until after they see how your initial effort doesn't meet them.
Therefore, it's nice to get that initial effort out ASAP, knowing that the
desing is definitely not complete. It's easier to make changes to the design
at that stage than after a lot of code is invested in a "completed" design.


I totally agree. You need to get as much information as possible up
front. Then you need to get feedback often. Even after all that,
they won't realize what they really want until after you give them
what they said they wanted.


Agreed. I always aim for being 80% right the first time. I don't bother spending
hours and hours discussing things, drawing diagrams, etc. Just get something in
front of them as a starting point and our discussion continues from there.

Ultra Frequent Application Deployment
http://www.granite.ab.ca/access/ufad.htm

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
Nov 13 '05 #36

P: n/a
Peter <no**@invalid.us> wrote:

If you're interested, MS is offering free downloads for some new tools. See:

http://lab.msdn.microsoft.com/vs2005/

for info. In particular, you can get Visual Studio Express (will replace
Web matrix) and SQL Server 2005 Express (will eplaces MSDE) for free.
I've played with both, and it seems clear that MS is trying to push more
RAD features into .NET development. At least, they want to make more
available.


Note that VS Express is free only while in Beta. From their FAQ page "Are the
Express Edition products free? We have not announced pricing and licensing and will
not do so until next calendar year. For the time being, we can tell you that the
Express Editions will be low-cost and will continue to be easy to acquire."

SQL Server Express will be free.

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
Nov 13 '05 #37

P: n/a
Tony Toews <tt****@telusplanet.net> wrote in message news:<tm********************************@4ax.com>. ..
Agreed. I always aim for being 80% right the first time. I don't bother spending
hours and hours discussing things, drawing diagrams, etc. Just get something in
front of them as a starting point and our discussion continues from there.

Ultra Frequent Application Deployment
http://www.granite.ab.ca/access/ufad.htm

Tony


Good points in your Ultra Frequent link. Most of my clients have seen
Access for awhile so I expect a little more clarity out of them than
from "green" clients. Even so, they still want me to ask general
operational questions and dream up a best first approximation myself.
You can get frequent feedback from a project coordinator and then get
hit with major surprises when the coordinator finds out that she
didn't understand the requirements fully. For example, after you've
already designed the database and it's been in use for months the
accountants discover that audits are going to be a pain. Of course
you can fix the problem, but wouldn't it have been better to include
those considerations in the original design? I am discovering that I
have to be more proactive about getting more information up front. Of
course, with less time up front you'll have to save them and be their
hero :-). I agree that you shouldn't waste time up front talking
about things that will probably change or things that won't be
understood until they see it on the screen.

James A. Fortune
Nov 13 '05 #38

P: n/a
ja******@oakland.edu (James Fortune) wrote:
Good points in your Ultra Frequent link.
Thanks.
Most of my clients have seen
Access for awhile so I expect a little more clarity out of them than
from "green" clients. Even so, they still want me to ask general
operational questions and dream up a best first approximation myself.
You can get frequent feedback from a project coordinator and then get
hit with major surprises when the coordinator finds out that she
didn't understand the requirements fully.
I also deal extensively with the end users. I do deal with a client coordinator
frequently but as often as not I'll snag them, or ignore them <smile>, and ask the
folks directly. Or they'll come directly to me.
For example, after you've
already designed the database and it's been in use for months the
accountants discover that audits are going to be a pain. Of course
you can fix the problem, but wouldn't it have been better to include
those considerations in the original design? I am discovering that I
have to be more proactive about getting more information up front. Of
course, with less time up front you'll have to save them and be their
hero :-). I agree that you shouldn't waste time up front talking
about things that will probably change or things that won't be
understood until they see it on the screen.


Agreed on your points. But one of the differences is that I do have twenty odd years
experience building systems. So I'm always asking these kinds of questions based on
other apps I've seen in the past. I seldom have to go back and re-arrange data in
tables. Although I will have to go back and add functionality.

It was quite humourous one time when I had a question about a material item and I
said we should go look at the physical item in question so I could understand it
better. We all put on hard hats and safety glasses and head out there. And while
I'm in the warehouse I glance around and see something that has three sizes. One
size and two which are a range of sizes. I ask what the heck is that marked on the
boxes? They explain and I explain 1) they just added a week to the estimate and 2)
how come they didn't tell me. <smile>

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
Nov 13 '05 #39

P: n/a

"Larry Linson" <bo*****@localhost.not> wrote in message
news:_b*******************@nwrddc01.gnilink.net...
"Kim Walker" <kj***@gaslight.net> wrote
> (BTW do you have any purpose around here at all?)


Yes, unlike the resident troll and his muliplicity of sockpuppets, I
actually answer questions that people post here.


Too bad they're mostly wrong answers.
Nov 13 '05 #40

P: n/a

"XMVP" <ac***********@hotmail.com> wrote
Too bad they're mostly wrong answers.


<SARCASM>
Thanks, I really needed someone who calls him/her/itself "access_morons" to
evaluate my answers.
</SARCASM>

As you don't answer Access questions, but just try to disrupt, disturb, and
insult, we can't evaluate your answers, now can we?
Nov 13 '05 #41

P: n/a
Tony Toews <tt****@telusplanet.net> wrote in message news:<ab********************************@4ax.com>. ..
Peter <no**@invalid.us> wrote:

If you're interested, MS is offering free downloads for some new tools. See:

http://lab.msdn.microsoft.com/vs2005/

for info. In particular, you can get Visual Studio Express (will replace
Web matrix) and SQL Server 2005 Express (will eplaces MSDE) for free.
I've played with both, and it seems clear that MS is trying to push more
RAD features into .NET development. At least, they want to make more
available.


Note that VS Express is free only while in Beta. From their FAQ page "Are the
Express Edition products free? We have not announced pricing and licensing and will
not do so until next calendar year. For the time being, we can tell you that the
Express Editions will be low-cost and will continue to be easy to acquire."

SQL Server Express will be free.

Tony


Thanks guys for the information. I have another question. Has anyone
tried the Linux Mono 1.0 package? I wouldn't have named the software
after a disease caught by excessive workaholics :-). Plus, the 1.0
version number scares me. It supposedly allows Visual Basic, C# and
Java programming, et al, with cross platform support under some sort
of .NET framework. I would be very interested in hearing how this
approach lives up to or falls short of Getz' vision.

James A. Fortune
Nov 13 '05 #42

This discussion thread is closed

Replies have been disabled for this discussion.