By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,118 Members | 1,134 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,118 IT Pros & Developers. It's quick & easy.

Access 2003 ODBC Problem

P: n/a
I have an Access 2003 .mde sitting on an SQL Server. The tables for
the application also sit on the Server. I'm having a problem with
ODBC on only one of about 10 machines. All the other machines using my
Access 2003 .mde see the linked tables without a problem. I've
configured the User DSN (under Control Panel, Administrative Tools)
tab to match what the other machines are set to, but this didn't work.
I keep getting an error message that ODBC failed. Does anything need
to be listed under the System DSN tab? Maybe something with the
drivers? The File DSN tab has different lists on the 10 machines, so
I'm not sure what to do with this.
Nov 13 '05 #1
Share this Question
Share on Google+
26 Replies


P: n/a
If you have multiple users logging in to the same .MDE on the server, you
significantly increase the probability of corruption of that .MDE. The very
strong recommendation of Microsoft and other knowledgeable parties is that
you give each user their own copy of the client; if running WTS or Citrix to
execute the Access clients on the server, still give each user their own
copy in separate folders. That isn't the answer to your current problem, but
if you distribute the front ends, you will likely eliminate _this_ problem
(but may face some different ones).

If distributing and updating client apps seems a daunting task, MVP Tony
Toews has a Front End Updater that is free for the downloading at his (very
helpful) site, http://www.granite.ab.ca/accsmstr.htm.

Larry Linson
Microsoft Access MVP
"Dragon" <xs*******@yahoo.com> wrote in message
news:3e************************@posting.google.com ...
I have an Access 2003 .mde sitting on an SQL Server. The tables for
the application also sit on the Server. I'm having a problem with
ODBC on only one of about 10 machines. All the other machines using my
Access 2003 .mde see the linked tables without a problem. I've
configured the User DSN (under Control Panel, Administrative Tools)
tab to match what the other machines are set to, but this didn't work.
I keep getting an error message that ODBC failed. Does anything need
to be listed under the System DSN tab? Maybe something with the
drivers? The File DSN tab has different lists on the 10 machines, so
I'm not sure what to do with this.

Nov 13 '05 #2

P: n/a
Make sure that you have the same ODBCE DRIVERs on each machine.

A DSN contains the connection information. You can use
connection information stored in the mde (a DSN'less connection),
in a file (a file dsn) or in the registry somewhere.

The actual connection information used by Access will be a
combination of information from currently open connections,
information stored in the database, and the DSN if one is used.

You will only have currently open connections if you try to
add or change a connection while the mde is in use, so that
shouldn't matter.

If the users have different DSN's, or the content of the DSN's
is different, then they need to have their own copies of the
MDE. Otherwise the connection information will get confused,
because the stored connection information in the database will
get mixed up with the different DSN information.

If the connection information is different in any way, each
user should have their own copy of the MDE, which can be re-
linked to use the correct connection information.

User DSN's and File DSN's are stored differently. Each DSN
contains connection information. If you are using a DSN, you
certainly need to work out which DSN you are using. Is it a
file DSN? Or a User DSN? The DSN's which you are NOT using
don't matter. The one DSN that you ARE using (if you are
using a DSN) should be identical on all machines. Even if
you are using separate copies of the MDE, and re-linking on
each PC, you still should make sure that you don't have multiple
different copies of the DSN, because that is sure to confuse
you!

(david)

"Dragon" <xs*******@yahoo.com> wrote in message
news:3e************************@posting.google.com ...
I have an Access 2003 .mde sitting on an SQL Server. The tables for
the application also sit on the Server. I'm having a problem with
ODBC on only one of about 10 machines. All the other machines using my
Access 2003 .mde see the linked tables without a problem. I've
configured the User DSN (under Control Panel, Administrative Tools)
tab to match what the other machines are set to, but this didn't work.
I keep getting an error message that ODBC failed. Does anything need
to be listed under the System DSN tab? Maybe something with the
drivers? The File DSN tab has different lists on the 10 machines, so
I'm not sure what to do with this.

Nov 13 '05 #3

P: n/a
"Sherwood Wang" <Sh****@waynesworld.net> wrote
*Sherwood Wang MVP*
(is also sys eng, bs, ms)


(is sockpuppet of resident troll XMVP. is not Microsoft MVP. is source of
much bs.)
Nov 13 '05 #4

