Now what? How to deploy?

[radink]

Well, I've got my DB ready to go. Now what?

I need to host it on our Win2003 server. How do clients use it?

I think im getting more confused as I try to figure this out. We are a
small company and I just want to be able to have everyone here use the
database at the same time without too much fuss. Do I just have to have
access on each machine and let them open it from the server, or is
there more to it than that? I just don't want them to be able to get
into the DB itself and modify things, just add entries and pull up
reports.

Thanks!

[Tim Marshall]

radink wrote:

Well, I've got my DB ready to go. Now what?

Hi there. Not rying to be mean, but based on the rest of your post,
your application is *NOT* quite ready to go yet.

To deploy you application in the environment you've described (network
environment) what is necessary is to have it set up like this:

1) The server has the "back end", ie, an mdb with the tables and data.

2) On each work station, Access must be installed and have a copy of
your "front end". By "front end", I mean all the forms, reports,
modules (if any) and associated code.

I could be wrong, and therefore apologize in advance if so, but it
sounds to me as if you've got an mdb with your data and forms, etc all
together.

If so, what you need to do is split your database. The easiest way to
do this in my experience is to simply take a copy of your existing mdb
and rename it data.mdb or something appropriate. Leave the tables with
the data, but delete everything else and compact what's left. You know
have an mdb with just tables and nothing else. This is now known as
"the back end".

In your other mdb, delete the tables from the mdb and compact (probably
a good idea to decompile as well if you're comfortable with that). This
becomes your "front end".

Now, make sure your data.mdb (the back end) is in the location you want
it to be on your server. In your front end application, on the tables
tab, link to the tables (File->Get external Data->Link Tables) in the
back end.

Now take your front end and make sure your users have the version of
Access running and a copy of your front end.

I need to host it on our Win2003 server. How do clients use it?

See above. Hope this helps.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tom van Stiphout]

On Sat, 30 Dec 2006 18:56:38 -0330, Tim Marshall
<TI****@PurplePandaChasers.Moertheriumwrote:

And if you're concerned about updating each workstation, check this
out:
http://www.granite.ab.ca/access/autofe.htm

-Tom.

>radink wrote:

>Well, I've got my DB ready to go. Now what?

Hi there. Not rying to be mean, but based on the rest of your post,
your application is *NOT* quite ready to go yet.

To deploy you application in the environment you've described (network
environment) what is necessary is to have it set up like this:

1) The server has the "back end", ie, an mdb with the tables and data.

2) On each work station, Access must be installed and have a copy of
your "front end". By "front end", I mean all the forms, reports,
modules (if any) and associated code.

I could be wrong, and therefore apologize in advance if so, but it
sounds to me as if you've got an mdb with your data and forms, etc all
together.

If so, what you need to do is split your database. The easiest way to
do this in my experience is to simply take a copy of your existing mdb
and rename it data.mdb or something appropriate. Leave the tables with
the data, but delete everything else and compact what's left. You know
have an mdb with just tables and nothing else. This is now known as
"the back end".

