Might be outgrowing Access but daunted by SQL Server

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

:

Go play with your deprecated baby sized jet databases, kid

We will, we will.

But at least we actually know something about it that is factually
true. You promote SQL Server for everything, yet, you don't seem to
know the first thing about it given how often you post factually
challenged information.

(I know you're going to ask for examples, and I'll just say read the
followups to any post you make about SQL Server and you'll have your
answer)

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Larry Linson" wrote in
:

Jet was never officially deprecated,

This is true and false. Many people point to some MSDN articles that
have the roadmap for MS's database technologies and it deprecates
Jet. But they fail to notice that the article was written to guide
developers transitioning from MS's old development tools (from the
VB6 era) to the .NET family of development tools. It's obvious that
one really oughtn't use Jet/ACE for .NET development (though perhaps
the 64-bit ACE will make that no longer a vulnerability), and that's
all the articles "deprecating" Jet were about. They were deprecating
Jet for a particular purpose, not for all uses.

The proof is in the pudding of course, with A2007 having shown that
MS has no intention whatsoever to deprecate or replace Jet at all.
Even if they are hoping that Sharepoint will take over all small
business usages, they still need Jet/ACE as local database engine
for managing disconnected data. But having it also brings with it
Jet's historical ability to work with the widest variety of data
sources of any database tool out there. And do it well, with good
default performance and a host of tools to make it easy.

but it didn't get a lot of attention
for a while. Then the product team gave it some attention, and
improved it along with creating a descendant (the ACE database
engine) in Access 2007. At about this time, they ceased
recommending ADP as the preferred Access front-end for SQL Server,
and now recommend MDB with ODBC for that purpose.

It will be interesting to see what comes of the current efforts to
work with SQL Server developers to make the version of Access after
2010 more versatile and SQL Server-friendly.

Some people just can't seem to get the story right... either they
are ignorant or they choose to disseminate false information.

I can't quite understand Aaron's actions as anything but those of a
person who is at some level mentally disturbed. But I am not a
doctor, so I could be wrong on that.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Jon22" wrote in message
...
Well thats troubling. A number of the areas of my database (quotes, jobs
and
designs to start with) work on an identification system that gives each
record (that is to say each Quote or each Job) a unique "Quote Number" or
"Job Number" etc. Now before you jump down my throat, I know that this is
a
basic principal of Access databases and that it already has a built in
unique
identifying system of it's own (Autonumber). But for various reasons, we
have
elected to use our own 'code' to uniquely identify our records. The basic
breakdown of our code system is: Single letter representing the type of
entry
(eg "Q" for a quote) followed by the curent year in "yy" format (eg "10"
for
current entries) then a dash ("-") then a three digit number representing
the
individual record for that entry type and year. So for example, "J09-154"
would be the identifying value for the 154th Job that we did in the year
2009. This record would be located in my table named "Jobs" and the value
of
the [JobNumber] field in this record would be "J09-154".

So on my form named "JobEntry", the expression in the 'Default' property
of
my [JobNumber] field for new records would look like this = "J" &
Format(Date(),"yy") & "-" &
Format((Mid(DMax("[JobNumber]","[Jobs]"),5,3)+1),"000").