P: n/a

"Larry Linson" <bo*****@localhost.not> wrote in message
news:kY54d.241$gu5.103@trnddc09...
"Sherwood Wang" <Sh****@waynesworld.net> wrote
*Sherwood Wang MVP*
(is also sys eng, bs, ms)


(is sockpuppet of resident troll XMVP. is not Microsoft MVP. is source of
much bs.)

ok you make joke on my english mr larry linson. ok you say i not me. ok
you say i not mvp.

NOT ok give bad stupid advice to poor people! you idiot saying what you say
in thread about ts running many many many copy accesss mde. so very stupid
advise from phony mr larry linson bfd. all sockepuppets can eat you lunch!

*Sherwood Wang MVP*
Nov 13 '05 #5

P: n/a
Don, it is bad enough that you try to distract the participants from the
business of the newsgroup, but when you try to mislead them, using whatever
alias is your choice of the moment, that is, indeed, WRONG and, indeed, not
OK.

Pull your head out of the dark and get a life.
"Sherwood Wang" <Sh****@waynesworld.net> wrote in message
news:1095824557.xdnZALwb1D+LNhE7NmwKIw@teranews...

"Larry Linson" <bo*****@localhost.not> wrote in message
news:kY54d.241$gu5.103@trnddc09...
"Sherwood Wang" <Sh****@waynesworld.net> wrote
*Sherwood Wang MVP*
(is also sys eng, bs, ms)
(is sockpuppet of resident troll XMVP. is not Microsoft MVP. is source of much bs.)

ok you make joke on my english mr larry linson. ok you say i not me. ok
you say i not mvp.

NOT ok give bad stupid advice to poor people! you idiot saying what you

say in thread about ts running many many many copy accesss mde. so very stupid advise from phony mr larry linson bfd. all sockepuppets can eat you lunch!
*Sherwood Wang MVP*

Nov 13 '05 #6

P: n/a
xs*******@yahoo.com (Dragon) wrote:
I have an Access 2003 .mde sitting on an SQL Server. The tables for
the application also sit on the Server. I'm having a problem with
ODBC on only one of about 10 machines. All the other machines using my
Access 2003 .mde see the linked tables without a problem. I've
configured the User DSN (under Control Panel, Administrative Tools)
tab to match what the other machines are set to, but this didn't work.


Not that this is likely to help you with your immediate problem but ...

I much prefer DSN-Less connections as it is one less thing for someone to have to
configure and one less thing for the users to screw up.

Using DSN-Less Connections
http://members.rogers.com/douglas.j....LessLinks.html
ODBC DSN-Less Connection Tutorial Part I
http://www.amazecreations.com/datafa...m&Article=true
HOWTO: Use "DSN-Less" ODBC Connections with RDO and DAO
http://support.microsoft.com/?id=147875
ODBC DSN Less
http://www.able-consulting.com/MDAC/...BC_DSNLess.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #7

P: n/a

"Larry Linson" <bo*****@localhost.not> wrote in message
news:zf24d.5091$Co1.5001@trnddc02...
If you have multiple users logging in to the same .MDE on the server, you
significantly increase the probability of corruption of that .MDE. The
very
strong recommendation of Microsoft and other knowledgeable parties is that
you give each user their own copy of the client; if running WTS or Citrix
to
execute the Access clients on the server, still give each user their own
copy in separate folders. That isn't the answer to your current problem,
but
if you distribute the front ends, you will likely eliminate _this_ problem
(but may face some different ones).

If distributing and updating client apps seems a daunting task, MVP Tony
Toews has a Front End Updater that is free for the downloading at his
(very
helpful) site, http://www.granite.ab.ca/accsmstr.htm.

Larry Linson
Microsoft Access MVP

Larry:

The part you wrote about running multiple client front ends on WTS or Citrix
is wrong. After all, that's why people buy WTS or Citrix--so they don't
have to run multiple copies! Also, I think Tony stole that front end
updater from me.

Arvin

Nov 13 '05 #8

P: n/a
Message-ID: <1095889669.GX6nk50cdPbsA0kLZEbI1w@teranews>
X-Abuse-Report: http://www.usenetabuse.com
This message is a forgery by the troll.
The part you wrote about running multiple client front ends on WTS or Citrix
is wrong. After all, that's why people buy WTS or Citrix--so they don't
have to run multiple copies!
Wrong.
Also, I think Tony stole that front end
updater from me.


