 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / General 1 / September 2004Access 2003 ODBC Problem
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. 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 > 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 [quoted text clipped - 6 lines] > drivers? The File DSN tab has different lists on the 10 machines, so > I'm not sure what to do with this. >if running WTS or Citrix to > execute the Access clients on the server, still give each user their own > copy in separate folders. mr larry linson you make nonesence! is dumbest thing i hear! we do 100s access ts clients all from 1 mde ok? *Sherwood Wang MVP* (is also sys eng, bs, ms) > 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 [quoted text clipped - 15 lines] > 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 >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 >> 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 [quoted text clipped - 26 lines] > > 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* The resident troll, forging a post as though it were from > 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. > The resident troll, forging a post as though it were from > [quoted text clipped - 18 lines] > 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? "Sherwood Wang" <shwang@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. > "Sherwood Wang" <shwang@waynesworld.net> wrote > most > [quoted text clipped - 22 lines] > 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* 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. >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 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* >> "Sherwood Wang" <shwang@waynesworld.net> wrote > most >> [quoted text clipped - 36 lines] > > *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 >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 >>Only one >>copy of the FE MDE is required for Terminal Server to handle all client [quoted text clipped - 7 lines] > 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. > [quoted text clipped - 5 lines] >>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. [quoted text clipped - 4 lines] > 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 [quoted text clipped - 3 lines] > 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 >>>Only one >>>copy of the FE MDE is required for Terminal Server to handle all client [quoted text clipped - 51 lines] > > PJ is not use mr pop jay. all morons all time as they say yes? *Sherwood Wang MVP* 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). > >>>Only one > >>>copy of the FE MDE is required for Terminal Server to handle all client [quoted text clipped - 55 lines] > > *Sherwood Wang MVP* 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. > Poor Don. Poor, poor pitiful Don. > [quoted text clipped - 72 lines] > > > > *Sherwood Wang MVP* > Say, Larry, is there a who's who of > MVP's anywhere on the net? It would [quoted text clipped - 5 lines] > 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. 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* > Poor Don. Poor, poor pitiful Don. > [quoted text clipped - 79 lines] >> >> *Sherwood Wang MVP* >>>Only one >>>copy of the FE MDE is required for Terminal Server to handle all client [quoted text clipped - 9 lines] > >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 > >>>Only one > >>>copy of the FE MDE is required for Terminal Server to handle all client [quoted text clipped - 50 lines] > 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. But Tony, there are no others words to describe what you and your buddy Larry have suggested. You and Larry are amateurs. Indeed, Larry wears the amateur badge "MVP". Isn't Tony long overdue in getting his "MVP" amateur badge also? >>[Tony:] >>> The problem still is that Access will update/lock objects in the [quoted text clipped - 7 lines] > 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.  SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc To find out more about Terminal Server with Access, go to Google like this: http://groups.google.com/groups?q=microsoft.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/default.aspx?scid=fh;EN-US;mvpaward&style=TOC#O ffice%20System%20-%20Access (david) > >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 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) > 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 [quoted text clipped - 6 lines] > drivers? The File DSN tab has different lists on the 10 machines, so > I'm not sure what to do with this. >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.steele/DSNLessLinks.html ODBC DSN-Less Connection Tutorial Part I http://www.amazecreations.com/datafast/GetFile.aspx?file=ODBCTutor01.htm&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/ADO/Connection/ODBC_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 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.