Now, if I have two users who were logged on to a TS RemoteApp session for
instance (or whatever other Terminal Services method we'd use) both with
this
Access Database open and they both started a new Quote at nearly the same
time (say within 2 minutes of eachother), given that the Quote form might
take 5 minutes to fill out and print to pdf, what you're saying is that my
two users could potentially create a quote each and send their quotes off
to
their prospective customers and had both used the same Quote Number that
was
automatically generated for them when they went to a new record on the
Quotes
form?


David W. Fenton" wrote:

=?Utf-8?B?Sm9uMjI=?= wrote in
:

Replication is out of the question. Too much of the data relies on
unique values that if doubled up would cause massive headaches at
the time of consolidating it all.

Er, that's a solved problem. It has to be, since replication is so
widespread.

It would require changing your database to account for it, but it's
completely solvable.

It will be an issue not matter what solution you choose if you're
providing disconnected editing of the data.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

uh, the extra overhead from maintaining, developing and administering
linked tables is just flat out unnecessary work

Access Data Projects allow you to keep all your information, queries
and logic - in one place - where it belongs - on a database server
(SQL Server 2005 is most likely candidate these days)




There is really nothing hard about managing a split app and it is
much, much safer and more reliable.


On Mar 2, 12:54*pm, "David W. Fenton"
wrote:
=?Utf-8?B?Q1c=?= wrote :

The whole setup works wonderfully for us and I often wonder why
one might need anything more sophisticated (= expensive and
time-consuming to learn and maintain).

The scenario you outline will not work in more than 1 out of 1000
cases. It is just wrong.

It's also much harder to update the application part of an unsplit
database, so it must be a pretty trivial app if that's working for
you.

There is really nothing hard about managing a split app and it is
much, much safer and more reliable. I've never once put an unsplit
app into production use with multiple users, and that includes the
very first one I ever did, back in 1996. I don't know exactly where
I got the information that I needed to split it, but that was the
way I designed the whole thing. This was back in the days of Access
2, Windows for Workgroups 3.1 and 10BaseT networking. I was blown
away by Access's ability to cache data (particular for a stupidly
designed combo box that had hundreds of records -- first time you
used it was slow, after that, totally fast).

It just doesn't seem like an issue to me.

--
David W. Fenton * * * * * * * * *http://www.dfenton.com/
usenet at dfenton dot com * *http://www.dfenton.com/DFA/

Larry;

The only reccomendation I've ever seen from MS says something about
'reccomending ADP for performance reasons.. ESPECIALLY FOR REPORTING'

So I don't have any clue WTF you're talking about, jackass!

-Aaron



On Mar 3, 11:43*pm, "Larry Linson" wrote:
"a a r o n . k e m p f @ g m a i l . c o m" wrote

* Go play with your deprecated baby sized jet databases, kid

Jet was never officially deprecated, but it didn't get a lot of attention
for a while. Then the product team gave it some attention, and improved it
along with creating a descendant (the ACE database engine) in Access 2007..
At about this time, they ceased recommending ADP as the preferred Access
front-end for SQL Server, and now recommend MDB with ODBC for that purpose.

Some people just can't seem to get the story right... either they are
ignorant or they choose to disseminate false information.

*Larry Linson
*Microsoft Office Access MVP

wtf are you babbling about you faggot?




On Mar 4, 11:03*am, "David W. Fenton"
wrote:
"a a r o n . k e m p f @ g m a i l . c o m"
wrote
:

Go play with your deprecated baby sized jet databases, kid

We will, we will.

But at least we actually know something about it that is factually
true. You promote SQL Server for everything, yet, you don't seem to
know the first thing about it given how often you post factually
challenged information.

(I know you're going to ask for examples, and I'll just say read the
followups to any post you make about SQL Server and you'll have your
answer)

--
David W. Fenton * * * * * * * * *http://www.dfenton.com/
usenet at dfenton dot com * *http://www.dfenton.com/DFA/

David;

you run around, claiming that jet replication is the only answer for
copying data back and forth over a wan.

you sit there and claim that SQL Server is _SOOOOO_ difficult to use.

but the FACTS state that using a single link, instead of 50 different
connection strings (one for each table? WTF?) is somehow less
efficient

You sit there and claim that copying tables, and copying queries and
refreshing links.. Is this somehow _FUN_ to you?

Access Development is much more fun if you just STFU, ignore the Jet
crybabies.. and use the most popular database engine in the world (SQL
Server)
Access Development is much more fun if you just STFU, ignore the Jet
crybabies.. and use the most popular database engine in the world (SQL
Server)
Access Development is much more fun if you just STFU, ignore the Jet
crybabies.. and use the most popular database engine in the world (SQL
Server)






On Mar 4, 11:08*am, "David W. Fenton"
wrote:
"Larry Linson" wrote :

