accdb vs adp

"a a r o n . k e m p f @ g m a i l . c o m"
wrote:

Stalking / Harrassment.. uh, what are you talking about?

http://www.courts.wa.gov/index.cfm Search Case Records Name
Search . Accept key in someone's name.

Legally, it never happened.

See above

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/
Granite Fleet Manager http://www.granitefleet.com/

"a a r o n . k e m p f @ g m a i l . c o m"
wrote:

your autofeupdater runs progressively slower the more queries you
have.

Rubbish.

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/
Granite Fleet Manager http://www.granitefleet.com/

"Sylvain Lafontaine" wrote in message
...
You can as easily set up a SQL-Server Express local to your machine and
make it synchronises over the Internet to a remote database and make it
work in both connected and disconnected mode.

Sure, it is doable, but you have to setup + install + maintain that local
instance of sql server. (and, do you want that running when access is not
running?).

Setting up sql express local is not always an option.

So, there is setup time here. And, you most certainly have to
setup some scripting to set that local instance into becoming a
proper subscriber.

For the rest, SharePoint is a big table, not a database. If you can put
everything in a single table then that's fine but for connecting to an
existing database with multiple tables interconnected with relationships;
not so sure about that.

Not quite how SharePoint works. Each table is a separate "list".

For SharePoint 2010 + access 2010 it supports cascade delete and RI features
like cascade delete restrict between tables (lists). So, we have RI between
tables pushed up to SharePoint.

Performance is great because you using JET as a local data store for the
tables. Sync occurs via a web service that does a difference on the two
ends. It is a very slick setup.

Even more interesting is that our new data triggers and stored procedures
for JET (now called ACE) will also run on SharePoint. So, you can develop
that trigger code and build those tables local. Once you publish to
SharePoint, the stored procedures and table triggers also move up into the
cloud (and, we don't have to re-write them). This also means if you build
a web site with access and publish access web forms to the web, then you
don't have to re-write the table trigger code and stored procedures. This
means that ms-access when used to build a web site with web forms results
in a true multi-tier design.

I would say that as a rule, I still prefer using sql server with access, but
the ease with which users can now use SharePoint and now that SharePoint
supports RI between tables, this means a good number of "lesser" skilled
access users will likely prefer SharePoint over that of sql server. It just
so very easy (this assuming the company has SharePoint). They as a rule will
not have to call IT like they do with sql server to get some instance of sql
server setup and running.

Looking around here, and my personal experience, we see a LOT more access +
sql server questions. However, I see some of these users now choosing
SharePoint
because "they can" and will due to ease of use..

SharePoint can also push out new front ends for those users that don't yet
have
the desktop "client" access installed. So, SharePoint just solves so
many issues of deployment and centralizing the data but gives the user a
desktop
development experience.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

Albert D. Kallal wrote:
"Sylvain Lafontaine" wrote in message
For the rest, SharePoint is a big table, not a database. If you can put
everything in a single table then that's fine but for connecting to an
existing database with multiple tables interconnected with relationships;
not so sure about that.

Not quite how SharePoint works. Each table is a separate "list".

I would agree with Sylvain. I did look into the actual SQL Server tables
driving the Sharepoint server and indeed, all lists are saved in two
tables. One table contains the list's definition/structure while another
table contains the list's actual content. I listed the DDL statement for
both tables in this post:

http://www.utteraccess.com/forum/ind...st&p=192 0240

Mind, Sharepoint may show us a bunch of lists while storing them all in
a big table so there's a lot of voodoo going on and is a big reason why
many Sharepoint MVPs will say "Do NOT touch SQL Server!" I saw a snippet
of a Drupal CMS structure and was just equally horrified by its
denormalized structure. I've not gotten a clear reason behind the
structure I saw in Sharepoint, but I would never think to consider
Sharepoint a relational database in any way.

For SharePoint 2010 + access 2010 it supports cascade delete and RI
features
like cascade delete restrict between tables (lists). So, we have RI between
tables pushed up to SharePoint.

This is true. This is a big win here for us, I would think. I'm not sure
what they pulled but at least it moves the burden from our shoulders to
their shoulder.

Aaron,

Sometimes I actually feel sorry for you. It must be hard to make a fool of
yourself over and over again, yet you do it, apparently compulsively. I
can't help but wonder why you feel compelled to make irresponsible
statements like this. And to what end? What do you think you gain by it? It
just makes no sense.

But, for the sake of clarity and in the hope that we can extract some
semblance of logic from these assertion, I would like to give you a chance
to explain and, if possible, provide citations for your claims.

So, let's clarify what you mean by this: "new features in ADP for every
version for the past 5 versions." Past 5 versions of WHAT? It's tempting to
assume you MIGHT be referring to new ADP features in MS Access, but then,
you really didn't bother to make that clear. What, exactly, do you mean? Are
you saying that there were new ADP features in Access 2010, 2007, 2003, 2002
and 2000? Or did you mean something else? Can you, will you, provide
citations describing some of those "New Features" for each of the past 5
versions? Doing so might go a long way towards removing the stigma of
irresponsibility and irrationality that hangs over all of your posts.

Actually, having watched your decent into ever more bitter and disconnected
rambling vitriol over several years , I harbor no real expectation, or even
hope, that you'll realize how self-destructive your posts have become. Yet,
there is always hope, and I can't quite give up on you. Perhaps this will be
the time when you finally get it. Is that possible?

George

"a a r o n . k e m p f @ g m a i l . c o m" wrote in
message
...
neglect of ADP?

that never happened, kid!

there have been new features in ADP for every version for the past 5
versions.

there have been new features in SQL Server for every release for the
past 5 versions.

-Aaron




On Feb 23, 10:53 am, "Tony Toews [MVP]"
wrote:
"David W. Fenton" wrote:

But all of this will change 2-3 years from now, with the release of
Access 15, which apparently is going to address the neglect of ADPs
in the last two releases. That isn't enough to convince me that it's
wise to trash an MDB app and replace it with an ADP even then, but
it's worth keeping in mind (i.e., the investment in moving to ADP
could pay off 2 or 3 years down the road; on the other hand, the
Access 15 ADPs could be sufficiently different to make current ADPs
problematic).