In your other mdb, delete the tables from the mdb and compact (probably
a good idea to decompile as well if you're comfortable with that). This
becomes your "front end".

Now, make sure your data.mdb (the back end) is in the location you want
it to be on your server. In your front end application, on the tables
tab, link to the tables (File->Get external Data->Link Tables) in the
back end.

Now take your front end and make sure your users have the version of
Access running and a copy of your front end.

>I need to host it on our Win2003 server. How do clients use it?

See above. Hope this helps.

['69 Camaro]

Hi.

Well, I've got my DB ready to go.

Almost, but not quite. You need to split your database before you put it into a
multiuser environment. Use the Database Slitter Wizard to place the back end
(tables and relationships) on the server) and leave the queries, forms, reports,
et cetera in the front end. Then convert this front end to an MDE database file
using the menu. Then make a copy of this MDE front end and place it on the
server for other users to copy to their hard drives, so that each user has his
own copy of the front end, which is linked to the tables in the back end. Make
sure you keep a copy of the MDB front end so that you can make changes later.

Once you split the database, you might be interested in automating the
distribution of any new front ends with Tony Toews's (MVP) AutoFE utililty.
With this utility, the developer places the new front end on the server and the
next time the users open the application, the new front end is saved to their
hard drives and they start using it. Please see the following Web page for more
information on his utility:

http://www.granite.ab.ca/access/autofe.htm

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"radink" <ra*****@gmail.comwrote in message
news:11*********************@73g2000cwn.googlegrou ps.com...

>
Well, I've got my DB ready to go. Now what?

I need to host it on our Win2003 server. How do clients use it?

I think im getting more confused as I try to figure this out. We are a
small company and I just want to be able to have everyone here use the
database at the same time without too much fuss. Do I just have to have
access on each machine and let them open it from the server, or is
there more to it than that? I just don't want them to be able to get
into the DB itself and modify things, just add entries and pull up
reports.

Thanks!

['69 Camaro]

Hi.

Do I just have to have
access on each machine and let them open it from the server

Access needs to be installed on each workstation that is using your Access front
end. Typically, this is the retail version of Access. However, if you have the
developer's edition (or Visual Studio Tools for Office if you have Access 2003
or 2007), then you can distribute the Runtime version of Access, because this
edition allows unlimited royalty-free distribution of the Access Runtime
version. The Runtime version doesn't allow the users to design applications,
just run Access database applications that were developed with the retail
version of Access.

For more information on VSTO 2005, please see the following Web page:

http://msdn2.microsoft.com/en-us/vstudio/aa718673.aspx

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"radink" <ra*****@gmail.comwrote in message
news:11*********************@73g2000cwn.googlegrou ps.com...

>
Well, I've got my DB ready to go. Now what?

I need to host it on our Win2003 server. How do clients use it?

I think im getting more confused as I try to figure this out. We are a
small company and I just want to be able to have everyone here use the
database at the same time without too much fuss. Do I just have to have
access on each machine and let them open it from the server, or is
there more to it than that? I just don't want them to be able to get
into the DB itself and modify things, just add entries and pull up
reports.

Thanks!

['69 Camaro]

Hi.

There are a lot of advantages to a split database in a multiuser environment,
including avoiding database corruption. For more information about split
databases (front end and back end), please see the following Web page:

http://www.Access.QBuilt.com/html/gem_tips.html#SplitDB

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"radink" <ra*****@gmail.comwrote in message
news:11*********************@73g2000cwn.googlegrou ps.com...

>
Well, I've got my DB ready to go. Now what?

I need to host it on our Win2003 server. How do clients use it?

I think im getting more confused as I try to figure this out. We are a
small company and I just want to be able to have everyone here use the
database at the same time without too much fuss. Do I just have to have
access on each machine and let them open it from the server, or is
there more to it than that? I just don't want them to be able to get
into the DB itself and modify things, just add entries and pull up
reports.

Thanks!

['69 Camaro]

Hi.

I just don't want them to be able to get
into the DB itself and modify things, just add entries and pull up
reports.

That's why it's advisable to deploy an MDE database file instead of an MDB
database file to the users. With an MDE, the user doesn't have access to the
VBA code, and will have difficulty making any changes to forms and reports.
However, the MDE file won't prevent the user from altering tables and queries.
If you really want to restrict permissions, look into implementing User-Level
Security. Please see the following Web page for downloading the Security FAQ:

http://support.microsoft.com/?id=207793

A fair warning, though. Implementing User-Level Security is difficult and prone
to error the first 20 times or so. Practice on a copy of your database first if
you decide to go this route so that you don't accidentally lock yourself out.
But you probably won't need security, since the MDE database file is usually
restrictive enough.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"radink" <ra*****@gmail.comwrote in message
news:11*********************@73g2000cwn.googlegrou ps.com...

>
Well, I've got my DB ready to go. Now what?

I need to host it on our Win2003 server. How do clients use it?

I think im getting more confused as I try to figure this out. We are a
small company and I just want to be able to have everyone here use the
database at the same time without too much fuss. Do I just have to have
access on each machine and let them open it from the server, or is
there more to it than that? I just don't want them to be able to get
into the DB itself and modify things, just add entries and pull up
reports.

Thanks!

['69 Camaro]

Hi.

Access databases designed in a single user environment often have performance
problems when deployed in a multiuser environment, such as the one you're about
to face. For more information about improving performance in multiuser
databases, please see the following Web page for a link to Access MVP Tom
Wickerath's article, "Implementing a Successful Multiuser Access/JET
Application":

http://www.Access.QBuilt.com/html/articles.html

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"radink" <ra*****@gmail.comwrote in message
news:11*********************@73g2000cwn.googlegrou ps.com...

>
Well, I've got my DB ready to go. Now what?

I need to host it on our Win2003 server. How do clients use it?

I think im getting more confused as I try to figure this out. We are a
small company and I just want to be able to have everyone here use the
database at the same time without too much fuss. Do I just have to have
access on each machine and let them open it from the server, or is
there more to it than that? I just don't want them to be able to get
into the DB itself and modify things, just add entries and pull up
reports.

Thanks!

[Lyle Fairfield]

"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote
in news:BI******************************@adelphia.com :

Hi.

Access databases designed in a single user environment often have
performance problems when deployed in a multiuser environment, such as
the one you're about to face. For more information about improving
performance in multiuser databases, please see the following Web page
for a link to Access MVP Tom Wickerath's article, "Implementing a
Successful Multiuser Access/JET Application":

http://www.geocaching.com

---------

(Would David call this "idiosyncratic advice"? We'll never know as he has
plonked me several times. He seems to plonk me every time he doesn't like
what I say.)

---------

Unrelated ...

I have faith that you'll get it, Gunny.

--
lyle fairfield

['69 Camaro]

Hi, Lyle.

(Would David call this "idiosyncratic advice"?

If he saw it, yes, I believe he would. But idiosyncratic though it may be, it
doesn't diminish its value in conveying an important concept.

I have faith that you'll get it, Gunny.

Uh, . . . after about 15 seconds, yes, I did. (Some of us are slower to catch
on than others.) ;-)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...

"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote
in news:BI******************************@adelphia.com :

>Hi.

Access databases designed in a single user environment often have
performance problems when deployed in a multiuser environment, such as
the one you're about to face. For more information about improving
performance in multiuser databases, please see the following Web page
for a link to Access MVP Tom Wickerath's article, "Implementing a
Successful Multiuser Access/JET Application":

http://www.geocaching.com

---------

(Would David call this "idiosyncratic advice"? We'll never know as he has
plonked me several times. He seems to plonk me every time he doesn't like
what I say.)

---------

Unrelated ...

I have faith that you'll get it, Gunny.

--
lyle fairfield

['69 Camaro]

And yes, I thought it was pretty funny. Thanks. :-)

Gunny
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote in
message news:Pv******************************@adelphia.com ...

Hi, Lyle.

>(Would David call this "idiosyncratic advice"?

If he saw it, yes, I believe he would. But idiosyncratic though it may be, it
doesn't diminish its value in conveying an important concept.

>I have faith that you'll get it, Gunny.

Uh, . . . after about 15 seconds, yes, I did. (Some of us are slower to catch
on than others.) ;-)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...

>"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote
in news:BI******************************@adelphia.com :

>>Hi.

Access databases designed in a single user environment often have
performance problems when deployed in a multiuser environment, such as
the one you're about to face. For more information about improving
performance in multiuser databases, please see the following Web page
for a link to Access MVP Tom Wickerath's article, "Implementing a
Successful Multiuser Access/JET Application":

http://www.geocaching.com

---------

(Would David call this "idiosyncratic advice"? We'll never know as he has
plonked me several times. He seems to plonk me every time he doesn't like
what I say.)

---------

Unrelated ...

I have faith that you'll get it, Gunny.

--
lyle fairfield

[radink]

Thanks for all of the help guys.

So to recap.

I split the DB.
Put the back end on the server in a shared folder
Fix the linking
Put the front end on each machine

Where is the splitting wizard. I can't seem to find it?

Thanks!

[tina]

look under Tools | Database Utilities, on the database window's menu bar.

you can also split the db yourself, by simply creating a new blank database
(don't forget to turn OFF the Name Autocorrect option), *importing* all
database objects EXCEPT the tables from your current database, and setting
any Startup options that you had set in the current database. then *link* in
the tables from your current database, compact, and close. next, back up the
current database (just in case!), then open it and delete all the objects
EXCEPT the tables. now the current database is the Backend database, and the
new database is the Frontend database.

note that if you've implemented Access Security, there may well be other
issues involved in splitting. i've no idea since i've never used the
Security feature, so you'll need to look further for information in that
case.

hth
"radink" <ra*****@gmail.comwrote in message
news:11**********************@s34g2000cwa.googlegr oups.com...

Thanks for all of the help guys.

So to recap.

I split the DB.
Put the back end on the server in a shared folder
Fix the linking
Put the front end on each machine

Where is the splitting wizard. I can't seem to find it?

Thanks!

[radink]

Cool thanks!
I haven't done any security yet. I'm just trying to keep it as simple
as possible. It's just a time card DB.

tina wrote:

look under Tools | Database Utilities, on the database window's menu bar.

you can also split the db yourself, by simply creating a new blank database
(don't forget to turn OFF the Name Autocorrect option), *importing* all
database objects EXCEPT the tables from your current database, and setting
any Startup options that you had set in the current database. then *link* in
the tables from your current database, compact, and close. next, back up the
current database (just in case!), then open it and delete all the objects
EXCEPT the tables. now the current database is the Backend database, and the
new database is the Frontend database.

note that if you've implemented Access Security, there may well be other
issues involved in splitting. i've no idea since i've never used the
Security feature, so you'll need to look further for information in that
case.

hth
"radink" <ra*****@gmail.comwrote in message
news:11**********************@s34g2000cwa.googlegr oups.com...

Thanks for all of the help guys.

So to recap.

I split the DB.
Put the back end on the server in a shared folder
Fix the linking
Put the front end on each machine

Where is the splitting wizard. I can't seem to find it?

Thanks!

[radink]

I splt the DB and ran the compress command.

All seems to have went well.

For the front end, does each person have their own copy, or can I share
one from the server?

If I change the frontend, how do I get everyone updated. Is it as
simple as just copying the new version to each machine, or is there an
even easier way?

Thanks again to everyone helping!

radink wrote:

Cool thanks!
I haven't done any security yet. I'm just trying to keep it as simple
as possible. It's just a time card DB.

tina wrote:

look under Tools | Database Utilities, on the database window's menu bar.

you can also split the db yourself, by simply creating a new blank database
(don't forget to turn OFF the Name Autocorrect option), *importing* all
database objects EXCEPT the tables from your current database, and setting
any Startup options that you had set in the current database. then *link* in
the tables from your current database, compact, and close. next, back up the
current database (just in case!), then open it and delete all the objects
EXCEPT the tables. now the current database is the Backend database, and the
new database is the Frontend database.

note that if you've implemented Access Security, there may well be other
issues involved in splitting. i've no idea since i've never used the
Security feature, so you'll need to look further for information in that
case.

hth
"radink" <ra*****@gmail.comwrote in message
news:11**********************@s34g2000cwa.googlegr oups.com...

Thanks for all of the help guys.
>
So to recap.
>
I split the DB.
Put the back end on the server in a shared folder
Fix the linking
Put the front end on each machine
>
Where is the splitting wizard. I can't seem to find it?
>
Thanks!
>

[tina]

you need to go back and read this entire thread again. the question i
answered had already been answered earlier by Tim Marshall (and was a more
efficient way to do it than what i posted), and your questions below have
already been answered, too.

hth
"radink" <ra*****@gmail.comwrote in message
news:11**********************@a3g2000cwd.googlegro ups.com...

I splt the DB and ran the compress command.

All seems to have went well.

For the front end, does each person have their own copy, or can I share
one from the server?

If I change the frontend, how do I get everyone updated. Is it as
simple as just copying the new version to each machine, or is there an
even easier way?

Thanks again to everyone helping!

radink wrote:

Cool thanks!
I haven't done any security yet. I'm just trying to keep it as simple
as possible. It's just a time card DB.

tina wrote:

look under Tools | Database Utilities, on the database window's menu

bar.

>
you can also split the db yourself, by simply creating a new blank

database

(don't forget to turn OFF the Name Autocorrect option), *importing*

all

database objects EXCEPT the tables from your current database, and

setting

any Startup options that you had set in the current database. then

*link* in

the tables from your current database, compact, and close. next, back

up the

current database (just in case!), then open it and delete all the

objects

EXCEPT the tables. now the current database is the Backend database,

and the

new database is the Frontend database.
>
note that if you've implemented Access Security, there may well be

other

issues involved in splitting. i've no idea since i've never used the
Security feature, so you'll need to look further for information in

that

case.
>
hth
>
>
"radink" <ra*****@gmail.comwrote in message
news:11**********************@s34g2000cwa.googlegr oups.com...
Thanks for all of the help guys.

So to recap.

I split the DB.
Put the back end on the server in a shared folder
Fix the linking
Put the front end on each machine

Where is the splitting wizard. I can't seem to find it?

Thanks!

[David W. Fenton]

"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:Pv******************************@adelphia.com :

[Lyle]

>(Would David call this "idiosyncratic advice"?

If he saw it, yes, I believe he would. But idiosyncratic though
it may be, it doesn't diminish its value in conveying an important
concept.

I wouldn't call it "advice" at all.

>I have faith that you'll get it, Gunny.

Uh, . . . after about 15 seconds, yes, I did. (Some of us are
slower to catch on than others.) ;-)

After waiting a long time for the page to load I stopped it and
reloaded and got "Server too busy."

I don't get it, but I'm phenomenally stupid whenever it comes to
anything Lyle posts.

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

['69 Camaro]

Hi, David.

I don't get it

Lyle provided empirical evidence of a Web programmer who obviously hasn't read
Tom Wickerath's article on improving database performance in a multiuser
environment (which I mentioned in a previous post). I have broadband, so it's
probably easier for me to see the effects. Web pages generally load in 1.5 to
2.5 seconds. Even the slowest pages only take 8 or 9 seconds. This Web page
took considerably longer than can reasonably be expected. I don't know how long
it takes to load, because I gave up and closed the window.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:Pv******************************@adelphia.com :

[Lyle]

>>(Would David call this "idiosyncratic advice"?

If he saw it, yes, I believe he would. But idiosyncratic though
it may be, it doesn't diminish its value in conveying an important
concept.

I wouldn't call it "advice" at all.

>>I have faith that you'll get it, Gunny.

Uh, . . . after about 15 seconds, yes, I did. (Some of us are
slower to catch on than others.) ;-)

After waiting a long time for the page to load I stopped it and
reloaded and got "Server too busy."

I don't get it, but I'm phenomenally stupid whenever it comes to
anything Lyle posts.

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

[Larry Linson]

"'69 Camaro" wrote

>I don't get it

Lyle provided empirical evidence of a Web programmer
who . . . Web pages generally load in 1.5 to 2.5 seconds.
Even the slowest pages only take 8 or 9 seconds. This
Web page took considerably longer than can reasonably
be expected. I don't know how long it takes to load,
because I gave up and closed the window.

Lyle's message would have been lost on me, also.

I know what "geocaching" is, and didn't think a website devoted to that
subject could be of much help in deploying Access databases, so only now,
after your discussion, did I click on Lyle's link.

Amazingly enough (I have lowest-level DSL), the initial page came up in less
than a second; and clicking on a link on that page brought up the next page
in similarly rapid fashion.

I can't recall anything I've done to set an option or to modify my browser
to "display at blinding speed what takes approximately forever for David and
Gunny to view."

Larry

['69 Camaro]

Hi, Larry.

I can't recall anything I've done to set an option or to modify my browser to
"display at blinding speed what takes approximately forever for David and
Gunny to view."

You have the magic touch, Larry. :-)

I just tried it again, and it still doesn't load for me. Well, if it was
intended for me to see something on that Web page, I never saw it, so perhaps I
didn't "get it" after all!

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"Larry Linson" <bo*****@localhost.notwrote in message
news:LTXlh.1324$Fs2.614@trnddc05...

"'69 Camaro" wrote

I don't get it

Lyle provided empirical evidence of a Web programmer
who . . . Web pages generally load in 1.5 to 2.5 seconds.
Even the slowest pages only take 8 or 9 seconds. This
Web page took considerably longer than can reasonably
be expected. I don't know how long it takes to load,
because I gave up and closed the window.

Lyle's message would have been lost on me, also.

I know what "geocaching" is, and didn't think a website devoted to that
subject could be of much help in deploying Access databases, so only now,
after your discussion, did I click on Lyle's link.

Amazingly enough (I have lowest-level DSL), the initial page came up in less
than a second; and clicking on a link on that page brought up the next page in
similarly rapid fashion.

I can't recall anything I've done to set an option or to modify my browser to
"display at blinding speed what takes approximately forever for David and
Gunny to view."

Larry

[Lyle Fairfield]

"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote
in news:4t******************************@adelphia.com :

>I can't recall anything I've done to set an option or to modify my
browser to "display at blinding speed what takes approximately
forever for David and Gunny to view."

http://kmeleon.sourceforge.net/
If you take some time to learn the "idiosyncracies" of K-Meleon you will be
rewarded with browsing about two times faster than Firefox, three times
faster than IE7 and four times faster than Netscape ... I think it beats
Opera too, but not by a lot.
But it does require some time and work.

I just tried it again, and it still doesn't load for me. Well, if it
was intended for me to see something on that Web page, I never saw it,
so perhaps I didn't "get it" after all!

http://www.ffdba.com/Geocaching%20-%...0Global%20GPS%
20Cache%20Hunt%20Site.htm

(all one line)

--
lyle fairfield

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.comwrote

>>I can't recall anything I've done to set an option
or to modify my browser to "display at blinding
speed what takes approximately forever for
David and Gunny to view."

http://kmeleon.sourceforge.net/
If you take some time to learn the "idiosyncracies" of
K-Meleon you will be rewarded with browsing about
two times faster than Firefox, three times faster than
IE7 and four times faster than Netscape ... I think it beats
Opera too, but not by a lot.
But it does require some time and work.

As my "blinding speed" came with a stock installation of IE 6, I don't know
if my poor body could accomodate the neck-snap of anything faster. But,
maybe I will take a look... it couldn't be more effort than some programs I
have, over time, used and appreciated.

I've run into some "aristocratic idiots" from time to time. Does this mean
K-Meleon is a "syncratic idiot"? I mostly ignored the aristocratic ones,
but doesn't seem that will work for this one.

Larry

['69 Camaro]

Hi, Lyle.

Thanks for the help. I followed your link, didn't see anything that jumped up
and bit me, and followed the link to "Let's get started" for an introduction
(I've never heard of geocaching before). It loaded very fast, but I didn't see
anything significant there, either. I went back to the page you put on your Web
site and started playing with the text box and combo box controls, but those
redirect one to a page relative to the main page, none of which were on your Web
site, so those didn't work. Then I decided to use the "Search Geocaching.com"
search button. I searched for "Lyle," but didn't see anything on the list that
would catch my attention. I next searched for "Fairfield," and saw a larger
list. I followed some of the links to the Geocache forum, but those pages
loaded fast, too. And then I went back and searched for "Camaro." I tried to
follow some of the links, but it's life in the slow lane for many of them.

If it wasn't the slowness of these Web pages loading from the Web site's
database (I gave up waiting, so I don't know how long they take to load), then
I'm too stupid to "get it," too. :-(

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact info.
"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...

"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote
in news:4t******************************@adelphia.com :

>>I can't recall anything I've done to set an option or to modify my
browser to "display at blinding speed what takes approximately
forever for David and Gunny to view."

http://kmeleon.sourceforge.net/
If you take some time to learn the "idiosyncracies" of K-Meleon you will be
rewarded with browsing about two times faster than Firefox, three times
faster than IE7 and four times faster than Netscape ... I think it beats
Opera too, but not by a lot.
But it does require some time and work.

>I just tried it again, and it still doesn't load for me. Well, if it
was intended for me to see something on that Web page, I never saw it,
so perhaps I didn't "get it" after all!

http://www.ffdba.com/Geocaching%20-%...0Global%20GPS%
20Cache%20Hunt%20Site.htm

(all one line)

--
lyle fairfield

[Larry Linson]

"'69 Camaro" wrote

>I can't recall anything I've done to set an option
or to modify my browser to "display at blinding
speed what takes approximately forever for
David and Gunny to view."

You have the magic touch, Larry. :-)

Possibly, as I certainly can't claim it "was because I've been living
right." <BIG GRIN>

And, as I did it with a strictly-stock installation of IE 6, it wasn't the
kind of "sufficiently advanced technology is indistinguishable from magic"
that Arthur C. Clarke or Robert A. Heinlien wrote about (I've seen the quote
attributed to both of them).

Larry

[David F Cox]

Just a thought. It is outside of my area of expertise, but I believe that
having controls in your internet cache is considerably faster than loading
them first time under the suspicious eye of an anti-virus package.
"Larry Linson" <bo*****@localhost.notwrote in message
news:iy_lh.6509$0F1.2159@trnddc02...

"'69 Camaro" wrote

I can't recall anything I've done to set an option
or to modify my browser to "display at blinding
speed what takes approximately forever for
David and Gunny to view."

You have the magic touch, Larry. :-)

Possibly, as I certainly can't claim it "was because I've been living
right." <BIG GRIN>

And, as I did it with a strictly-stock installation of IE 6, it wasn't the
kind of "sufficiently advanced technology is indistinguishable from magic"
that Arthur C. Clarke or Robert A. Heinlien wrote about (I've seen the
quote attributed to both of them).

Larry

[David W. Fenton]

"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:94******************************@adelphia.com :

If it wasn't the slowness of these Web pages loading from the Web
site's database (I gave up waiting, so I don't know how long they
take to load), then I'm too stupid to "get it," too. :-(

Um, no, it's not that you're stupid, it's that Lyle hasn't made his
point.

This is typical. He posts something and doesn't make clear *why* he
posted it. This is one of the reasons he's in my kill file.

Actually, the other reason was his religious devotion to ADPs and
deprecating the "old-fashioned" approach of using an MDB. He's come
around on that one, after experiencing the problems that everyone
else reported (and that I think were inevitable given the bogus
purpose of ADPs, i.e., to avoid Jet, instead of using Jet properly).

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

[Lyle Fairfield]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in
news:Xn**********************************@127.0.0. 1:

"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:94******************************@adelphia.com :

>If it wasn't the slowness of these Web pages loading from the Web
site's database (I gave up waiting, so I don't know how long they
take to load), then I'm too stupid to "get it," too. :-(

Um, no, it's not that you're stupid, it's that Lyle hasn't made his
point.

This is typical. He posts something and doesn't make clear *why* he
posted it. This is one of the reasons he's in my kill file.

Actually, the other reason was his religious devotion to ADPs and
deprecating the "old-fashioned" approach of using an MDB. He's come
around on that one, after experiencing the problems that everyone
else reported (and that I think were inevitable given the bogus
purpose of ADPs, i.e., to avoid Jet, instead of using Jet properly).

Actually I came around after experiencing one problem of which, TTBOMK, I
was the initial reporter.

And, I'm thinking of retreating on that, and going back to being a
supporter of ADPs.
--
lyle fairfield

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.comwrote

And, I'm thinking of retreating on that, and
going back to being a supporter of ADPs.

Hmm. If you're "going back", you could go back to Access 97, or Access 2.0,
and MDB vs ADP would not be an issue. And, being as they are "obsolescent
versions," they'd be cheap for your clients to purchase on eBay or the "old
software" sites.

Wait a minute, now... that's not _you_ posting as a@ron k#mpf or J@mie
C*llins, is it? <GRIN>

Have they fixed the problem that soured you on ADPs in Access 2007?

Have you taken a look at the OpenSource xHarbour, enhancement to dBase?

Larry

[Lyle Fairfield]

"Larry Linson" <bo*****@localhost.notwrote in
news:5rjmh.1388$SQ1.1359@trnddc03:

Have they fixed the problem that soured you on ADPs in Access 2007?

Not TTBOMK. What has changed is that I believe MDBs connecting to MS-SQL
Databases with ODBC have the some potential for problems.
If there are two solutions and they both have the same problems there seems
little point in abandoning the modern, glistening, capable one for the
other, slower, trudging model.

But I do not pretend to have a lot of experience with ODBC. Someone, (Rick
Brandt?) made me more aware and appreciative of its power. Regardless, IMO,
it's way behind the direct OLEDB/ADP connection of the ADP.

Also IMO there is only one problem with ADPs. That is that user permissions
may be accessible and these permissions may be used in other ADPs or
whatever to access the data.
IF ... big IF, ODBC has the same failing then I can think of no reason to
use ODBC.
As for other ADP problems ... I don't know of any, or at least of any for
which there is not a ready solution.
--
lyle fairfield

[Larry Linson]

The new ACCDB requires SharePoint, I hear, for security. As I don't have a
setup in my home office that allows me to set up SharePoint, nor do any of
my clients have SharePoint installed, that is something of a stumbling
block. I don't expect those clients to rush to SharePoint just because
Microsoft is promoting it so heavily, either...

In the admittedly-somewhat-limited work I did enhancing a client's ADP, I
saw no particular advantage in the rather ordinary proposal-tracking
application... but, of course, the original author appeared to have been a
"refugee from Visual Basic," didn't the DBA to put Primary Keys on the SQL
Server Tables to allow bound forms, so it was un-representative.

And, of course, I didn't have the same application in MDB and ODBC to
compare, but have had very good results with ODBC over a number of years.

Larry Linson
Microsoft Access MVP
"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...

"Larry Linson" <bo*****@localhost.notwrote in
news:5rjmh.1388$SQ1.1359@trnddc03:

>Have they fixed the problem that soured you on ADPs in Access 2007?

Not TTBOMK. What has changed is that I believe MDBs connecting to MS-SQL
Databases with ODBC have the some potential for problems.
If there are two solutions and they both have the same problems there
seems
little point in abandoning the modern, glistening, capable one for the
other, slower, trudging model.

But I do not pretend to have a lot of experience with ODBC. Someone, (Rick
Brandt?) made me more aware and appreciative of its power. Regardless,
IMO,
it's way behind the direct OLEDB/ADP connection of the ADP.

Also IMO there is only one problem with ADPs. That is that user
permissions
may be accessible and these permissions may be used in other ADPs or
whatever to access the data.
IF ... big IF, ODBC has the same failing then I can think of no reason to
use ODBC.
As for other ADP problems ... I don't know of any, or at least of any for
which there is not a ready solution.
--
lyle fairfield

[Rick Brandt]

"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...

"Larry Linson" <bo*****@localhost.notwrote in
news:5rjmh.1388$SQ1.1359@trnddc03:

>Have they fixed the problem that soured you on ADPs in Access 2007?

Not TTBOMK. What has changed is that I believe MDBs connecting to MS-SQL
Databases with ODBC have the some potential for problems.
If there are two solutions and they both have the same problems there seems
little point in abandoning the modern, glistening, capable one for the
other, slower, trudging model.

But I do not pretend to have a lot of experience with ODBC. Someone, (Rick
Brandt?) made me more aware and appreciative of its power. Regardless, IMO,
it's way behind the direct OLEDB/ADP connection of the ADP.

It is not hard for me to believe that OLEDB/ADP could have performance
advantages over ODBC. What is lacking is any believable sources that actually
make that claim and can back it up with easily reproducible evidence. In fact
all I have heard over and over is that ODBC is faster.

With other products in other situations I have had numerous occassions where we
were using OLEDB and were encountering some difficulties. Upon consulting with
outside experts we are told time and time again "Yeah, there are problems with
OLEDB, use ODBC instead".

Only with the recent change to SQL Server 2005 and the use of SSIS have we been
able to use OLEDB without issues. Here again we find SSIS LOTS slower than the
DTS it replaces, but it does not appear to be due to OLEDB in this case becase
even when we use ODBC it is still a lot slower than DTS. In this case it is the
dot-net layer that appears to be the piece slowing things down (big surprise).

So, as with lots of other stuff my impression has become that OLEDB has been
widely adopted simply because it is newer, not because of any huge technical
advantages it supposedly has. I am not a luddite, but I do not upgrade just
because it's newer. I expect some bang for my buck.

Also IMO there is only one problem with ADPs. That is that user permissions
may be accessible and these permissions may be used in other ADPs or
whatever to access the data.

I don't understand this objection. To access data you have to give permissions
to the tables and views that contain the data. Is there ANY product where this
is not the case? While I have heard of granting permissions "to the
application" and not to users I have never encountered a product that actually
does this. One can always go with an "all stored procedures" model to avoid
giving any permissions to the source tables.

Could you not embed within the application a connection that is not based on the
user and only grant permissions to that "application user" to avoid these
problems? Of course that would introduce the big disadvantage of not being able
to easily have differing permissions per-user.

SQL Server 2005 supports application roles (not sure if its the first to do so),
but I have never messed with them.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Lyle Fairfield]

"Rick Brandt" <ri*********@hotmail.comwrote in
news:0T****************@newssvr12.news.prodigy.net :

SQL Server 2005 supports application roles (not sure if its the first
to do so), but I have never messed with them.

Application roles were introduced in Server 7.0 I believe.
But I would advise keeping right on with never messing with them, at least
with ADPs. Their use in ADPs is convoluted, erratic and, largely,
undocumented.

--
lyle fairfield

[David W. Fenton]

"Larry Linson" <bo*****@localhost.notwrote in
news:Sxlmh.1879$PN2.163@trnddc07:

The new ACCDB requires SharePoint, I hear, for security.

Eh? You mean for an ACCDB back end? My understanding was that the
only security in an ACCDB was a database password, though you could,
of course, connect an ACCDB front end to any secured server back
end.

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

[David W. Fenton]

"Rick Brandt" <ri*********@hotmail.comwrote in
news:0T****************@newssvr12.news.prodigy.net :

So, as with lots of other stuff my impression has become that
OLEDB has been widely adopted simply because it is newer, not
because of any huge technical advantages it supposedly has. I am
not a luddite, but I do not upgrade just because it's newer. I
expect some bang for my buck.

It's sad, really. ODBC is really long in the tooth and doesn't
accomodate a whole host of technologies that are now commonly found
in database engines of all stripes. The intention behind OLEDB was
good, obviously, it's just that I think MS tried to hard to make it
*smart* so that it takes over and does things that it shouldn't, and
over which the programmer has no control.

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

[Lyle Fairfield]

David W. Fenton wrote:

It's sad, really. ODBC is really long in the tooth and doesn't
accomodate a whole host of technologies that are now commonly found
in database engines of all stripes. The intention behind OLEDB was
good, obviously, it's just that I think MS tried to hard to make it
*smart* so that it takes over and does things that it shouldn't, and
over which the programmer has no control.

It's unlikely that anyone would mistake me for an ODBC fan. But MSDN's

Microsoft Open Database Connectivity (ODBC) papers
http://msdn2.microsoft.com/en-gb/library/ms710252.aspx

have opened my eyes to how powerful and enabling this technology is.
Specifically I am very impressed with its ability to translate many
application function calls to provider specific function calls which
will run on the server. This means we don't have to examine say, BOL,
and choose the correct T-SQL expression. ODBC will do this
silently,swiftly and behind the scenes, for us. What I get from this is
that the Access developer does not have to learn T-SQL in order to take
advantage of T-SQL. I think that's amazing and tres excellent.
(It may make me a bit p-off that I learned T-SQL but T-SQL is useful in
many other places and a little learning never hurt anyone).
I extrapolate from this that properly crafted ODBC will take advantage
of MS-SQL capabilities when directed to MS-SQL Server, and the same
statements, queries whatever will take advantage of Oracle when
directed to Oracle.
That may be better than crafting T-SQL and then having to rewrite it
all for Oracle.

Gee, I just implied I'm not an ODBC fan!

(Everything here is assuming I am understanding things correctly which
is probably a 50-50 proposition. I don't pretend to be an expert on
ODBC and have only experimented with it, not used it extensively.)

--

Regardless, my preference for ADPs extends beyond the relationship of
ADPs and MS-SQL Server. One can do things in ADPs which one cannot do
in MDBs. I like that.
Myabe an ADP with an ODBC connection? ... hmmmmmmmmm and lol.