accdb vs adp

  • Thread starter Thread starter briank
  • Start date Start date
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. Instead of connecting the ADP to the
remote database, you connect it to the local SQL-Server. Not that much
different than your current scenario.

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. Of course, you can start mixing up a solution on
the server like setting up some SSIS jobs in order to synchronise SharePoint
with the other database but then, bye bye the simplicity and say Hi! to the
costs.

--
Sylvain Lafontaine, ing.
MVP - Windows Live Platform
Blog/web site: http://coding-paparazzi.sylvainlafontaine.com
Independent consultant and remote programming for Access and SQL-Server
(French)
 
"a a r o n . k e m p f @ g m a i l . c o m" <[email protected]>
wrote in
m:
-Aaron
Click to expand...

Welcome back from jail, or parole, or whatever part of your
punishment for stalking/harassment has now reached its end, and
apparently now allows you to post your lies and misrepresentations
in public places without fear of retribution.
 
I hadn't heard this. Any URLs?
Click to expand...

Something somebody said somewhere (how's that for specific?) and a
post on the Access team blog:

Access 15 and SQL Server:
http://tinyurl.com/yffbdyt =>
http://blogs.msdn.com/access/archive/2009/12/03/access-15-and-sql-ser
ver.aspx

I'm trying to think where I heard the information about ADPs and
such, and am drawing a blank. I thought it was somewhere here in the
newsgroups, since I trusted the source (I wouldn't be passing it on
if I hadn't marked it as trusted in my memory).
 
Stalking / Harrassment.. uh, what are you talking about?

Legally, it never happened.

Thanks for your concern though!

-Aaron
 
ROFL oh that's cute dude!!!

Yah right, I'm sure it works as well as the rest of Jet does!!!

Tired of corruption?
Tired of bloat?

Move to ADP / SQL

-Aaron
 
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.
 
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
 
Something somebody said somewhere (how's that for specific?) and a
post on the Access team blog:

Access 15 and SQL Server:
http://tinyurl.com/yffbdyt =>
http://blogs.msdn.com/access/archive/2009/12/03/access-15-and-sql-ser
ver.aspx
Click to expand...

Oh yes, now I recall that posting.
I'm trying to think where I heard the information about ADPs and
such, and am drawing a blank. I thought it was somewhere here in the
newsgroups, since I trusted the source (I wouldn't be passing it on
if I hadn't marked it as trusted in my memory).
Click to expand...

In that same blog posting:

"How often do create a ADP + SQL solution vs. a Access frontend linked
to SQL? In other words, how often is it about something like an ADP,
and how often do you work with linked SQL tables? Is one of these
more important for us to improve than the other?"

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/
 
DSN and linked tables, and all that other junk-- is just a waste of
time.

It gives zero benefit over linked servers, for example
 
Stalking / Harrassment.. uh, what are you talking about?
Click to expand...

http://www.courts.wa.gov/index.cfm Search Case Records >> Name
Search .>> Accept >> key in someone's name.
Legally, it never happened.
Click to expand...

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/
 
Sylvain Lafontaine said:
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.
Click to expand...

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.
Click to expand...

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 said:
Not quite how SharePoint works. Each table is a separate "list".
Click to expand...

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/index.php?s=&showtopic=1920219&view=findpost&p=1920240

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.
Click to expand...

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

message
 
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.
 
message

Tired of corruption?
Tired of bloat?

Move to ADP / SQL

-Aaron
========================
That would make sense if it were true. Regular maintenance of any database,
as well as adherence to good design, negates both bloat and corruption. I
haven't actually experience either since 2003.
 
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
 
Jet is impossible to make 1,000th as reliable as SQL Server

It's just not possible.

Only a retard would pretend that it's in the same galaxy.

(it might work great until your boss wants to run something on
wireless ROFL)
 
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
 
Back
Top