On Aug 18, 6:18*pm, "David W. Fenton" <NoEm... (AT) SeeSignature (DOT) invalid>
wrote:
Just my 0.5p worth. I've been developing with Access since v1 and I
have *never* used a runtime. However, I must add that almost all my
work has been with small/v. small businesses where the owner/manager
is often the user as well and I tend to work on-site except for the
heavy lifting stuff where I like to have my own PC and tools
available. I don't like working on laptops, even with an attached kb
and mouse - I'm an old fogey! This makes runtime too much of a
bother. Working on-site means I am able to consult with the user(s)
as I build and also I don't have to be concerned about different
screen resolutions, PC speeds and so on. It also makes billing more
transparent!

Anyway, in my sector I cannot foresee any of my actual or potential
clients being interested in a Sharepoint style of working. It just
doen't fit with what they do and it would be an unnecessary expense.
I don't suppose MS will lose any sleep over this however!

JB

a a r o n _ k e m p f <aaron_kempf (AT) Hotmail (DOT) com> wrote in
news:5e8bdc6c-49d6-49ee-9aae-9381a8eb36de (AT) a4g2000prm (DOT) googlegroups.com
:

[nothing worth reading, except for the amusement value]

Your misleading or wrong assertion rate is higher than 1 error per
sentence. It must take you quite a lot of time to construct these
artfully wrong-headed posts.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On Wed, 18 Aug 2010 16:50:16 -0700 (PDT), a a r o n _ k e m p f
<aaron_kempf (AT) Hotmail (DOT) com> wrote:

Wrong. I objected to your insistence on using ADPs everywhere all the
time.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

"David W. Fenton" <NoEmail (AT) SeeSignature (DOT) invalid> wrote


Been very busy, sorry about being to late in responding here

Sure, but that is not the goal or problem being solved here .

And, this approach It *IS* necessary when doing web based Development. Front
page, Expression,
or just about ANY web based system DOES NOT FORCE you to re-publish the
WHOLE WEB SITE EVERY TIME.

You mean I change some text, or move a text box, or add a text box, you are
now suggesting that I must re-publish THE WHOLE WEB SITE?

As I said, this type of publish model is standard fair in web development,
and to suggest that web publishing is going to be turned into something
where every web single object must be re-published when ONE object is
changed is simply how web development IS NOT DONE. While most people have
high speed connections, having to publish up to a web server every single
web
page when only one been changed makes no sense at all here. On a desktop,
you don't have this bandwidth issue, and for access, you not dealing with
separate files (physical).

I frequently publish up changes to downloadable files to my web server, it
takes a long time even to just pump up a minor change and then the resulting
few megabytes files takes a long time to up-load.

With access web services, you make a change to one form and hit published,
Bam it barely takes a second.

This not only performance considerations, as I mentioned it's the nature of
the beast and the architecture.

This all comes down to the web model and
the fact that a web servers are built around a model of reading web
SINGLE web pages and dishing them out. The web server software
can't know or read a single mdb file and view it as many pages. The
Access web services are built around standard web technologies (IIS, and
..net).

If the Access team could build their own web server, then sure this would be
possible, no more so then having to build their own version of SQL server
that perhaps
allows to publish an mdb file directly to SQL server that would THEN read
and consume
an access file. I mean this would be fantastic, and is possible, but is not
realistically practical.

When access web services was built, it was not possible to build and create
a NEW web server, it HAD TO USE EXISTING web server technologies.

It was not a question of leaving it out, it simply how the system works.
Both client objects and web objects are saved on the server as separate
objects. A change to one client form, or web form is done on the desktop,
but
results are saved on the server (so, this is exactly like source code
control here - nothing new).

If you not going to save and shuffle out parts, then just use Tony's free FE
then? Or just place a inno scrip install as an link on the SharePoint site
and you done. There is no need to use SharePoint for this.

With access web services, you make a change to one form and hit published,
it's done in the blink of an eye. It really supports the RAD development
model that access is always had.

It is a useful design goal if you looking to publish parts to a web site.
Now I understand that you're clearly speaking in terms of client based
development, but as I said this model is adopted for the web based
architecture, the fact that access is always been capable of viewing forms
and reports of separate objects is continued to be utilized here.