Absolutely wrong!

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #9

P: n/a

"Arvin Meyer" <No****@NoSpam.net> wrote in message
news:1095889669.GX6nk50cdPbsA0kLZEbI1w@teranews...

"Larry Linson" <bo*****@localhost.not> wrote in message
news:zf24d.5091$Co1.5001@trnddc02...
If you have multiple users logging in to the same .MDE on the server, you
significantly increase the probability of corruption of that .MDE. The
very
strong recommendation of Microsoft and other knowledgeable parties is
that
you give each user their own copy of the client; if running WTS or Citrix
to
execute the Access clients on the server, still give each user their own
copy in separate folders. That isn't the answer to your current problem,
but
if you distribute the front ends, you will likely eliminate _this_
problem
(but may face some different ones).

If distributing and updating client apps seems a daunting task, MVP Tony
Toews has a Front End Updater that is free for the downloading at his
(very
helpful) site, http://www.granite.ab.ca/accsmstr.htm.

Larry Linson
Microsoft Access MVP

Larry:

The part you wrote about running multiple client front ends on WTS or
Citrix is wrong. After all, that's why people buy WTS or Citrix--so they
don't have to run multiple copies! Also, I think Tony stole that front
end updater from me.

Arvin


mr arvin meyer so very much thank you! is a problem in ng with bad advice
yes? is most come from larry and tony i see. everybody is troll if when
they get caught wrong! is like tune somebody write on them--

Here comes Larry without a clue
Here comes Tony and Davey too
It's finger flip flippin' time
They think they're smart
And that's a real bad start

is so very true ok?

*Sherwood Wang MVP*



Nov 13 '05 #10

P: n/a
The resident troll, forging a post as though it were from
"Arvin Meyer" , wrote
The part you wrote about running multiple
client front ends on WTS or Citrix is wrong.
How disgusting, that the resident troll should not only use his sockpuppets
to mislead participants here, but forge posts from MVPs, trying to take
advantage of their credibility to mislead.
After all, that's why people buy WTS or
Citrix--so they don't have to run multiple
copies!


Not true -- people use WTS or Citrix so they can run at the server rather
than at a user's machine. This can be vital, depending on the network and
connection speed.

BTW, with your half-vast experience in forgery, did you send some Word
documents to a Bill Burkett, down in Texas? Those were sloppy enough to have
been your work.
Nov 13 '05 #11

P: n/a

"Larry Linson" <bo*****@localhost.not> wrote in message
news:VQB4d.661$Jj4.203@trnddc06...
The resident troll, forging a post as though it were from
"Arvin Meyer" , wrote
The part you wrote about running multiple
client front ends on WTS or Citrix is wrong.


How disgusting, that the resident troll should not only use his
sockpuppets
to mislead participants here, but forge posts from MVPs, trying to take
advantage of their credibility to mislead.
After all, that's why people buy WTS or
Citrix--so they don't have to run multiple
copies!


Not true -- people use WTS or Citrix so they can run at the server rather
than at a user's machine. This can be vital, depending on the network and
connection speed.

BTW, with your half-vast experience in forgery, did you send some Word
documents to a Bill Burkett, down in Texas? Those were sloppy enough to
have
been your work.


most what you write ot mr larry linson bfd. is truth tho you are studip now
for all world seeing now!

what people use metaframe sofware as server please? stupid people like you
yes? surprize now mr larry linson bfd. no need for wts or citrix if you
make 1000s copy of mde in 1000s folders on server! like you say.

now you go deep stupid give us more big laughs ok?

btw texas is home to you yes?

Nov 13 '05 #12

P: n/a
"Sherwood Wang" <sh****@waynesworld.net> wrote > most
what people use metaframe sofware
as server please? stupid people like you
yes?
Everyone who uses it. That is what it is for, to let someone on a network
execute applications on the server machine. I'd suggest you do some research
on WTS/Citrix, Don, because the one making a fool of himself in public is
you.
surprize now mr larry linson bfd. no
need for wts or citrix if you make 1000s
copy of mde in 1000s folders on server!


