Is mdb safe to travel through vpn?

[Todos Menos [MSFT]]

Tom

you're a mother fucking pussy for not standing up for ADP

ADP makes a huge difference

grow some balls, pussy-boy


ADP uber alles


and FUK MICROSOFT

Dear David:

OK, sorry. Not so much difference in which FE design tool you choose.

Tom Ellison
Microsoft Access MVP

That wasn't my question. I was talking ADP->MSDE/SQL Server vs.
MDB->MSDE/SQL Server. Everyone already understands that Jet can't be
as efficient as a server back end.

But I'm only addressing the front end question, since you brought up
ADP.

 

[David W. Fenton]

It's not that JET is slow, it's that a WAN is slow and JET must
return at least the indexes of the entire table(s) to work

Huh? Doesn't Jet hand off the whole thing to the server when it
determines that it can do so? We're talking about SQL Server as a
back end here, so Jet's behavior with Jet data is really irrelevant.

 

[Todos Menos [MSFT]]

re:
The advantage of using the JET overlay to SQL-Server
is that you can run a local JET query on top of a SQL-Server pass-
thru.

I sure as hell don't get this

You don't NEED to run queries on top of queries

the whole Jet layer is unnecessary

how many chipmunks does it take to update a SQL Passthrough Call?

ROFL

 

[Todos Menos [MSFT]]

If Jet used SQL Server data efficiently; I would consider JET.

but it doesn't; it hasn't and it won't

JET is a dead dog and you kids are sitting here; humping a dead dog

it makes me sick

anyone that uses MDB for anything should be fired and then spit upon

 

[Todos Menos [MSFT]]

SERIOUSLY

it's not jet that is slow; it is the WAN that is slow?

BUT THIS SLOW WAN IS ONLY A PROBLEM WHEN YOU USE MDB.. RIGHT?

MDB doesn't work across WAN, VPN, Wireless-- or the public internet.

ADP works flawlessly over any of those four

 

[Todos Menos [MSFT]]

ADP hands everything off to SQL server-- there is no other layer
if you want to call a sproc with 3 args; it takes like 0 code

MDB is just unnnecessary overhead

 

[Todos Menos [MSFT]]

this from the dipshit that 'still uses Access 97'

rofl

ADP / ADO is faster, easier, more stable, more scalable for EVERYTHING

 

[Tony Toews [MVP]]

ADPs are listed as Microsoft to be 'considerably faster than MDB for
reporting, specifically'

URL?

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

 

[David W. Fenton]

URL?

He's paraphrasing a selective quote, of course. His source is:

http://technet2.microsoft.com/Office/en-us/library/1dce641e-ba1c-
446a-8ff2-221769a58ba51033.mspx?mfr=true

....where it does, in fact, say:

Because of the layers required to get from Access to SQL Server in
the ADP architecture, it is often easier to optimize MDB/ACCDB
file solutions. However, there are some scenarios where a report
might be generated significantly faster in an ADP file. . . .

and:

One advantage that ADP files have over files in MDB or ACCDB
format is the ability to make design changes to SQL Server
objects. . . .

But if you read these things in context, you find that they come
after this:

Access uses OLEDB to communicate with SQL Server. To provide the
Jet-like cursor behavior desired for desktop applications, Access
implements the Client Data Manager (CDM) as an additional layer
between Access and OLEDB.

Because of the layers required to get from Access to SQL Server in
the ADP architecture, it is often easier to optimize MDB/ACCDB
file solutions. However, there are some scenarios where a report
might be generated significantly faster in an ADP file. To add
these performance improvements and retain the flexibility of SQL
Server, you can build the majority of the application in an MDB or
ACCDB file and have the file load reports from a referenced ADP
file.

So, what is really being said is that reports have a minor advantage
in an ADP, but you'd not want that to be the issue that causes you
to build your whole app as an ADP -- instead, you might use the ADP
for reporting, and the MDB for everything else.

But what he puts in quotation marks is not actually a direct
quotation, and that's telling, because it doesn't actually say
exactly what Aaron is implying with his paraphrased selective quote.

The entire relevant passage:

Access Data Projects (ADPs)

An Access Data Project is an OLE document file, like the .xls
or.doc file formats. It contains forms, reports, macros, VBA
modules, and a connection string. All tables and queries are
stored in SQL Server. The ADP architecture was designed to create
client-server applications. Because of this, there is a limit to
the number of records that Access returns in any recordset. This
limit is configurable, but you typically must build enough
filtering into your application so that you do not reach the
limit.

Access uses OLEDB to communicate with SQL Server. To provide the
Jet-like cursor behavior desired for desktop applications, Access
implements the Client Data Manager (CDM) as an additional layer
between Access and OLEDB.

Because of the layers required to get from Access to SQL Server in
the ADP architecture, it is often easier to optimize MDB/ACCDB
file solutions. However, there are some scenarios where a report
might be generated significantly faster in an ADP file. To add
these performance improvements and retain the flexibility of SQL
Server, you can build the majority of the application in an MDB or
ACCDB file and have the file load reports from a referenced ADP
file.