I think it's a really good architecture, because those individual objects
are not only publisher that website, but it would be now in theory possible
to write other types of third party tools to go through those pages and
modify them.

Like it or not, web sites are made up of many individual parts that are
dished out to the web server. They don't work like traditional desktops in
which you have an executable that is compiled and run as a SINGLE object.

As I stated, this issue has little to do with desktop development. I 100%
agree this is not what traditional Access developers do.

I should point out that not only from near day one have most web developers
adopted this idea of modifying a single page at a time, but if you look at
just about every other major development tool and platform in the
marketplace, the standard industry tools even for 100% desktop based
development not only logically view objects to separate entities, but also
physically have each objects stored as a separate file.

So I'm hard pressed to think of any standard tool even for desktop
development that does not treat each object as a separate file, the fact
that access web Services Works this way should not surprise you since it's
based on industry standard tools.

And again my point here is is once again the architecture for most
traditional development environments, is treating everything as both
logically and physically as separate files. In fact I would say that access
is likely one of the few development products in the marketplace that has a
single container file for the source objects.

Well it is if you're going to get into web development and start utilizing
existing web based technologies, and I stress the utilizing these other
technologies part.

Because Access web services is based on the standard web tools, then the
result is this posting today on the Access blog that allows you to hook in
..net code and read data my MySql in a Access form:

Going beyond Web Macros: Using Event Receivers & .NET with Access Services
http://blogs.msdn.com/b/access/archi...-services.aspx

Once again, I cannot stress how important this architecture is, and by
access web services choosing and utilizing existing technologies, it also
means that we open up the doors to utilizing other existing technologies
that's also built to work around the .net framework and Microsoft web
servers.

The design goal here was not to be able to save and shuffle individual parts
in and out of CLIENT based applications, but the whole system is capable of
doing such, and this ability thus just represents a bonus as to how we can
distribute applications that are being modified in environments. If you
taking the approach that none of your applications are ever modified by end
users, then this is not really relevant in terms of desktop development.

However even in the case of classic web development where you end users
never modify the product, the architecture and approach is still a logical
and physical view of separate files, and access web services pretty much had
to join his party in this fashion.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

"a a r o n . k e m p f @gmail.com [MCITP: DBA]" <aaron.kempf (AT) gmail (DOT) com>
wrote

Access does work well with SQL Server, but there are many situations where
it is not the best approach, and, for that reason "not everyone with a clue"
moved to it. Many of the clients for whom I consulted/contracted had other
databases as their corporate standard, and because of Access'
interoperability (via ODBC), it was a great choice for a front end. Almost
every one of those clients had applications that just didn't warrant the
time/effort/TLC/maintenance required for a server DB, so they'd just use
(for safety and convenience) split Access databases... front end features in
an MDB/MDE on the user machines and linked tables in an MDB on the server.

No, you are only kidding yourself to believe that every user shop is going
to have a server, and will have installed and will maintain SQL Server.
There is a vast, knowledgeable mass of computer users who know they should,
and will, choose appropriate software tools for the situation.

Larry Linson
Microsoft Office Access MVP

Albert D. Kallal wrote:

Depends on what kind of web development doesn't it? All of my web
development is building AJAX-apps that are published within Java servlet
projects. These are distributed as WAR files on a Tomcat server. In that
scenario the entire WAR file (around 20 MB) IS distributed even when one has
made just a small change to a single file. While this might sound wasteful
it does have the advantage that the entire project with all of its
dependencies is rolled into a single package that can be easily deployed on
different servers by just dropping a file into the correct folder.

Now, a WAR file is not "the whole web site", but in most cases neither would
a webified Access app be. I suspect most places that would be interested in
deploying Access in this manner would already have either an intranet or
internet set up.

The point being that while uploading only the part that changed might be a
nice feature, it does not justify a costly framework to achieve it.

Access Developer wrote:
product. In my unlearned view, I consider SQL Server similar to a
backend. It has tables. You can set up indexes. It contains data. But
for data entry one needs, or should use, a front end if I have it correct.

