Might be outgrowing Access but daunted by SQL Server

I've been looking up Windows Terminal Server and related subjects. We do not
have at this point in time a stand alone server computer. Is Terminal Server
a type of system software? Should I be considering buying a new computer to
act as our server which would run this software?

"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/
.

"Jon22" wrote in message
...


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?

No they are not the exactly the same thing. Windows terminal services uses
what is called the remote desktop protocol to send mouse clicks and little
text boxes down to the client. However the term window terminal services
generally means you're using remote desktop. Perhaps more specific is a
windows terminal server is something that creates multiple desktops that
people can remote into.

I mean if you have one computer and one desktop, and 10 people connect to
it, they would normally all see the same desktop (I think it's quite obvious
that that kind of setup is not going to be very useful).

Windows terminal services, or what is normally referred to a terminal server
is simply a good powerful server that setup and it allows multiple copies of
windows and allows one to have multiple users each with their own desktop
separate from each other running all at the same time on the ONE box. In a
sense you can think of windows terminal server as almost like a web server
that allows people to view all these pages being dished out, but in place of
dishing a web pages, it's dishing out windows desktop to each user.

What this means is that in terminal services, you're are connecting to a
computer box that's running windows in a way that allows each user to have
their own desktop. The beauty of this system means it doesn't matter what OS
or how crap of a computer you are running to CONNECT to this box. In some
cases some companies actually use this because then they can go to a
computer junkyard and pick up the cheapest worst pieces of junk desktop
computers. They then by ONE nice server in which they install windows 7,
office 2007 and all latest software. What this means is that each of the
client computers only need to connect to this remote desktop. Any additional
maintenance, setup of software, adding hardware, fixing problems are now
done on ONLY ONE box.

The type of and condition of the client computers don't matter. Heck you can
even use Macintoshes if you want. So using window terminal services is well
liked by some companies because they never have to upgrade any of the old
client computers sitting around in the office. Some companies are still
running old computers with windows 98 as cleints. These boxes are free at
your local computer junkyard. So, 64 megs of ram is planning for this
system, whereas the typical computer today is shipping with 4 gigs of ram.
So some companies actually adopt remote desktop and windows terminal
services even for all users (not just remote ones). They do this because it
means then they never have to upgrade any of their cheap crap computers in
the office anymore. And when they have to upgrade to the next version of
officer something, they never have to install any upgrades are software on
any of the client computers. Another significant advantage is that any user
can work in any desktop anywhere in the company, and instantly be using the
same desktop they've used for years, and if they work at home when they
remote in, again they get the exact same desktop. So, they can work on any
computer, remote into the termal server, and presto, they have their same
experience and the same desktop they use every day. Because all processing
ran and software is managed and run on that terminal server, then it's not
significant or relevant as to what kind of client computer you have. You can
have a client piece of junk computer, but install the latest windows 7 and
office 2010 on the terminal server if you want. So you get a great
centralized management of all software, and the client hardware computers
don't matter anymore.

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.

Well there's probably 15 to 20 different remote desktop systems available in
the marketplace, and you even see products like "goto my pc" heavily
advertised on TV and in magazines.

However, if you are in fact using the remote windows desktop, then the
pixelation is a function of what resolution and setup you're using for the
remote system. You should get at least as smooth as experience, and even
some what smoother than that of say using a web browser and web based
application. And, web applications are generally nowhere near as rich and
functional as a typical windows desktop application. Of any remote
technology I've used, the remote desktop protocol, and connecting to windows
terminal server cans to give about the best remote experience possible, and
with any high speed Internet connection, use to get a windows like
experience with little difference then running everything on your local
computer.

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?

