"philr" wrote in message
...
I went to my local Barnes & Noble to look up more information on using
Terminal Services with SQL Server. A look through the index of the books
available didn't mention TS. Is there another keyword or term or a
recommend
book that can teach me this rdbms distribution method? Other resources?
Well, TS is a basic system that runs on windows 2000 server. So, it is not
specific to sql server, or any particular software application for that
matter. So, just like we can't find a book on using terminal services and
ms-word, I doubt you will find one for TS + sql server. So, you will not
find a book specific to "one" particular application when using TS. So, TS
works with virally ANY software you can run on the desktop. I doubt you will
find a book on using word, and TS. However, you most certainly should be
able to find a book on terminal services. (some books that cover
administration of windows 2000, or 2003 server likely would cover TS). I
mean, you can use windows 2000 as a domain server (that simply means that
all computers logging on to the network get ALL OF their security from
windows 2000 server). If your domain server goes down, and NO one can
actually log on to their computers! My point here is that domain servers are
big part of the windows server system, but I don't think you will find a
book JUST on domain servers for windows - well, ok...probably on Amazon you
can, but I think you see my point here).
The home page for TS is he
http://www.microsoft.com/windows2000...l/default.mspx
So, from the above, you can find white papers, links to articles, and even
newsgroups....
If I use Access ADP with SQL Server do I lose any query capabilities? The
book I'm reading covers Jet SQL but, under ADP, queries apparently turn
into
the da Vinci toolset. During ADP development does Access handle these
query
differences behind the scenes so I don't need to think much about the
differences or do I need to find another reference to understand the
differences?
Hum, well, you do loose the ability to use VBA in sql expressions. That is
about the largest change. Otherwise, not much difference here. The general
approach to build the queries will be much the same as you have now.
Perhaps the largest difference is that you can NOT using VBA expressions in
the sql when you use a adp (this is because he query runs native on the sql
server, and thus no VBA expressions can be executed). When you use a mdb,
then you can write public functions, and they can be used in sql
expressions. And, about the only other issue here is that a saved regular
select query a mdb application is a "view" in sql server. So, I can't say
that a ADP handles the queries differently, but some functions, and
expression will be slightly different. The overall process of building a
query remains the same, and the query builder will result in a some sql.
IOW, does Access create the T-Sql for automatically?
No, ms-access does not create the t-sql (but, why would it?). You certainly
can however write stored procedures in t-sql, but that assumes you now have
spent the time to learn t-sql. (so, sure, you can write t-sql procedures)
From an experience POV, how would I best set up my hard drive to segregate
files for this development?
Hum, I don't have any specify tips. I guess the issue is that you would
likely run a local copy of sql server for testing, and development. Before
you deploy, you would change the connection. You would have to deal with
things like adding a new table to your test database, and then remembering
to "copy", or create the same table on the production database (but, always
had to deal with this in a split system anyway). Sql server is better, in
that you can generate DDL scripts to create the table on a different
machine. On the other hand, exporting, and import would be possible, since
you have a connection to both sql servers (you local development one, and
the production one at work - got quite a few options, and even bulk copy can
be used with the sql admin tools).
If I deliver the BE and FE in encrypted format do I have to re-encrypt
with
each deployment?
We need to clarify what you mean by encrypted. I as a general rule do NOT
encrypt the mde (FE), as then it will not zip, or compress. However, if you
mean do you compile the mdb to a mde each time? Well, yes, of couse you
re-compile each time as that is the ONLY way to make a mde. You can't make a
new mde (or ade) without re-compiling the applcation. (again, this comes
down to you having worked with a split system for a awhile....if you have
not, then kind need t start doing this, you have to learn to walk before you
run).
Do I need to just encrypt the BE data?
Assuming the data will reside on sql server, then no encryption is needed.
It is assumed that users will NOT have permission to where the back end
files are located. However, users will most certainly have permissions to
the sql server. What you let them see, and use will be up to you (you could
always do that in ms-access anyway). I mean, the general rule is that if
users can see the data..then they can take it....right? (what stops you from
cutting and pasting data from the internet movie database?). So, the data on
sql server is not encrypted in anyway. The only difference between a backed
that is a mdb file, and backend that is sql server, is that with sql server,
you can REMOVE permissions to the directory where the files are from users
(so, sql server lets you hide where the actual data files are, and users
never get to see that directory). However, users will STILL need some
permissions to the tables and data used on sql server. (if they don't have
permissions, then how can they use the data!!). Don't confuse database
permissions with that of how you design your software, and what you let
users see, or not see (they are similar, but different issues).
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
http://www.members.shaw.ca/AlbertKallal