One advantage that ADP files have over files in MDB or ACCDB
format is the ability to make design changes to SQL Server
objects. ADP files include graphical designers for tables, views,
stored procedures, functions, and database diagrams.

Particularly note the first sentence of the third paragraph:

 

[Todos Menos [MSFT]]

oh come on Tony

the famous 'Microsoft reccomends MDB linekd to SQL article' that you
fags cling all your hopes on

 

[Todos Menos [MSFT]]

and I heard that you guys were mentioning in this thread that ADP are
superior for forms

so superior for forms + superior for reports = ADP uber alles

go eat a poop sandwich, mdb wimps

 

[Todos Menos [MSFT]]

David;

and for the record; I just blatantly disagree with this statement:

Because of the layers required to get from Access to SQL Server in
the ADP architecture, it is often easier to optimize MDB/ACCDB
file solutions.

BECAUSE OF THE LAYERS INVOLVED IS WHY ADP IS EASIER TO MANAGE

DO YOU KNOW WHAT SQL PROFILER IS?

Does MDB have a SQL Profiler?

It is _EASIER_ to manage ADP than MDB.

I can run a wizard on a database file-- that will 'automagically fix
indexes' based on a workload

you can run a crappy 'Analyze Performance' wizard that doesn't even
_WORK_ for large MDB applications


Your MDB _CRAP_ is laughable at best

what are you still writing connection strings?

Me? I'm a SQL 2005 Certified DBA; and I've worked on 100+ SQL Server
databases these past 5 years

you?

you're a friggin MDB baby

go eat a poop sandwich, MDB wimp!!

 

[Todos Menos [MSFT]]

re:
Because of this, there is a limit to
the number of records that Access returns in any recordset. This
limit is configurable, but you typically must build enough
filtering into your application so that you do not reach the
limit.



Please not that there is an important exclusion there--

there is an OPTIONAL limit to the number of records that Access
returns in any recordset.

it's called SET ROWCOUNT 0 kid



or shit; set it under tools options to 0 and you'll never have to
worry about it.

but you CAN still put filters on certain tables / views etc-- an
abstraction layer for record count limits-

this is one of the biggest benefits of ADP, kid

MDB doesn't have this filter on recordcount

I mean seriuosly-- how is an OPTIONAL limit on recordcount a limit in
ADP?

I mean seriously here; kid


the dipshit that wrote this article was probably praying to a golden
calf in india; god damn ragheads can lick it

-Todos

 

[i_takeuti]

oh come on Tony

the famous 'Microsoft reccomends MDB linekd to SQL article' that you
fags cling all your hopes on

 

[Todos Menos [MSFT]]

re:
he advantage of using the JET overlay to SQL-Server
is that you can run a local JET query on top of a SQL-Server pass-
thru.


I still disagree.

why would you need to do this?
Let me guess.. because you don't know how to write SQL Server views
and stored procs?



lose the training wheels, kids

seriously MDB is mother fucking crap for everything

MDB against SQL is _NOT_ the same as ADP.
for starters, it takes you 10 lines of code to set some parameters on
a sproc and bind it to a form

me?

it doesn't take me a single line of code to bind a sproc-- with
arguments-- to a form

MDBs will always use JET, but connecting JET to a SQL-Server back-end is the
difference. If you use JET queries, they will always be slower. But if you
use Pass-thrus so that the Server is returning a reduced recordset, the
difference is slight. The advantage of using the JET overlay to SQL-Server
is that you can run a local JET query on top of a SQL-Server pass-thru. Why
would you want to do that? Well, JET has some real advantages in that it can
resolve VBA functions. So, say you have a couple of hundred thousand rows of
data. Use a Pass-thru to SQL-Server to return the 10 rows you need, then run
a JET query on top of that (locally) to return your final result. Best of
both worlds.

It's not that JET is slow, it's that a WAN is slow and JET must return at
least the indexes of the entire table(s) to work. I personally find that
ADPs are often the easiest way to get and write SQL-Server data from a
front-end. Because of the amount of local processing that is done with VBA,
however, I invariably use MDBs for a lot of my reporting.

Still, the most users I've ever had on a WAN is 15, and I find that a
Terminal Server with Jet is still easier for the smaller databases (under a
couple of hundred MBs, that I build). For MSDE/SQL-Express where the engine
is free, the ROI is still often with an MDB because of the faster (generally
30 to 50%) development times. But with the full cost of a SQL-Server
license, the ROI is almost always with the MDB/JET solution.
--
Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com

That wasn't my question. I was talking ADP->MSDE/SQL Server vs.
MDB->MSDE/SQL Server. Everyone already understands that Jet can't be
as efficient as a server back end.

But I'm only addressing the front end question, since you brought up
ADP.

 

[Todos Menos [MSFT]]

the dude is having a problem getting to a MDB file right?>
'
how is JET performance not important in this discussion

mother fucking screw jet and anyone that uses it for anything



SERIOUSLY