That is correct. As mentioned you don't actually have to have 10 computers
sitting unused physically sitting in the office. A windows terminal server
allows you to create as many users as you want each with their own copy of
windows and a separate desktop on that one computer (that one computer is
typically referred to as the window's terminal server). So for each
additional user you add to that box, you don't have to install setup and
purchase a whole new computer. However, if each existing user already has a
working "physical" computer at work, then remote into that box would be a
solution (and you are hinting and suggesting that you're capable of remoting
in this way now).

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?


No, it is a true windows remote system. Nothing is placed or installed on
the client computer. The only thing you need on the client computer is the
software or program that allows you to connect to the terminal services, and
that's called the remote desktop client. In fact for Windows XP, and
certainly any editions later the so called remote desktop client is pre
installed (built) into windows. This fact only saves you having to install
some software on each person's computer that would allow you to connect to
windows terminal server. This client "system" uses what is called RDP
(remote desktop protocol). There are many different remote desktop systems
in the marketplace. RDP is particularly efficient, and well suited to lower
bandwidths as it tends to only send mouse clicks, characters (text) and only
part of the screen that changes. There are also free products the
marketplace that don't have the windows terminal server part, don't use RDP
but allow remoting into a desktop. VNC, or ultra VNC is such an example.
Perhaps you using VNC? And, don't confuse VNC with a VPN (virtual private
network).

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

That makes sense ONLY in the case to allow one to tunnel into ONE particular
desktop box within your Office Network. If you take (setup) a server and
install and set up windows terminal services, then you only in theory
connecting to one computer in the office again, but that computer is capable
of vitalizing and dishing out multiple instances of desktops to multiple
users. It would be like saying that your system only allows everyone to
connect to one server, but that server has your files on it. So this might
be a limitation of your gateway modem, but it's really not a issue or
problem because you're using all the resources to go through one particular
"port" to connect to one particular computer. It's just that the particular
computer you're connecting to is not some type of SQL server, or in this
case a windows terminal services server that is set up to dish out multiple
desktops. So even when using windows terminal server you're only connecting
to the one box, but the one box a capable of servicing many people. In a
nutshell this limitation likely would not be significant if you're using
windows terminal server.

It is perhaps also interesting to point out that the remote desktop system
that you see built into windows also is based on and uses the remote desktop
protocol. So as a trial run, if you are in fact using remote desktop and
the issues of resolution and mouse clicks is a problem, then this is a
great way to give you an idea of the type of experience users will receive
when using windows terminal services. You should be able to crank up the
resolution, and fix those pixliation issues. Keep in mind that remote
desktop is not great for graphic intensive applications as that requires too
much network bandwidth. So if you after reading the above decided to dump
all your desktops or use crap computers, and centralize all of you software
and support services into one box, it would not work well for an
organization that's doing computer drafting or cad type graphics intensive
applications. On the other hand if it's just some data entry into some
forms for typical access application that's not graphically rich, then many
companies will actually make the decision to centralize all their software
support and services into one box.

However, in your case you would not be using windows terminal services to
replace all your desktops, but only to allow remote access to a particular
application. However, WTS still implieds that each user logging into the
terminal server will have their own separate desktop. I should point out
that windows terminal services also does have setup options that allow when
the user connects to one of those desktops, that an application (such as
your access application) can automatically run when you connect. So, it is
not necessarily that each user actually have to see that separate desktop,
but conceptually they all still have their own desktops when using a windows
terminal server.


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

"Jon22" wrote in message
...
I've been looking up Windows Terminal Server and related subjects. We do
not
have at this point in time a stand alone server computer. Is Terminal
Server
a type of system software? Should I be considering buying a new computer
to
act as our server which would run this software?


That is a correct assumption. All of the later editions of the so called
server editions of windows, such as windows server 2003, or windows server
2008 all allow windows terminal services to be installed and setup and run
as a service. In fact, as far as I know, windows terminal services is
already preinstalled on later server editions of windows servers. In the
past you had to install and set up this WTS software. So, from a conceptual
point of view, it's not a whole lot different than dedicating a server, and
installing SQL server services on that server. So, the only real difference
here is, that windows terminal services is preinstalled on most server
additions.

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

"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

"Albert D. Kallal" wrote in
:

"David W. Fenton" wrote in message
There really is no comparison in regard to the cost and
difficulty level.

Cost for me using sql server is less.

Less than for someone who hasn't topped the SQL Server learning
curve, yes, but certainly not less than hosting the app on WTS. Even
though you've got good SQL Server chops, it still takes more time to
port the app to SQL Server and re-design it to be efficient enough
to run across a WAN. That's not a trivial amount of time even for
the experienced developer like you who has done it before and knows
how to run SQL Server and how to interact with it efficiently in
Access. And then there's all the potential for bugs and the like
that come from rewriting code and redesigning forms/reports, and it
seems that WTS wins hands down.

It's not even close, even for the person like you with all the
necessary experience/knowledge to go either way.

Of course, this is all assuming an existing Access application. If
it's a new app, and the user population, security, reliability and
other requirements are suited to Jet/ACE for the back end, I think
Access/Jet/ACE + WTS wins for new development, too (as compared to
architecting the Access app to run across a WAN with SQL Server).
But there, at least, it's a closer issue.

I have many successful applications
running over the Internet using SQL server. However, I done the
learning curve. We don't even used stored procedures.

Certain kind of operations are going to need it, I think.

We use some pass-through,

How do parameters work with pass-throughs? That's the reason I've
used sprocs in the past, because I needed to pass parameters that
weren't available via WHERE clauses.

and
mostly link to views for joins on reports or pick lists. I can
zero in and get a access application up and running for SQL server
in a WAN environment in VERY little time now. I am also using a
hosted option for sql server. And, sql Azure can be had for $10 a
month for a 1 gig database. I believe the trials are on now, and I
can't wait to try Azure.

However, WTS vs SQL server in BOTH cases, a server + VPN must be
setup.

I have argued this for years, but some people (like Lyle) have
repeatedly argued that it's safe to expose your SQL Server to the
public Internet. Others have exposed their RDP port to the open
Internet, which is even more inadvisable (since if breached, would
open the WTS to a much wider spectrum of potential risks than is the
case with a breached SQL Server).

WTS really is far less learning overall.

Learning? There's learning involved? I guess there is from the
standpoint of the person who sets it up and administers it, but for
an experienced Windows sysadmin, that's a remarkably trivial amount
to learn.

And, one does NOT spend money
modifying an already good working access application.

....so you avoid introducing bugs or changed behaviors. The amount of
testing needed for hosting an existing Access app on WTS is really
small in comparison to any other options, seems to me.

So, the larger and more complex the access application, the the
more work needed for SQL server. This thus again favors he WTS
choice.

Exactly. I just don't see any scenario where if WTS is an option
that SQL Server over a WAN is better. Even where WTS is not an
option, I'd expect SQL Server to also not be an option, so that WTS
wins again.

Can you tell I'm a big WTS fan?

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

"Albert D. Kallal" wrote in
:

There are many different remote desktop systems
in the marketplace. RDP is particularly efficient, and well suited
to lower bandwidths as it tends to only send mouse clicks,
characters (text) and only part of the screen that changes.

The real reason this is efficient is because it sends all this
information in the same encoding that is used by the components of
Windows, using the native graphics primitives that are used to
communicate between the Windows graphics subsystem and the hardware.
Thus, the native Windows calls are sent from the remote Terminal
Server to your own local computer, and then translated into the
exact commands necessary to tell your computer's graphics card how
to paint the screen.

Programs like VNC, which I use all the time, BTW, send bitmaps. It's
like the difference between scalable fonts and bitmapped fonts in
terms of the amount of data sent. A scalable font sends the font
definition once (which is a series of mathematically described
curves) and to render any particular font, the point size and weight
and so forth are sent. With bitmapped output, every single pixel's
position and color has to be sent.