WTS/Citrix allows executing the MDE _on the server_, and allows a user with
a relatively slow (e.g., Internet) connection to run Access remotely. If
there was a sufficiently fast LAN, a user could execute an MDE that is
stored on the server, but it would execute on the user's own machine.

Thanks for showing your ignorance and, thus, giving me an opportunity to
explain WTS/Citrix, Don. If you don't believe this, do your own research --
it is obvious that you have neither used or learned WTS/Citrix.


Nov 13 '05 #13

P: n/a

"Larry Linson" <bo*****@localhost.not> wrote in message
news:22I4d.9673$2A1.6044@trnddc08...
"Sherwood Wang" <sh****@waynesworld.net> wrote > most
what people use metaframe sofware
as server please? stupid people like you
yes?


Everyone who uses it. That is what it is for, to let someone on a network
execute applications on the server machine. I'd suggest you do some
research
on WTS/Citrix, Don, because the one making a fool of himself in public is
you.
surprize now mr larry linson bfd. no
need for wts or citrix if you make 1000s
copy of mde in 1000s folders on server!


WTS/Citrix allows executing the MDE _on the server_, and allows a user
with
a relatively slow (e.g., Internet) connection to run Access remotely. If
there was a sufficiently fast LAN, a user could execute an MDE that is
stored on the server, but it would execute on the user's own machine.

Thanks for showing your ignorance and, thus, giving me an opportunity to
explain WTS/Citrix, Don. If you don't believe this, do your own
research --
it is obvious that you have neither used or learned WTS/Citrix.

not so rapid before you getaway mr larry linson. i call you bob now ok?

you tell poor poster

"if running WTS or Citrix to
execute the Access clients on the server, still give each user their own
copy in separate folders."

is wrong bob. is only one copy mde needed under wts/citrix. 1000s users no
problem bob. wts/citrix make 1000s instance one mde for 1000s users yes?.
ok bob? you take nappy now please.

*Sherwood Wang MVP*
Nov 13 '05 #14

P: n/a
It is a sad, sad day when someone who knows better goes out of his way to
try to mislead people here, instead of helping them. I hope the OP was not a
newby, and recognized trollery for what it is.

You are disgusting, Don, really disgusting.

Nov 13 '05 #15

P: n/a
"Sherwood Wang" <sh****@waynesworld.net> wrote:
is wrong bob. is only one copy mde needed under wts/citrix. 1000s users no
problem bob. wts/citrix make 1000s instance one mde for 1000s users yes?.
ok bob? you take nappy now please.


Don

Not only are you wrong you are insulting non native English speakers around the
world.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #16

P: n/a

is so very true all ways yes?

Here comes Larry without a clue
Here comes Tony and Davey too
It's finger flip flippin' time
They think they're smart
And that's a real bad start

*Sherwood Wang MVP*
Nov 13 '05 #17

P: n/a

"Sherwood Wang" <sh****@waynesworld.net> wrote in message
news:1095994881.2uMbrW7PuTs9i76nSZE+hw@teranews...

"Larry Linson" <bo*****@localhost.not> wrote in message
news:22I4d.9673$2A1.6044@trnddc08...
"Sherwood Wang" <sh****@waynesworld.net> wrote > most
> what people use metaframe sofware
> as server please? stupid people like you
> yes?


Everyone who uses it. That is what it is for, to let someone on a network
execute applications on the server machine. I'd suggest you do some
research
on WTS/Citrix, Don, because the one making a fool of himself in public is
you.
> surprize now mr larry linson bfd. no
> need for wts or citrix if you make 1000s
> copy of mde in 1000s folders on server!


WTS/Citrix allows executing the MDE _on the server_, and allows a user
with
a relatively slow (e.g., Internet) connection to run Access remotely. If
there was a sufficiently fast LAN, a user could execute an MDE that is
stored on the server, but it would execute on the user's own machine.

Thanks for showing your ignorance and, thus, giving me an opportunity to
explain WTS/Citrix, Don. If you don't believe this, do your own
research --
it is obvious that you have neither used or learned WTS/Citrix.

not so rapid before you getaway mr larry linson. i call you bob now ok?

you tell poor poster

"if running WTS or Citrix to
execute the Access clients on the server, still give each user their own
copy in separate folders."

is wrong bob. is only one copy mde needed under wts/citrix. 1000s users
no problem bob. wts/citrix make 1000s instance one mde for 1000s users
yes?. ok bob? you take nappy now please.