Jet was never officially deprecated,

This is true and false. Many people point to some MSDN articles that
have the roadmap for MS's database technologies and it deprecates
Jet. But they fail to notice that the article was written to guide
developers transitioning from MS's old development tools (from the
VB6 era) to the .NET family of development tools. It's obvious that
one really oughtn't use Jet/ACE for .NET development (though perhaps
the 64-bit ACE will make that no longer a vulnerability), and that's
all the articles "deprecating" Jet were about. They were deprecating
Jet for a particular purpose, not for all uses.

The proof is in the pudding of course, with A2007 having shown that
MS has no intention whatsoever to deprecate or replace Jet at all.
Even if they are hoping that Sharepoint will take over all small
business usages, they still need Jet/ACE as local database engine
for managing disconnected data. But having it also brings with it
Jet's historical ability to work with the widest variety of data
sources of any database tool out there. And do it well, with good
default performance and a host of tools to make it easy.

but it didn't get a lot of attention
for a while. Then the product team gave it some attention, and
improved it along with creating a descendant (the ACE database
engine) in Access 2007. At about this time, they ceased
recommending ADP as the preferred Access front-end for SQL Server,
and now recommend MDB with ODBC for that purpose.

It will be interesting to see what comes of the current efforts to
work with SQL Server developers to make the version of Access after
2010 more versatile and SQL Server-friendly.

Some people just can't seem to get the story right... either they
are ignorant or they choose to disseminate false information.

I can't quite understand Aaron's actions as anything but those of a
person who is at some level mentally disturbed. But I am not a
doctor, so I could be wrong on that.

--
David W. Fenton * * * * * * * * *http://www.dfenton.com/
usenet at dfenton dot com * *http://www.dfenton.com/DFA/

!l

"Jon22" a écrit dans le message de groupe
de discussion : ...
Thanks David, they sound like convincing enough arguments to me. I have
spent
way too many hours on this Access database to go back and rewrite
anything.

Can you clear something up for me though. Is Windows Terminal Services
exactly the same thing as Remote Desktop? Or is it a platform that allows
multiple simultaneous Remote Desktop connections or something?

The reason I ask is, I regularly use Remote Desktop to access/connect to
my
workstation at the office from my notebook at home and I have to say, I
find
it great for some things but not so great for others. The concept is
brilliant but I don't like the way the interface looks through this
connection or how it reacts to commands. Everything looks pixelated and
runs
'jumpy' and not very responsively.

So with WTS would the staff be just remotely opening the desktops of their
computers on our office network and then opening the Access database from
there? Or is it something closer to a copy of the Front end being on their
remote computers and the back end being on our office network and the two
talk to eachother via WTS?

One other thing, the firewall settings on our 2701HGV-W Gateway modem only
allows one instance of Remote Desktop to be used at a time between all the
computers on the network (although this is a relatively small issue in the
scheme of things).


"David W. Fenton" wrote:

=?Utf-8?B?Sm9uMjI=?= wrote in
:

I think I am going to persevere with trying to get my
head around SQL server.

I think this is a mistake. Writing an Access app to run on SQL
Server across the Internet means you have to really understand how
to design and maintain server-side components (view and stored
procedures) and then you have to carefully design your app to use
those server-side objects, and you may have to jump through certain
hoops (such as using ADO to get editable results from sprocs) that
are not compatible with default Access behaviors/designs.

Also, you'd have to set up a VPN (assuming you're not silly enough
to just expose your SQL Server port directly to the wide-open
Internet). If you've got a server to run SQL Server, you've got a
server that can run Windows Terminal Server. Since you'd have the
VPN anyway, the only step to use WTS would be to acquire the CALs to
allow users to connect to run their Remote Desktop Sessions, and
then the basic setup of the terminal server for your application
(giving each user an individual copy of the front end, automating
updates, etc.).