The result is that remote sessions via Remote Desktop Protocol with
compatible hardware use very little bandwidth and are even usable
over a 28.8 dialup connection (though usually with reduced color
depth and resolution to gain some speed). It's not great, but it's
acceptable when that's the best possible connection. With anything
approaching even American DSL seeds (300Mbps and above), it's very
little different than running locally, except when Internet
congestion gets in the way (which happens a lot less than you'd
expect with any reasonably reliable broadband connection).

It *is* necessary that the Terminal Server itself be connected to a
broadband connection that is sufficient to support the number of
simultaneous users, but I've found that even this is not as taxing
as you'd expect, since users are not updating the screen all the
time, so they don't need full bandwidth all the time. That is, if it
takes 300Mbps to update the screen reasonably responsively, the user
only needs that every few seconds. In between, other users can be
serviced at full bandwidth. Thus, I always allocate bandwidth at
about 128Mbps per simultaneous user, which I've found to be more
than enough to give all users nice snappy response.

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

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.

Jet builds it's own locking and Workgroup security on
top of the Windows Services. Workgroup security,
because Jet pre-dates Windows security. Locking,
because without Windows Security, Jet needed to build
it's own lock database to be able to report who had
a record locked.

Just to check my comprehension he

By 'Windows service', we're referring to file sharing.
By 'Windows security', we're referring to filesystem permissions.
By 'Jet Workgroup security', we're referring to User-Level Security.

If that is correct, then:

I agree that JET/ACE depends on Windows service for locking the .ldb
file. Heck, it has to for all other file operations. No different from
any other applications, really.

