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 ?]
41  3035 
-----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 ?]
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.
"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.
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.
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
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"?
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.
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 ?]
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.
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.
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.
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
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.
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.
>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.
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 ?]
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
"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!"
"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.
"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?)
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
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.
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
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
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:
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:
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
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
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
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
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
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
"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. 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
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
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 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
"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.
"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?
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Paddy McCarthy |
last post by:
Frustrated at being prevented from using Python at work I went
gunning for Perl.
Time to roll out some useless Google statistics to make me feel
better
Google Phrase count...
|
by: Patrick Finnegan |
last post by:
Running UDB V7 FP10a and 8.1 .4 on Windows 2000.
Did full offline backups of three V7 databases. Restored two databases
to V8 instance successfully.
Third restore ended with:
SQL2517W The...
|
by: Jep |
last post by:
Any help or advice appreciated.
We have just installed and configured a new DB2 v.8.1 with latest
FixPack. Just a few days later it dies and now we have a DB that is
totally unusable.
- - - -...
|
by: Bonggoy Cruz |
last post by:
We have a fairly big size ASP.NET web application that was written VB.NET.
We are in the process converting the web project.
We used the migration wizard included in VS 2005. I followed step by...
|
by: Shawnk |
last post by:
Some Sr. colleges and I have had an on going discussion relative to when and
if
C# will ever support 'true' multiple inheritance.
Relevant to this, I wanted to query the C# community (the...
|
by: pamelafluente |
last post by:
Hi ,
I have a DIV element in a page with a lot of other stuff (the page can
scroll several times) absolutely positioned:
<div id="MyDIV" <br<brFooter </div>
Just after the page load, I...
|
by: tomek milewski |
last post by:
Hello,
I have a map with keys that can be compared each other. I need a
method that returns the lowest and the greatest key from that map.
Now I'm using begin() and rbegin() which gives...
|
by: Troels Arvin |
last post by:
At work, some people have found IBM's Migration Toolkit (MTK) to be a
nice tool for copying data from one table (in another DBMS product) to
DB2.
Now, they want to do the same thing from one DB2...
|
by: 1 |
last post by:
Dear friend, we sell all kinds of laptops and guitars . our product
is a quantity best, the price is the lowest in the world, i think you
will be interested in our product . thanks a lot! Our...
|
by: davenet |
last post by:
Hi,
I'm new to Python and working on a school assignment.
I have setup a dictionary where the keys point to an object. Each
object has two member variables. I need to find the smallest value...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