And WTS requires NO ALTERATIONS to your application, and no learning
curve. Going with SQL Server to support remote access has a very
high learning curve, and would require substantial alteration to
most Access apps designed to run with a Jet/ACE back end (or even
most designed to use SQL Server on a local LAN).

There really is no comparison in regard to the cost and difficulty
level.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

I should probably point out that the way that jet or ace works in the
above statement is exactly the same.

JET does not have the concept of trusted locations.
ACE does not have the concept of MDW security.


You should probably add to this that you're talking about a accDB file.
ACE still fully supports the jet workgroup security model if you open
an older mdb file format.

But then it's not ACE is it. It's JET.

(david)

"Albert D. Kallal" wrote in message
...
"david" wrote in message
...


ACE uses Windows security instead of Jet Workgroup
security, which is good, because Jet Workgroup security
is very old, not properly implemented, and has never been
updated.


I should probably point out that the way that jet or ace works in the
above statement is exactly the same.

But ACE as written can't do table level security.

You should probably add to this that you're talking about a accDB file.
ACE still fully supports the jet workgroup security model if you open an
older mdb file format.

I guess the main point at the end of the day here is there is not some
special consideration or modifications in ACE as compared to JET in how
JET deals with and works with and interacts with the built in window
security model and file system.

The only real change here is that were being encouraged not to use the jet
workgroup security model with ACE. However, ACE still does fully support
workgroup security.

It's somewhat misleading to state that is ACE can't do table-level
security, because ACE still does support jet workgroup security.

And to be 100% fair, I don't believe you ever made the claim that somehow
ACE works with, or interacts any differently than that of when JET opens
that plane jane windows file.

To my knowledge, both jet and ace open and work with those window files
exactly the same way.

So, ACE does in fact have the JET workgroup code base and does in fact
support jet workgroup security.

Perhaps the biggest news here is that the reason why ACE (jet) is being
extended now is because the Access team now owns the jet code base. Prior
to access 2007, the access team really could not make modifications to
JET, or now what we refer to as the ACE engine.

For Access 2010, that ACE engine now has stored procedures and table-level
triggers. So no matter how we slice and dice this the mere fact of the
Access team gaining ownership of jet is rewarding us with all kinds of new
features. Those feature range from the new cool offline disconnected mode
when working with SharePoint, or stored procedures and triggers at the
table-level.

And wonders of wonders, it also means that we get a 64 bit version of our
lovable jet engine due to office 2010 having a 64 bit version of VBA
available.


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

It's an interesting concept, to be sure, but if I haven't
misunderstood david's point, it doesn't really serve :-)
to limn the difference


The idea that you can adequately describe a concept
by definining it's differences from a familiar concept is
a beginners mistake in teaching and training.

More fundamentally, the idea that you can teach a
concept by replicating the way an experienced person,
who understands the concepts, thinks about the concepts,
is a beginners mistake in teaching and training.

So, I was never trying to explain the differences between
SQL Server and the service derived from SHARE.EXE.

I was trying to explain what they had in common, for a
person who had described himself as 'daunted by SQL
Server'


The rest of it was trying to help people who were putting up
misleading information about 'opening ports' and 'services'
and stuff like that. Those mistakes always lead to
misunderstandings further down the line.

(david)


"James A. Fortune" wrote in message
...
"Cargo Culture" Banana (Republic) wrote:
david wrote:
Banana,

Access/Jet is built on top of the Windows Database primatives.

But what exactly is a 'Windows Database primitives'? I've googled this
phrase and didn't find anything useful. I'd like to know what you mean
by that phrase.

You clearly and carefully presented your case that the DLL's used for
data access in Access are file based. I agree. david, in mentioning
native windows database primatives, seems to suggest that because the
files themselves are served (via SMB), there is some similarity to how
the information contained in a SQL Server file is served. It's an
interesting concept, to be sure, but if I haven't misunderstood
david's point, it doesn't really serve :-) to limn the difference
between the two data access methods. The DLL's used by Access are
still file-based, as we understand the term. The SQL Server service
is still Client/Server, as we understand the term.

James A. Fortune