"cc" <cristianclavero (AT) topmail (DOT) com.ar> wrote

Been a while since I visited here, and even longer since I posted here.

I am a person who developer a good number of applications for clients under
pick for "small seat" users.

Those clients of mine have been since moved to ms-access.

I do take some exception to the issues of support costs, and even those of
reliability for these small seat systems. There is/was a number of posts
here stated that

oh..gee, I know a client with a access based solution, and they are
constantly bringing in someone to add features etc.

Well, if they are bringing in someone to constantly change things, then
likely the business is changing, or the developers don't know what they are
doing.

I would not blame ms-access, and for these smaller systems, it is ideal.

First, lets clear up some things.

ms-access is a developers tool, and you want to distinguish this tool from
that of the database engine you use with ms-access. I think it is important
to note that ms-access is really a IDE that is based on VB. (in fact, it
shares the same compiler as VB6, and the syntax is the same as VB6 (except
for the forms object model). Ms-access is really just another tool to
create software like VB6, or whatever your choice is.

I should also note, that the next version of ms-access (office 12) coming
out has multi-valued support in it (note that I am under NDA with Microsoft
as I write this, but this information has been made public elsewhere). I
going to leave this issue for now, but suffice to say that when this feature
was announced at the MVP summit to us ms-access developers, there was so
much heat generated in the room, that some of the developers latter made
apologies to the Microsoft office team. (poor codd turning in his grave).

Anyway, the "many to many" join ability of the new jet engine was mostly
added
for SharePoint integration, but this multi-value means that users will be
able to add multiple values, and not have to do the grunt work of building a
another table and building the relationships in the relationship window.

Further, I should point out that if a small business outgrows a JET based
solution in ms-access, you can then migrate the back end data to sql server
but CONTINUE to use ms-access as the front end part. You can use
ms-access as a client to sql server, or Oracle for that matter. And, for
my market segment, I got the free desktop edition of sql server
(MSDE), or now, the incredible free sql server express which is going
to be perfect for those 5-30 seat systems (and, again, no licensing here,
no annual support fees!!). I will continue to use ms-access as the front
end part.

So, ms-access is NOT the JET database engine, and we need to distinguish
this
issue. I should note that the office team now owns the JET code, and the new
version of this engine is called ACE (ACesss data Engine).

As for a "jet" applications, or so called ms-access based application not
being
appropriate, nor reliable enough for small business, you should consider the
following commercial applies that are based on the access "mdb" + jet file
format:

Ms-access
Windows NT (directory services)
Microsoft Money
Internet Information Server
Index Server
Microsoft Project.
A Jet variation even serves as the message store for
Exchange Server.

Simply Accounting
CityDesk (web content manager).:

Note that we see two accounting packages in the above list!!, and I know
MANY
small business that use simply accounting. Do you folks know that simply
accounting is access based??? I never heard anyone tell me that Simply
Accounting is less reliable then say QuickBooks, or any other of the small
business accounting applications....have you?

however, the fact that Simply Accounting is access based means that I can
open those files, and query them with ms-access. From a developers point of
view, I think you can see how nice this is. This ability to open and use
those accounting tables reminds me of the good old days in pick when you
could using something like the Datamax "xyz" accounting package, but simply
write you OWN code to read, and use that accounting data. Very nice.....

So, there is some quite widely used, and widely distributed commercial
applications based on JET, and the ms-access mdb file format. I not going to
get into a argument with the other posts that dished ms-access as a solution
to small business. I will say that "JET" based solutions on the ms-access
mdb
file format is by FAR AND AWAY the most popular data engine out there right
now.

For some reason, IT people, and c++ developers, and most tend to really look
down upon ms-access, but in 99% of the cases, it is developers to blame
here..not the tool that so many developers love to hate.

Now, as for a solution?

Fast back to 1990.

A customer needs a multi user system, and some type of multi-user database.
Windows for workgroups is just getting ready for market. The only real
serous game in town to network 2-6 computers is to use Novell. Once you got
the computers networked, then you still faced with trying to get some type
of database engine. So, for each Novell seat, you pay a big bunch of money.
And, if you also purchase some database system (where of choices where next
to none), you again have VERY steep licensing costs.

To rescue was the PICK system. Wow, I could deliver to client a 386 box with
a 40 meg hard disk, 4 megs ram. I would then purchase 5 286 pc's that boot
ms-dos (in fact, I used dr-dos back then) with a floppy using ProCommm on a
dos disk. A few serial cables, and my handy dandy crimp tool (I used rs232
ends that accepted rj45 phone cord). Presto...I just built a multi user
system
for about 1 5th the cost of the competition to deliver a multi user system.

So, no hard disks on each station...I
got a POWERFUL multi-user system. I got 6 licensed users for multi user, and
6 licensed users for database with the pick system (really, that is two for
one!!)
Talk about pounding out the
competition. What a FABULOUS system. And, those 386 pc's were as fast, and
in
fact faster then most of the "mini" computer versions of pick I had used.
Those "3" user copy of pick made a LOT of sense back then....

I had 6 user version of my "Rides" reservation system running from 1991 to
2001. A lot changed in those 10 years.

Now, the network for those 6 computers is free, and is included with
windows.
That took away a large advantage of pick as a choice for small systems here.

Further, file based database systems such as FoxPro, and of course ms-access
came on the scenes, and again this meant no licensing costs. So, if I can
deliver a ms-access based solution to that client, I save 6 x $400, or
whatever the licensing cost is. I can pocket that money now.

Further, the real BIG issue is ease of install, and distribution. Last
year, in a period of one month, I deployed 5 copies of my Rides reservation
software to 5 *different* customers/people in a city I never met. Again, I
can't
just do that with my pick based solutions.

And, to support them, I use a web suite, and a "update" software button in
my application .. (when they hit that button, I can install and update
changes to their application. (in the following screen shot (last one) you
can
see that "update" button I have in my "about" screen in ms-access here)

http://www.kallal.ca/ridest2/index.htm
(sure, take a quick look at the above...scroll to the last screen).

For the majority of these small systems that I once wrote in pick, I now
write deploy them in ms-access, I have very good insight as to cost issues,
and even those of support issues.

Lets take that 10 year run with 6 users. That application is reasonably
complex. In fact, I write with some good points about this conversion from
pick to ms-access here:

http://www.members.shaw.ca/AlbertKal...000000003.html
(read the above one later when you got some time!!)

The resulting ms-access application has 160 forms, 27,000 lines of code, and
a
lot of reports and queries. In the 5 years that the client has run this
application (in place of pick), I have no service calls relate to down time
(note that I migrated most of the pick data to this application).

The database has only about 55 (highly) related tables, and
the data sets are quite small (tables of 50,000 to 100,000 records) are
nothing for ms-access. And, the system only has 3-6 users on it. Again,
never a problem (and, with such small data sizes, one would not expect
problems with ms-access anyway. My point here is that this type of
data base size is not large, but very typical of small business. I should
point out that this is a typical "sweet" spot in the market place that
I used pick for. And, pick was at one time by FAR the best solution
for me.

The main reasons for me converting these applications from pick to ms-access
was
that of ease of install, integration with word/excel, and ESPECIALLY email.
The
other issue was that of having GUI.

Further, I saw it as a chance to improve distribution (I can sell/offer the
application via the web. I use the developers edition of ms-access, and that
results in a standard windows install. The end users does NOT know this is
ms-access based solution, and the client/user does not have to purchase
or have ms-access.

The added bonus is of course that I can update the clients software via a
web site. I repackage the application part using the free open source Inno
installer, and that installs the software update for me. So, when a
customer in a different city asks for a new report, or change, I simply
build
it for them, and upload to my web server. I suppose the solution with pick
is
to telnet to the client site, but often these 1, or 2....or 3 user systems
don't have the experience to setup telnet. Further, I don't even have to
dedicate a server for my setup, as a simple peer to peer office network is
all that I need. The clients with more then 2 users tend to dedicate a
server for my software..but there is no installing of my software required
on
the sever side (just a shared folder).

The other thing of course is that my software all now has a very "NICE"
looking interface. Here is some screen shots

http://www.members.shaw.ca/AlbertKal...icles/Grid.htm

I can't say that I represent much of the pick marketplace,
but at one time, there was LOT of 1, or 2 or 3, or 6 users systems that pick
was the FIRST choice for me....but not no more....

I have to say for these "smaller" systems, my move to ms-access
was a very good one indeed, and allows me to "distribute" my
software with great ease....

However, I do find it quite amazing that the next version of ms-access will
have multi valued support (it does this will relation tables behind the
scenes....but users will not have to know, or learn this).

--
Albert D. Kallal (Microsoft Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
http://www.members.shaw.ca/AlbertKallal

I not had a chance to play with this product, but I sure wish it was out 5
or 6 years ago....
(if it was...I was not aware!!).


Most of us kind of thought that AREV was dead.....
(I did have a 1984 copy of ARV for the ibm pc, and while most magazines said
it was VERY complex, that was simply because users never had seen pick
before!!). It was a nice system back then!!

From what I heard, the new OpenInsight is very impressive

What is the pc UI like now? Does it build graphical forms? (any screen
shots?)

I am so busy right now...but I will try that eval when I got a chance....

--
Albert D. Kallal
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
http://www.members.shaw.ca/AlbertKallal

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote:
Glen wrote:
The same can be said for MV, and I've seen a lot of crappy MV
applications where the end-user relies on their VAR/developer for
everything. This is a matter of ethics and/or competence, and I don't
think the tools are at fault. Don't get me wrong, I don't like MS
Access, never have, but I think this emphasizes that good programming
is an art and skill, and not just any monkey can do it well, even
though a lot of monkeys can sell themselves as programmers for Pick,
MS Access, MySQL, Postgres, SQL Server, etc. There are a multitude of
excellent applications that use MS Access as their base, most of them
single-user, I don't think we can discredit the lot of them for the
bad apples that we've seen.

Do you believe there might be a market to do this using a tool like
mv.NET? I hope there is. Excel is a powerful tool, not just a
container for a grid as most people see it. It can import/export data
in a lot of ways and then do great things with the data it has. As
you know, I've done extensive coding into Excel and especially
integration with MV. The problem I see is not lack of power in Excel
or in MV, but that as soon as you tell a Pick developer that there are
elegant ways to integrate MV with Excel, you get the "I can do that
with AccuTerm" response. I'd maintain that such solutions are easy
for developers and inadequate for end-users who then need to take the
CSV files and perform the same reformatting operation on them every
week or month. Why don't end-users complain? They've already asked
for Excel integration and this is what they got - do they need to ask
again? Most end-users aren't technologists - they believe this is the
best that can be done because they don't know any better, so they
accept it and go on about their manual reformatting activities. This
is what perpetuates the false impression that Pick is primitive, and
it only serves to further the demise of the market as people go on to
find real solutions.

And you folks may recall that about a year ago I said Microsoft,
Oracle, and SAP are shifting focus from the Fortune 1000 companies and
down into the markets that we call home. I also said there were
solutions available to deal with the onslaught, but I wasn't going to
give those solutions away for free. Well, if competition wasn't bad
enough before it's going to get much worse now. There are still ways
to deal with it, but it's still going to cost ya.


I personally believe Microsoft has made a tremendous investment into
SQL Server 2005 in order to set the stage for a transition from MS
Access. Access is (arguably) a capable tool for small single-user
applications, but falls on its face in a multi-user environment. That
said, one of my clients is successfully running a busy website with
ASP.NET against an MS Access MDB file that's updated once per day from
D3. However, if you look at SQL Server 2005 and the developer tools
available it seems they are positioning it as a "real" database for
applications vs Access for hobbyists.

Years ago I started a project which I called MyDB which would allow
people to create databases on the web, make them available to the
public, get advertising for the type of data they hosted, make
database templates available to friends or sell them for business,
etc. None of our MV colleagues seemed to like the idea - but today
it's called Google Base and I'm sure it will be a hit. I still have
the code, might dig it up now that the idea is popular. Like Glen's
open source application project these sorts of things seem to get
dismissed by MV people but embraced by the rest of the world (Google
for "open source business applications" and there are many nice non-MV
offerings).

Dawn, the audience is completely different. While a lot of people use
MS Access as a standalone datastore, it's also a database which can
sit behind an application. Google Base is positioned as a stand-alone
database - all data, no applications. I suspect at some point they
will figure out how to allow end-users to attach business rules to
their data and build apps around data hosted at Google Base (maybe
with Web Services) - they'd be silly not to do this. It's at this
point that I'd agree that Google becomes a platform for development
rather than the series of unrelated tools as I see them now. And I'll
predict that Microsoft will follow with their own Google Base Killer,
a hosted database solution served from Microsoft servers through their
new ASP initiative.

T

Albert D. Kallal wrote:

Hi Albert.

It has been a long time. I was wondering if you were going t jump in
on the MS Access comments :-)

Sounds like things are going well. Good to hear.

Cheers,

--
Kevin Powick

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote


Well, actually, the multi-value support in the next version of ms-access is
a very cool concept. It seems to me that this is a endorsement of the MV
model and concepts we had for 30+ years. Kind of puts a smile on my face
anyway....

The fact is that the MV model has a greater ease of use, and a end user does
NOT need to think relational to use this stuff. This is much the value of
multi-value!

Do note that these multi-value extensions extend to the sql also.....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
http://www.members.shaw.ca/AlbertKallal

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote:
You're right. Access simply shouldn't be used with a database over
50MB (even that's over the top IMO) and with more than one persistent
user. As soon as a site pushes those boundaries they should consider
a real system. From a ODBC/ADO.NET perspective, the difference
between MS Access and SQL Server is trivial, some apps give a free or
low-cost version based on Access because they know no real company can
use it, and offer an upgrade to SQL Server as required.

It's for this same reason that the big MV DBMS providers should long
ago have considered a "lite" version of their platforms, no compiler,
limited file size and item count, no spooler or tape handler, no TCL,
etc. It would have been a great affordable low-end system and a
lead-in to a real system. These days however we have OpenInsight and
OpenQM to fill that gap. Revelation is doing great marketing and
LadyBridge is doing the Open Source thing. I'm really happy to see
that. For anyone who is going after the low end of the business
market and consumer products we might not need anything else.

Agreement again. I didn't mean to imply end-users were at fault here.
I'll clarify if required.


Wow, that sure hits the target.


If you haven't seen it, Microsoft is going all out to provide
applications via the web starting next year. They will be hosting CRM
and ERP and many others. They've been looking for partners to sign up
and they're getting some biggies - but yes, there is some skepticism
about security, Microsoft as a Customer Service provider, competition
with the reseller channel, etc. For over a year I've been offering
for-fee consultation to VARs who want to survive initiatives like this
from the large corporations like Microsoft, Oracle, and SAP. Anyone
who doesn't see how these initiatives are going to kill their business
is wearing blinders. There's more to come, I'm not offering free
market strategies in a public forum.

T

Hi Albert
Thanks a million, your explanations on your site are great. I am blown away
by the thought of Microsoft having multi-value . After 30 years of using
Pick I could not think of life without it. Of course you have neatly
confused my plans re PHP and or Flashconnect etc now I have more study to
do.
Peter McMurray
PS love the chateau
"Albert D. Kallal" <kallal (AT) msn (DOT) com> wrote

"Peter McMurray" <excalibur21 (AT) bigpond (DOT) com> wrote

Well, don't jump too high yet here. You have to remember while this
multi-value extends to the new ms-access query engine, and to the sql, it
does not extend to each field on a form as such.

What this ability will accomplish however is that new users will find
creating queries on related tables VERY easy. I think for experienced
developers, this will not help a whole lot. For example, you might have
case where you display a "list" of possible selections on a screen. Lets say
got a form such as:

Please select the clients favorite colors from the following list:
(more then one is allowed)

red
green
blue
yellow

The data entry person can highlight 1, or 2...or as many colors from the
list as needed. Right now, to code the above choices, you would use a
listbox, and then have to take the selected values, and write them out to a
related table (the many side). With the new "many to many" join, no code
would be needed be written here as a control is now provided to do this for
you.

Further, the amazing part is that sql statements will work on the "many"
side of the field without having to specify a join. (so, in this regards,
you do get a multi-value experience).

However, you can't just take a field and decide you want to have multiple
values in it. So, this is kind of a kiss, but not with a full hug. In a
sense, this is really what we call in our industry a leaky abstraction. You
can read about those here:

http://www.joelonsoftware.com/articl...tractions.html

Simply put, this is an attempt by MS to increase the usability of relational
data to users that have difficulty with this concept. And, it also reduces
the coding, and need to use relational "joins" to pull data together.

However, from a developers point of view, it does NOT give us the ability to
simply start adding "more" values to a given field. So we don't really get
the full MV programming benefits from this new "many to many" feature of
ms-access. (the dao/ado model is extend however). It does seem that xml, and
the need to work with "lists" from SharePoint was a reason for this new
feature.

You can read about it here:
http://blogs.msdn.com/access/archive...13/480870.aspx

This is a ms-access feature, and not a sql server feature, and really is
something to try and make things easy for users...but for us developers, I
can't say it will do that much since it is not a real MV implementation
here.

--
Albert D. Kallal
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
http://www.members.shaw.ca/AlbertKallal

Fairly OT here...

"Albert D. Kallal" wrote:
I don't know how many people see this but Microsoft has made a lot of
changes to their latest product releases with the intent of catering
to nuveau/hobbyist developers. Other examples include improved
support for databound controls and the new "My" keyword in VB.NET
which makes it all too easy for new programmers who know nothing about
OOP to create the sloppiest code on earth. The problem is that even
seasoned programmers are going to tap into these new features, sort of
adding an amateur signature to what might otherwise be professional
code.

T

Quotes just for the helluvit:
- "BASIC is to computer programming as QWERTY is to typing." (Seymour
Papert)
- "It is practically impossible to teach good programming style to
students that have had prior exposure to BASIC; as potential
programmers they are mentally mutilated beyond hope of regeneration."
(Edsger Dijkstra)
- "[Visual Basic] is a poor imitation of an object system for a poor
imitation of a programming language that poor imitations of
programmers use to write poor imitations of programs for poor
imitations of employers who pay poor imitations of programmers'
salaries." (Jim H Jacobs)
- "Real programmers can write assembly code in any language." (Larry
Wall)

Gee, that was those "leaky abstractions" is all about. (and, yes...the net
..net features for data binding are actually taking much hints from products
like ms-access). Each new generation of software tends to eliminate, or move
one farther away from the actual inner working of a computer. Today we see a
lot of languages are loosely typed, and with the advent of xml, we see a lot
of languages that allow string manipulations of data. These things make
programming somewhat easier, and perhaps the c++ guys don't like this.

Come to think of this, was not Pick one of the first on the block to make
things easy for developers? I would go so far as to say that Pick is around
today because of so many vertical market packages that were "more" easily
written due to these "ease" of use features.

Those assembler and c++ guys never respected those VB developers anyway.
(and, that group further dizzied the ms-access group!!). I not sure those
developers would have respected Pick either. Since most developers don't
know what pick is, then they give it a good order of respect, but I don't
think that would be case if Pick was as wide spread as say VB.....

I am not sure where all this attempting to make things easy will end up at,
but it seems that the trend is to more scripting languages today then
ever....

Gee, the way things are going, we will all back to writing procs in the
future!!!

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
http://www.members.shaw.ca/AlbertKallal