I hadn't heard this. Any URLs?

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 seehttp://www.autofeupdater.com/
Granite Fleet Managerhttp://www.granitefleet.com/

"a a r o n . k e m p f @ g m a i l . c o m" wrote in
message
...
your autofeupdater runs progressively slower the more queries you
have.

keeping all your data and queries in one place- where they belong - on
a database server-- is a much more effective and efficient method.
======================
Let me explain database design to you, as you seem to be under the
impression that you actually know something. MVPs, including those in
SQL-Server, know that is a misapprehension on your part.

No matter where a query is run, it's speed is more determined by the design
of the tables and relationships, and the query design, than what the
database engine is. For small tables (generally under 100,000 rows) queries
are often faster using JET than SQL-Server, given the same equipment and
environment. Generally, the most powerful machine which is devoted to the
job, is the speed determiner. That's not always true, especially with
smaller datasets. As networks get even faster, that becomes even less
important.

SQL-Server is an important tool used by most Microsoft designers, including
Access MVPs. There are many instances where JET is the better tool for the
job. If you regarded your clients (if you really had any) as much as we do
ours, you'd pay attention to your their best interest, instead your
prejudices and misconceptions.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

"a a r o n . k e m p f @ g m a i l . c o m" wrote in
message
...
neglect of ADP?

that never happened, kid!

there have been new features in ADP for every version for the past 5
versions.

there have been new features in SQL Server for every release for the
past 5 versions.

-Aaron




On Feb 23, 10:53 am, "Tony Toews [MVP]"
wrote:
"David W. Fenton" wrote:

But all of this will change 2-3 years from now, with the release of
Access 15, which apparently is going to address the neglect of ADPs
in the last two releases. That isn't enough to convince me that it's
wise to trash an MDB app and replace it with an ADP even then, but
it's worth keeping in mind (i.e., the investment in moving to ADP
could pay off 2 or 3 years down the road; on the other hand, the
Access 15 ADPs could be sufficiently different to make current ADPs
problematic).

I hadn't heard this. Any URLs?

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 seehttp://www.autofeupdater.com/
Granite Fleet Managerhttp://www.granitefleet.com/

Jet has no benefit, it causes slower performance and bigger table
scans.

Sprocs, Views, Functions are thousands of times more powerful.

SQL Server - out of the box- allows every user to have a different
copy of the same object if you want.

It's just completely false to claim that Jet has any benefit over SQL
Server.

-Aaron