What do people use as "front ends" for SQL Server? I know HTML pages on
the web may communicate and update data from SQL Server. As far as a
desktop application, what is the popular front end, data entry program?
VB? Access? Others? Or does SQL Server have it's own front end?

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in
news:TKYco.3864$8A2.2725 (AT) newsfe22 (DOT) iad:

Precisely the issue -- MS is solving the wrong problem, and, as a
result, has made it too expensive for most of us.

Sure, no problem. But if you're not doing Web Development, there
really is no justification for requiring the infrastructure to
support it for things that are much simpler (or could have been).

I understand that. I'm saying that this was a design error on MS's
part to use the same approach to two very different problems.

[]

By their choice, not of necessity.

By their choice, not of necessity.

By their choice, not of necessity.

Why deploy one system to share data and another to share your
application?

[]

But not if you're not. This is my entire point, and always has been
-- the new web feature drove the design of the implementation of
client app distribution, failing to account for the way updates to
most client front ends are most logically distributed.

Again, by their choice, not of necessity. The result of their choice
to implement it this way means they've priced most of our clients
out of the market for it.

Exactly the problem, in my opinion. Instead of Sharepoint
integration being enhanced in a way that makes our desktop
development easier, they've instead chosen to do something that our
traditional clients won't be able to benefit from because of the
enormous expense of the way they've implemented it.

This is exactly what happened with A2000 -- changes to Access were
driven by the needs of a set of users who mostly weren't interested
in Access in the first place, and it's taken a very long time to
correct those mistakes. Now MS seems to be making a whole new set of
similar mistakes, leaving their traditional developer population
behind, to fend for themselves.

[]

But if web development is not needed, you also can't benefit from
any of the other features of Sharepoint distribution because they
bundled all those features into Access Services.

[]

I don't really understand why you think repeating the same argument
over and over again (Web Apps are great -- something on which we
don't disagree one bit) is somehow a response to my criticism. They
didn't have to implement it the way they did. They chose to do so,
and the result is that the product is going to fail to be used in
the exact market segment in which it is most suited.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

"Access Developer" <accdevel (AT) gmail (DOT) com> wrote in
news:8djjc5FqglU1 (AT) mid (DOT) individual.net:

Aaron doesn't have any clients or any actual real-world development
experience, so of course he wouldn't know any of these things.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

Yes, SQL Server is a server database... generally, though not necessarily,
that implies that the database engine runs on a different machine than the
UI; Jet/ACE is a file-server database; the database engine runs on the same
machine as the UI, though the tables may reside on a different machine.
Oracle, MySQL, DB2, Informix, and various Sybase products are also server
databases. In "enterprise installation", the database may require and
utilize multiple server machines, a cluster, or, in fact, need a "server
farm".

No, MS SQL Server does not include its own front end... other than features
for database administration, not intended to support a database application,
just defining and maintaining databases.

Those server databases require a separate installation, administration, and
(usually a good bit of) tender loving care. You can communicate directly
with Microsoft SQL Server using an Access ADP (this is Mr. Kempf's
favorite). Others can be used, if ODBC-compliant, by linking the tables
from the Access MDB or ACCDB.

Microsoft has, over time, made available a "stripped down" version of MS SQL
Server, called MSDE (Microsoft Data Engine) which was included with some
versions of Access, but had to be installed separately and lacked some very
useful administrative functions of MS SQL Server. Now, there is a Microsoft
SQL Server Express Edition that is free for the downloading, and even more
capable, it is limited in power, and somewhat limited in function, but is
much closer to a small installation of the commercial MS SQL Server.

You can, and people do, create front ends in many programming languages...
in the DotNet world, those include VB.NET, C#, and other DotNet-compatible
languages. Earlier front-ends were often in classic VB, C++, the older C,
Delphi, and others. A product that was just for creating front-ends was
Power Builder -- it was bought by Sybase, but I think it can still be used
as a front end for other server DBs. For LAN or WAN environments, Access is
an excellent UI (front-end) for ODBC-compliant or using OLEDB, for an ADP
accessing Microsoft SQL Server directly.

--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access


"Salad" <salad (AT) oilandvinegar (DOT) com> wrote