However, I am not sure that ULS does builds on Windows Service - it's a
part of JET/ACE design and merely restrict access to various objects
within the file within JET/ACE's context. It simply doesn't function
outside that context (e.g. open that same file in a hex editor and
there's no object-level security anymore).

So the Jet/MDB locking is done by locking records in
the lock file, rather than by locking records in the data
file. The locking of records in the lock file is done by
using Windows Record locking.

Agreed.

Windows has a mechanisim for reading/writing/locking
records. Jet uses this to get what are sometimes called
'physical records' from the database. On old IDE drives,
physical records are disc sectors, not even disk clusters,
and certainly not what is returned by a record request,
so that nomenclenture is not correct, but if the OS was
integrated with the File System and the Disk Controller,
as they were in old OS's, then the OS database primatives
would return 'physical records'.

FWIW, I'd think we've long ago moved from needing to concern ourselves
with such low-level details such as clusters, sectors and tracks of the
hard drive. I believe JET/ACE deals with the file in terms of pages
rather than sectors, and pages are always a fixed size.

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.

But ACE as written can't do table level security. ACE
needs Windows record-level security to implement ACE
table-level security. Windows security doesn't have record-
-level security, and Windows table-level security was
based on a different model. So ACE will get table-level
security if ACE is completely re-written, or if Windows
adds record-level security.

To be honest, that part was confusing to me until Albert posted his
reply which made a bit sense out of this.

If we're still on 'Windows security' = 'filesystem permissions', then I
should point out that I think we're talking about two different security
models. ULS works at object level while filesystem permissions works on
file level. Filesystem permissions cannot be used to manage objects
within the file so I think this is a case of comparing oranges to
apples, and to be sure, they weren't mutually exclusive. We could use
_both_ filesystem permissions and ULS to secure the same file (and
subsequently the objects within the file). (keeping in mind Albert's
clarification that both JET and ACE are capable of using ULS - it is a
question of whether we use the .mdb format or .accdb format rather than
whether we use JET or ACE)

I'm also aware of 'Windows Record Locking', which basically operates on
a file based on a byte offset. However you mentioned 'Windows
table-level security', which a google turned empty. Could you clarify
what you mean by 'Windows table-level security', please? Otherwise, I
think that if the point is that filesystem permissions does not work
below the file level (e.g. Windows record level), then we're in agreement.

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

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?

Albert has explained all of this, but it's important to realize that
Terminal Server predates Remote Desktop. Back in the NT 4 Server
days, the Terminal Server version of Windows Server was a separate
product, and cost more money and licensing was very expensive. It
was also really primitive unless you used Citrix's add-ons to it.

Microsoft licensed Citrix's technology for inclusion in Windows
Server 2000, and from then on all Windows Server versions include
WTS support (by default, there are two sessions available, but only
to users who are administrators). If you install client-access
licenses (CALs) on the Terminal Server, remote machines can connect.
In order to run software in their terminal server session, though,
they have to have the appropriate licenses on their local desktop.
Any user with Office installed on the local desktop will be granted
permission to run Office apps on the Terminal Server.

Now, originally the terms under which all that happened were quite
friendly and loose -- you didn't need the exact same version (you
could have Access 2000 and run Access 2003 in your terminal
session), but with Office 2007, this has become much stricter. You
now really do need the matching version of Office and the exact same
app (for instance, having Office 2007 Standard installed locally
doesn't allow you to run Access 2007 remotely). Also, the
requirements for the server have been changed -- it must be Windows
Enterprise Server in order to provide remote users the opportunity
to run Office 2007 applications.

If you stick with Access 2003, you can use any version of Windows
Server except Small Business, and as long as your users have a
version of Office from 2000 on installed, they'll be able to use it.

Now, the Remote Desktop you're familiar with is based on the exact
same technology, and was introduced in Windows XP. However, it has
the restriction that only one user at a time can connect, and it can
only have one session at a time. It doesn't allow multiple sessions
as is the case on a Windows Terminal Server. But the underlying
technology that enables the remote control of the PC on the other
end is exactly the same, i.e., RDP, or Remote Desktop Protocol.
That's why the Remote Desktop client can be used to connect to a
workstation and to a Terminal Server, because the protocal is
identical. The only difference is how things are handled on the
remote machine, which is dependent entirely on what version of
Windows it is and what's installed in terms of licenses.

There are 3rd-party products like Winconnect (Google it to find out
more) that also use RDP. Citrix provides GoToMyPC using the
technology, as do LogMeIn.com and any number of other remote access
solutions. Winconnect is different in that they have a server
version that can be installed on a desktop and allow multiple users
to connect. I haven't used it but others I respect have said it's
quite a good product. If I had a small client who needed remote
access to support a couple of remote users and didn't have a Windows
server, I'd definitely consider Winconnect.

[]

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

It's likely not a limitation of the firewall, but of the
configuration it's running in. Most firewall/routers have port
forwarding such that the administrator maps a port to a particular
application and destination computer. All remote control
applications have a default port (VNC's is 5900, for instance), and
if you want to support more than one computer, you usually configure
more than one port so that the user requests a connection to a
particular computer by using the port number allocated to that
destination PC.

With Windows Terminal Server, there's one port that serves everyone.
I wouldn't recommend having a port open through the firewall (the
scenario you describe in your office is not one I'd recommend
either), but instead set up a VPN for all purposes, so only one port
is open for all applications and uses by remote users. They connect
to the VPN, authorize against your domain controller (or whatever is
used for VPN authorization) and then have access to the resources on
the internal network similar to the way they do in the office
itself. Thus, there's nothing opened up to the Internet except the
VPN port, which is usually a much stronger "lock on the door" than
any of the alternatives, since individual keys and encryption
settings can be required for users to be able to log on (i.e., it's
insufficient to just provide a valid username/password -- you have
to submit appropriate credentials beyond that).

I think that addresses all the things that Albert left out of his
very complete answer.

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

"Albert D. Kallal" wrote in
news

"Jon22" wrote in message
...
I've been looking up Windows Terminal Server and related
subjects. We do not
have at this point in time a stand alone server computer. Is
Terminal Server
a type of system software? Should I be considering buying a new
computer to
act as our server which would run this software?


That is a correct assumption. All of the later editions of the so
called server editions of windows, such as windows server 2003, or
windows server 2008 all allow windows terminal services to be
installed and setup and run as a service. In fact, as far as I
know, windows terminal services is already preinstalled on later
server editions of windows servers. In the past you had to install
and set up this WTS software.

This is not really correct. There was never a version of Windows
Terminal Server where you could add it on. In NT 4, it was a
separate version of Windows, and you had to re-install it. Starting
with Windows 2000 Server, it was included in the OS itself, with two
administrator-level logons pre-authorized. To have more than two
simultaneous users (and users not running as administrators, which
would be unwise for regular users!), you have to purchase
Client-Access licenses, which are about $40 each last I checked.

That doesn't provide the licenses to run Office apps, just the
permission to connect to the Terminal Server and run apps for which
you have the licenses. If you have Office 2000 to 2003, you can
usually run any Office 2000-2003 app on Terminal Server. Starting
with Office 2007, this is more strict -- you have to have the
particular app installed and it has to be version 2007 (though I'd
expect it to be downard-compatible, i.e., if you have Access 2007,
you can run Access 2003 on the Terminal Server). Also, certain
versions of Windows Server don't allow anything other than the two
administrative Terminal Server sessions. This would include all
versions of the Small Business Edition of Windows Server, and
running Office 2007 (and I'd presume 2010 when it comes out) on the
Terminal Server, you have to be running Enterprise Server.

As an alternative if you really only need to support a couple of
remote users and don't have a Windows Server (and can't justify the
expsenss) you might look into Winconnect (google it), which allows
you to use a regular desktop PC as your server (though you'd want
that to be a dedicated machine). I don't know how close the
performance is to Terminal Services running on a Windows Server, but
I've heard from reliable sources that it's pretty good. If a client
of mine needed a couple of remote users and had no server, that's
exactly where I'd start.

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

Banana Banana@Republic wrote in news:4B893809.3070701@Republic:

David W. Fenton wrote:
But if you're contemplating allowing disconnected use, you'll
need the SQL Server running on the laptops and you'll probably
need to implement SQL Server replication in order to keep the
laptop databases synchronized with the central one. Replication
is not a minor issue, and if you can avoid it, you really should.

If OP wanted to use the application in disconnected state, I would
really not want to entertain the idea of running SQL Server
Express on every client machine. That would be too much
administration and training.

I'd daresay it'd be easier to just use Access local tables and
write scripts to synchronize when the laptop comes home. I also
understand that SQL Server supports replication with linked
server, but I'm not sure how well SQL Server handles synchronizing
with non-SQL Server sources or whether it'll be practical in this
use, though.

I didn't know about the linked server thing. I do know that SQL
Server 2000 supported heterogeneous replication with Jet 4, which
allowed a Jet 4 user to be a subscriber to a replicated SQL Server
database. They dropped that with SQL Server 2005, but I wonder if
the linked server solution would enable it (so that you'd be running
SQL Server on the remote laptop only in order to do the
synchronization of the MDB linked "server").

I agree that replication is difficult no matter how you set it up.

Sharepoint is the future for that, both because it's easier and
because it's the platform MS is putting its resources into to
support disconnected editing.

In general, backing up the live SQL Server files is not going to
give you a reliable backup. It's just like backing up an
MDB/ACCDB that is open by a user -- you may or may not get a
valid file out of it (it's probably even less likely with the SQL
Server files, I would think). SQL Server has a backup agent to
take care of backups for you, but one of the disadvantages of SQL
Server Express 2008 is that the backup agent is not included!
Some backup software is able to talk directly to the SQL Server
and get a backup file, but if that is dependent on the agent, it
won't work with SQL Server Express.

That's why I had qualified my statement as "even then that is not
strictly necessary." Perhaps I should have had used "is not
actually necessary", because in most practical backup usage, we'd
be dealing with .bak files, not .mdf or .ldf files.

FWIW, when I'm responsible, I include the MDF/LDF files in the file
backup in addition to running the SQL Server agent to do its thing.
Multiple levels of redundancy are a requirement when it comes to
backups, because the danger is that multiple backups will fail
simultaneously. I've seen it happen so often that I just don't set
up a single level of backup for anyone.

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