On Feb 23, 8:21*pm, "Arvin Meyer [MVP]" wrote:
"a a r o n . k e m p f @ g m a i l . c o m" wrote in
...
your autofeupdater runs progressively slower the more queries you
have.

keeping all your data and queries in one place- where they belong - on
a database server-- is a much more effective and efficient method.
======================
Let me explain database design to you, as you seem to be under the
impression that you actually know something. MVPs, including those in
SQL-Server, know that is a misapprehension on your part.

No matter where a query is run, it's speed is more determined by the design
of the tables and relationships, and the query design, than what the
database engine is. For small tables (generally under 100,000 rows) queries
are often faster using JET than SQL-Server, given the same equipment and
environment. Generally, the most powerful machine which is devoted to the
job, is the speed determiner. That's not always true, especially with
smaller datasets. As networks get even faster, that becomes even less
important.

SQL-Server is an important tool used by most Microsoft designers, including
Access MVPs. There are many instances where JET is the better tool for the
job. If you regarded your clients (if you really had any) as much as we do
ours, you'd pay attention to your their best interest, instead your
prejudices and misconceptions.
--
Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com

new features in ADP for every
version for the past 5 versions." Past 5 versions of WHAT?


Access 2000 - First version
Access 2002 - better UDF / SQL Server support
Access 2003 - pivotTables
Access 2007 - SQL 2005, half dozen other features
Access 2010 - SQL 2008 support

There you are-- new ADP funcitonality in each of the past 5 versions


On Feb 23, 6:14*pm, "GP George" wrote:
Aaron,

Sometimes I actually feel sorry for you. It must be hard to make a fool of
yourself over and over again, yet you do it, apparently compulsively. *I
can't help but wonder why you feel compelled to make irresponsible
statements like this. And to what end? What do you think you gain by it? It
just makes no sense.

But, for the sake of clarity and in the hope that we can extract some
semblance of logic from these assertion, I would like to give you a chance
to explain and, if possible, provide citations for your claims.

So, let's clarify what you mean by this: "new features in ADP for every
version for the past 5 versions." Past 5 versions of WHAT? It's tempting to
assume you MIGHT be referring to new ADP features in MS Access, but then,
you really didn't bother to make that clear. What, exactly, do you mean? Are
you saying that there were new ADP features in Access 2010, 2007, 2003, 2002
and 2000? Or did you mean something else? Can you, will you, provide
citations describing some of those "New Features" for each of the past 5
versions? Doing so might go a long way towards removing the stigma of
irresponsibility and irrationality that hangs over all of your posts.

Actually, having watched your decent into ever more bitter and disconnected
rambling vitriol over several years , I harbor no real expectation, or even
hope, that you'll realize how self-destructive your posts have become. Yet,
there is always hope, and I can't quite give up on you. Perhaps this will be
the time when you finally get it. Is that possible?

George

"a a r o n . k e m p f @ g m a i l . c o m" wrote in
...

neglect of ADP?

that never happened, kid!

there have been new features in ADP for every version for the past 5
versions.

there have been new features in SQL Server for every release for the
past 5 versions.

-Aaron

On Feb 23, 10:53 am, "Tony Toews [MVP]"
wrote:
"David W. Fenton" wrote:

But all of this will change 2-3 years from now, with the release of
Access 15, which apparently is going to address the neglect of ADPs
in the last two releases. That isn't enough to convince me that it's
wise to trash an MDB app and replace it with an ADP even then, but
it's worth keeping in mind (i.e., the investment in moving to ADP
could pay off 2 or 3 years down the road; on the other hand, the
Access 15 ADPs could be sufficiently different to make current ADPs
problematic).

I hadn't heard this. *Any URLs?

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 seehttp://www.autofeupdater.com/
Granite Fleet Managerhttp://www.granitefleet.com/

look at the code dude

making your users wait an extra 5 seconds while you copy over lookup
tables, queries? what a joke dude

'the worst software ever written' because it's more efficient to keep
all your tables in one place- where they belong- a database server
that supports SMP, X64, etc

-Aaron



On Feb 23, 4:01*pm, "Tony Toews [MVP]" wrote:
"a a r o n . k e m p f @ g m a i l . c o m"
wrote:

your autofeupdater runs progressively slower the more queries you
have.

Rubbish.

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 seehttp://www.autofeupdater.com/
Granite Fleet Managerhttp://www.granitefleet.com/