*Sherwood Wang MVP*

You're right Sherwood (Don?) as Arvin Meyer already pointed out. Only one
copy of the FE MDE is required for Terminal Server to handle all client
requests. The idea suggested by Larry and Tony--creating one copy of the FE
MDE in a separate folder for every client--is ridiculous. Terminal Server
creates instances (copies) of the FE MDE in memory on an as-needed basis,
one for each client session. So what they say is totally crazy.

And how do they know who the (next) client will be? And how do they set up
all these FE MDE copies and folders with hundreds of different clients
coming and going every hour or every minute?

I can imagine Larry and Tony deploying an Access FE upgrade! So much for
single-point application maintenance!

Larry and Tony obviously don't understand application server technology.
(Personally I think they're nutty as squirrels.) Based on what I've read
here, I wouldn't let these guys change the oil in my lawn mower nevertheless
work on my server.

Stick to your guns Sherwood. And work on your English.

PJ
Nov 13 '05 #18

P: n/a
"Pop Jay" <no*****@nothing.com> wrote:
Message-ID: <1096065045.2emDrONNeEx1Si5HU8dNyg@teranews>
X-Abuse-Report: http://www.usenetabuse.com
The origin of this posting is highly suspicious. Nevertheless it is a good posting
and I will treat it accordingly.
You're right Sherwood (Don?) as Arvin Meyer already pointed out.
Except that posting was not by Arvin Meyer but was a forgery.
Only one
copy of the FE MDE is required for Terminal Server to handle all client
requests. The idea suggested by Larry and Tony--creating one copy of the FE
MDE in a separate folder for every client--is ridiculous. Terminal Server
creates instances (copies) of the FE MDE in memory on an as-needed basis,
one for each client session. So what they say is totally crazy.
The problem still is that Access will update/lock objects in the FE MDE/MDB thus
leading to greatly increased chances of corruptions.

Access does not work the same way as a .exe in that respect.
And how do they know who the (next) client will be? And how do they set up
all these FE MDE copies and folders with hundreds of different clients
coming and going every hour or every minute?

I can imagine Larry and Tony deploying an Access FE upgrade! So much for
single-point application maintenance!


Exceedingly easy with the Auto FE Updater. Set it up and forget about it.

I specifically created the Auto FE Updater utility so that I could make changes to
the FE MDE as often as I wanted and be quite confident that the next time someone
went to run the app that it would pull in the latest version. For more info on the
errors or the Auto FE Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the FE on each PC up
to date.

In a Terminal Server or Citrix environment the Auto FE Updater now supports creating
a directory named after the user on a server. Given a choice put the FE on the
Citrix server to reduce network traffic and to avoid having to load objects over the
network which can be somewhat sluggish.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #19

P: n/a

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:pe********************************@4ax.com...
"Pop Jay" <no*****@nothing.com> wrote:
Only one
copy of the FE MDE is required for Terminal Server to handle all client
requests. The idea suggested by Larry and Tony--creating one copy of the
FE
MDE in a separate folder for every client--is ridiculous. Terminal Server
creates instances (copies) of the FE MDE in memory on an as-needed basis,
one for each client session. So what they say is totally crazy.
The problem still is that Access will update/lock objects in the FE
MDE/MDB thus
leading to greatly increased chances of corruptions.

Nonsense. Unless you are putting tables in your FE's, which is wrong. But
I wouldn't put it past you after what you've said in this thread.

Access does not work the same way as a .exe in that respect.
And how do they know who the (next) client will be? And how do they set
up
all these FE MDE copies and folders with hundreds of different clients
coming and going every hour or every minute?

I can imagine Larry and Tony deploying an Access FE upgrade! So much for
single-point application maintenance!
Exceedingly easy with the Auto FE Updater. Set it up and forget about
it.

I specifically created the Auto FE Updater utility so that I could make
changes to
the FE MDE as often as I wanted and be quite confident that the next time
someone
went to run the app that it would pull in the latest version. In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating
a directory named after the user on a server. Given a choice put the FE
on the
Citrix server to reduce network traffic and to avoid having to load
objects over the
network which can be somewhat sluggish.

You don't get it, do you? ONE FE. Not some indeterminate number of FE's
saved in some indeterminate number of folders, with each folder named after
a client user that may never be seen again.

Your moronic scheme defeats the whole purpose of an application server.

But you don't get it because you never worked in a large-scale application
server environment that handles thousands of client sessions per day. Any
sys admin would kick you and your silly "Auto FE Updater" off the server so
quick your head would spin.

PJ



Nov 13 '05 #20

P: n/a

"Pop Jay" <no*****@nothing.com> wrote in message
news:1096072728.Rj5iJAZz8vwj7FPBnB6yWg@teranews...

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:pe********************************@4ax.com...
"Pop Jay" <no*****@nothing.com> wrote:
Only one
copy of the FE MDE is required for Terminal Server to handle all client
requests. The idea suggested by Larry and Tony--creating one copy of the
FE
MDE in a separate folder for every client--is ridiculous. Terminal
Server
creates instances (copies) of the FE MDE in memory on an as-needed basis,
one for each client session. So what they say is totally crazy.


The problem still is that Access will update/lock objects in the FE
MDE/MDB thus
leading to greatly increased chances of corruptions.

Nonsense. Unless you are putting tables in your FE's, which is wrong.
But I wouldn't put it past you after what you've said in this thread.

Access does not work the same way as a .exe in that respect.
And how do they know who the (next) client will be? And how do they set
up
all these FE MDE copies and folders with hundreds of different clients
coming and going every hour or every minute?

I can imagine Larry and Tony deploying an Access FE upgrade! So much for
single-point application maintenance!

Exceedingly easy with the Auto FE Updater. Set it up and forget about
it.

I specifically created the Auto FE Updater utility so that I could make
changes to
the FE MDE as often as I wanted and be quite confident that the next time
someone
went to run the app that it would pull in the latest version.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating
a directory named after the user on a server. Given a choice put the FE
on the
Citrix server to reduce network traffic and to avoid having to load
objects over the
network which can be somewhat sluggish.

You don't get it, do you? ONE FE. Not some indeterminate number of FE's
saved in some indeterminate number of folders, with each folder named
after a client user that may never be seen again.

Your moronic scheme defeats the whole purpose of an application server.

But you don't get it because you never worked in a large-scale application
server environment that handles thousands of client sessions per day.
Any sys admin would kick you and your silly "Auto FE Updater" off the
server so quick your head would spin.

PJ

is not use mr pop jay. all morons all time as they say yes?

*Sherwood Wang MVP*

Nov 13 '05 #21

P: n/a
Poor Don. Poor, poor pitiful Don.

He can't get anyone to agree with his sockpuppets except his other
sockpuppets. And Don is using his sockpuppets to deliberately try to mislead
participants here. He even goes to the extent of impersonating Arvin Meyer,
an MVP (a group which Don does not like, in the least, but whose credibility
he is perfectly willing to trade on... as in "Sherwood Wang MVP" and forging
Arvin's name and title).


"Sherwood Wang" <sh****@waynesworld.com> wrote in message
news:1096082484.0u8k3JtCxhqzsJuoQbxmfw@teranews...

"Pop Jay" <no*****@nothing.com> wrote in message
news:1096072728.Rj5iJAZz8vwj7FPBnB6yWg@teranews...

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:pe********************************@4ax.com...
"Pop Jay" <no*****@nothing.com> wrote:

Only one
copy of the FE MDE is required for Terminal Server to handle all client
requests. The idea suggested by Larry and Tony--creating one copy of theFE
MDE in a separate folder for every client--is ridiculous. Terminal
Server
creates instances (copies) of the FE MDE in memory on an as-needed basis,one for each client session. So what they say is totally crazy.

The problem still is that Access will update/lock objects in the FE
MDE/MDB thus
leading to greatly increased chances of corruptions.

Nonsense. Unless you are putting tables in your FE's, which is wrong.
But I wouldn't put it past you after what you've said in this thread.

Access does not work the same way as a .exe in that respect.

And how do they know who the (next) client will be? And how do they setup
all these FE MDE copies and folders with hundreds of different clients
coming and going every hour or every minute?

I can imagine Larry and Tony deploying an Access FE upgrade! So much forsingle-point application maintenance!

Exceedingly easy with the Auto FE Updater. Set it up and forget about
it.

I specifically created the Auto FE Updater utility so that I could make
changes to
the FE MDE as often as I wanted and be quite confident that the next time someone
went to run the app that it would pull in the latest version.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating
a directory named after the user on a server. Given a choice put the FE on the
Citrix server to reduce network traffic and to avoid having to load
objects over the
network which can be somewhat sluggish.

You don't get it, do you? ONE FE. Not some indeterminate number of FE's saved in some indeterminate number of folders, with each folder named
after a client user that may never be seen again.

Your moronic scheme defeats the whole purpose of an application server.

But you don't get it because you never worked in a large-scale application server environment that handles thousands of client sessions per day.
Any sys admin would kick you and your silly "Auto FE Updater" off the
server so quick your head would spin.

PJ

is not use mr pop jay. all morons all time as they say yes?

*Sherwood Wang MVP*

Nov 13 '05 #22

P: n/a
"Pop Jay" <no*****@nothing.com> wrote:
Only one
copy of the FE MDE is required for Terminal Server to handle all client
requests. The idea suggested by Larry and Tony--creating one copy of the
FE
MDE in a separate folder for every client--is ridiculous. Terminal Server
creates instances (copies) of the FE MDE in memory on an as-needed basis,
one for each client session. So what they say is totally crazy.
The problem still is that Access will update/lock objects in the FE
MDE/MDB thus
leading to greatly increased chances of corruptions.

Nonsense.


<shrug> That's what happens. Open an MDE/MDB and open some forms and reports just
like a user would. Not in design mode. You will soon see the date/time of the
MDB/MDE change.
Unless you are putting tables in your FE's, which is wrong. But
I wouldn't put it past you after what you've said in this thread.
<sigh> Don't make such assumptions.

See the TempTables.MDB page at my website which illustrates how to use a temporary
MDB in your app. http://www.granite.ab.ca/access/temptables.htm Which has existed
on my website for a few years.
You don't get it, do you? ONE FE.
Yes, I do get it. You run a greatly increased chance of corrupting the FE MDB/MDE.
Sharing the FE MDB/MDE works for some people but definitely not others.
Not some indeterminate number of FE's
saved in some indeterminate number of folders, with each folder named after
a client user that may never be seen again.

Your moronic scheme defeats the whole purpose of an application server.
No, it's a work around for how Access works.
But you don't get it because you never worked in a large-scale application
server environment that handles thousands of client sessions per day.
Correct. I haven't worked in such an environment. If this works for you then I'm
happy for you.
Any
sys admin would kick you and your silly "Auto FE Updater" off the server so
quick your head would spin.


Then the sys admin will have to deal with the problems.

In the future please avoid the use of derogatory phrases such as "You don't get it,
do you? ", "moronic", and "silly". They don't do much for your image.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #23

P: n/a
pitiful is facts ==>

mr larry linson bfd making very bad advice
mr larry linson bfd making lies hiding very bad advice
mr larry linson bfd talking silly talk to arvin don what ever is wierd

*Sherwood Wang MVP*

"Larry Linson" <bo*****@localhost.not> wrote in message
news:6Y55d.609$ku4.294@trnddc01...
Poor Don. Poor, poor pitiful Don.

He can't get anyone to agree with his sockpuppets except his other
sockpuppets. And Don is using his sockpuppets to deliberately try to
mislead
participants here. He even goes to the extent of impersonating Arvin
Meyer,
an MVP (a group which Don does not like, in the least, but whose
credibility
he is perfectly willing to trade on... as in "Sherwood Wang MVP" and
forging
Arvin's name and title).


"Sherwood Wang" <sh****@waynesworld.com> wrote in message
news:1096082484.0u8k3JtCxhqzsJuoQbxmfw@teranews...

"Pop Jay" <no*****@nothing.com> wrote in message
news:1096072728.Rj5iJAZz8vwj7FPBnB6yWg@teranews...
>
> "Tony Toews" <tt****@telusplanet.net> wrote in message
> news:pe********************************@4ax.com...
>> "Pop Jay" <no*****@nothing.com> wrote:
>>
>>>Only one
>>>copy of the FE MDE is required for Terminal Server to handle all
>>>client
>>>requests. The idea suggested by Larry and Tony--creating one copy of the >>>FE
>>>MDE in a separate folder for every client--is ridiculous. Terminal
>>>Server
>>>creates instances (copies) of the FE MDE in memory on an as-needed basis, >>>one for each client session. So what they say is totally crazy.
>>
>> The problem still is that Access will update/lock objects in the FE
>> MDE/MDB thus
>> leading to greatly increased chances of corruptions.
>
>
> Nonsense. Unless you are putting tables in your FE's, which is wrong.
> But I wouldn't put it past you after what you've said in this thread.
>
>
>
>>
>> Access does not work the same way as a .exe in that respect.
>>
>>>And how do they know who the (next) client will be? And how do they set >>>up
>>>all these FE MDE copies and folders with hundreds of different clients
>>>coming and going every hour or every minute?
>>>
>>>I can imagine Larry and Tony deploying an Access FE upgrade! So much for >>>single-point application maintenance!
>
>> Exceedingly easy with the Auto FE Updater. Set it up and forget
>> about
>> it.
>>
>> I specifically created the Auto FE Updater utility so that I could
>> make
>> changes to
>> the FE MDE as often as I wanted and be quite confident that the next time >> someone
>> went to run the app that it would pull in the latest version.
>
>> In a Terminal Server or Citrix environment the Auto FE Updater now
>> supports creating
>> a directory named after the user on a server. Given a choice put the FE >> on the
>> Citrix server to reduce network traffic and to avoid having to load
>> objects over the
>> network which can be somewhat sluggish.
>
>
> You don't get it, do you? ONE FE. Not some indeterminate number of FE's > saved in some indeterminate number of folders, with each folder named
> after a client user that may never be seen again.
>
> Your moronic scheme defeats the whole purpose of an application server.
>
> But you don't get it because you never worked in a large-scale application > server environment that handles thousands of client sessions per day.
> Any sys admin would kick you and your silly "Auto FE Updater" off the
> server so quick your head would spin.
>
> PJ
>

is not use mr pop jay. all morons all time as they say yes?

*Sherwood Wang MVP*


Nov 13 '05 #24

P: n/a
Tony Toews <tt****@telusplanet.net> wrote in
news:nq********************************@4ax.com:
"Pop Jay" <no*****@nothing.com> wrote:
[Tony:]
The problem still is that Access will update/lock objects in the
FE MDE/MDB thus
leading to greatly increased chances of corruptions.


Nonsense.


<shrug> That's what happens. Open an MDE/MDB and open some forms
and reports just
like a user would. Not in design mode. You will soon see the
date/time of the MDB/MDE change.


Forms, reports and queries are all stored in Jet tables, so the fact
that you don't have any *application* data in your front end does
not mean that there are not Jet tables in the front end that get
updated.

Anyone who has actually ever attempted to share an A2K front end
among multiple users would know this.

And, Tony, you should dismiss all the criticisms based on
"large-scale application server environments." If "Pop Jay" had ever
worked in one and deployed a single shared front end, he'd have been
fired.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #25

P: n/a
To find out more about Terminal Server with Access, go to
Google like this:
http://groups.google.com/groups?q=mi....public.access

and search the microsoft.public.access news groups. You
may also wish to visit Tony's web site, or search the
microsoft.public.access news groups, in order to form
an opinion about Tony's authority and competency. For a
list of Microsoft MVP's, go to this site:
http://mvp.support.microsoft.com/def...m%20-%20Access

(david)
"Pop Jay" <no*****@nothing.com> wrote in message
news:1096072728.Rj5iJAZz8vwj7FPBnB6yWg@teranews...

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:pe********************************@4ax.com...
"Pop Jay" <no*****@nothing.com> wrote:

requests. The idea suggested by Larry and Tony--creating one copy of
MDE in a separate folder for every client--is ridiculous. Terminal

Nonsense. Unless you are putting tables in your FE's, which is wrong.

But
Nov 13 '05 #26

P: n/a
"Nomen Nescio" <no****@dizum.com> wrote in message
news:39******************************@dizum.com...
Say, Larry, is there a who's who of
MVP's anywhere on the net? It would
be nice to be able to lookup one's
favorite MVP and find out where they
live and what they do for a living, even
their net worth.

You know, kinda like the Forbes
billionaire list.


I've heard there is a "Trollhunter's Guide", summarizing the open seasons,
bag limits, etc. for various jurisdictions, and with a guide to likely
habitats.
Nov 13 '05 #27

This discussion thread is closed

Replies have been disabled for this discussion.