Salad wrote:
IINM, FoxPro's database engine is also file-based just as Jet/ACE
(although like Jet/ACE, it can work with external sources as well).
Other examples would be SQLite and SQL Server Compact Edition. What it
means is that there are no daemons involved. You open a file directly
and interact with it, perhap sharing it with others at same time. In
case of server-based RDBMS, the daemon has the exclusive access to the
data files and you communicate with the daemon and if you have the
permission, daemon will provide you the data and perform any updates on
your behalf (again, assuming you have the permission). With file-based
database engine, they're just a library that runs in-process with the
given application and locally on the client machine, managing the data
file directly _as_ you and not as a daemon (e.g. as if you were opening
it in Word and editing it).

If they were wanting to replace traditional client/server application
with Sharepoint... I would think that would be a bad decision and a lot
of people will be mightily inconvenienced.

Web or no web, security is needed in all contexts, and this is not the
case here.

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:iLydnYkQbPgRZu_WnZ2dnUVZ_gOdnZ2d (AT) earthlink (DOT) com:

Ya think?

Geez, I would have thought that was completely obvious with A2007
already:

1. eliminate replication from ACCDB format -> MS solution: use
Sharepoint for synchronizing data

2. eliminate ULS in ACCDB format -> use SQL Server or Sharepoint

3. add new data types, multi-value fields, attachment fields ->
makes things compatible with Sharepoint

Notice a pattern there?

Then look at all the new things in A2010, even the ones that are
present in plain old Access without any Sharepoint involved, and
nearly everything new is motivated by integration with Sharepoint.
In A2010, at least, some of those new features (like the great data
macros) are really useful for apps that don't use Sharepoint. Most
of the rest of them, not so much.

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

Banana <Banana (AT) Republic (DOT) com> wrote in
news:4B72F917.3080603 (AT) Republic (DOT) com:

I think it would be relatively trivial to decompile an MDE that
isn't encrypted (and password-protected) to figure out what your
encryption code actually does.

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

David W. Fenton wrote:
My understanding is to the contrary. It was mentioned to me by a
non-Access programmer that it would be more difficult to decompile a MDE
compared to an executable (whether compiled to machine code or to
intermediate bytecode). There's plenty of decompilers out there for
C-family languages & Java & .NET languages and even for Visual Basic.
However, good luck finding a MDE decompiler to download & run with few
clicks. Heck, none of those beforementioned decompiler are click'n'run.

Here's a thread where Wayne Phillips, the guy who runs
EverythingAccess.com and offer MDE to MDB conversion service agrees with
this assertion:

http://www.utteraccess.com/forums/sh...Number=1877894

Of course, if one is so worried about the possibility of someone
decompiling, they could get Wayne's utility to strip out the symbols as
well, but we should do very well to remember that the skill required to
successfully decompile a program (whether it's an executable or a MDE
file) would be very high and most likely out of reach for vast majority
of users, even those who are otherwise fluent developers.

Also, if we're at the point of being sufficiently concerned about
someone decompiling the program in order to extract the algorithm for
salting & hashing, then we're most likely way past the point of Access
being the right tool for the job, IMHO.

I'd actually be more concerned about malware running in the background
logging the keystrokes or tracking the memory heap at this point as it's
far more trivial to write a malware to log the keystrokes or dump the
heap than it is to decompile any program. But that's not my job anymore
- that's IT's job to properly secure the computer and prevent malware
from being present and thus compromising all otherwise well-secured
applications, including mine.