If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Mr. Kallal & Mr. Fenton: What did I do wrong?
Pls, could you check up
http://groups.google.co.uk/group/mic...2fcbeceb22ac0? According to your comments I must have done something wrong, but I don't know what. Pls, answer in this newsgroup. TIA Vlado |
#2
|
|||
|
|||
Persistanct connections
For a post that is 5 days old, it certainly not considered rude to start
another post/thread.. I not sure why my name is mentioned here....as I don't see my participation in that previous thread.... To test a persistent connection, simply open up your front end, and then open ANY table (use the tables tab). Simply double click on any linked tabled. So, you are now viewing data in a linked table. Now, minimize the table.... Now, launch your applications main form..and see if the application runs faster. If it runs faster, then the persistent connection is helping, if the application does not improve, then the persistent connection did not help. Remember, a persist connection is simply to FORCE and KEEP open the back end database AT ALL TIMES. So, if you simply launch the front end, and then simply click on a linked table in the table tab to open and view the data in a table (that is linked), you have a persistent connection. DO NOT close this table...but simply minimize it..and then see if performance improve. If the performance does improve, then you can consider writing some code in your start-up code that forces open a persistent connection. however, you don't need to write, or test, or build some code...just click on a table to open it (you do this in the front end). Keep the table open..and then simply then try your main form etc to see if it runs faster. You don't have to write code to test this you ONLY need some code AFTER you tested this....... However, as a general rule, I always do create a persistent connection, as on some networks..it don't make a difference, but on others...it makes a HUGE difference. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#3
|
|||
|
|||
Persistanct connections
Hello,
TYVM for your respond. I've mentioned you because you have posted something about persistent connection (PeCo) in one of previous threads: http://www.developerfood.com/re-spli...9/article.aspx. Pls, could you check up my scenario and tell me if there was something wrong. In that case, PeCo didn't help at all and that's why I thouhgt that PeCo was just a myth. But after that discussion I googled the web and went to my old code... and tried to check up what was wrong. IMO, my scenario seems to be OK. Long time ago I've "discovered" that if I ran Word or Excel and then opened an A97 app, Access performed very slow until I closed the other MSO apps. I'm not sure if it's the same in US (EN) release of Access - I use Czech version. There may be some unknown language issues... as there's at least one known "language issue" in A2002, see http://groups.google.co.uk/group/mic...25ddb44d18b76b. At the moment I'm trying to collect as most information on PeCo as I can. I appreciate any comments. TIA Vlado "Albert D. Kallal" píše v diskusním příspěvku ... For a post that is 5 days old, it certainly not considered rude to start another post/thread.. I not sure why my name is mentioned here....as I don't see my participation in that previous thread.... To test a persistent connection, simply open up your front end, and then open ANY table (use the tables tab). Simply double click on any linked tabled. So, you are now viewing data in a linked table. Now, minimize the table.... Now, launch your applications main form..and see if the application runs faster. If it runs faster, then the persistent connection is helping, if the application does not improve, then the persistent connection did not help. Remember, a persist connection is simply to FORCE and KEEP open the back end database AT ALL TIMES. So, if you simply launch the front end, and then simply click on a linked table in the table tab to open and view the data in a table (that is linked), you have a persistent connection. DO NOT close this table...but simply minimize it..and then see if performance improve. If the performance does improve, then you can consider writing some code in your start-up code that forces open a persistent connection. however, you don't need to write, or test, or build some code...just click on a table to open it (you do this in the front end). Keep the table open..and then simply then try your main form etc to see if it runs faster. You don't have to write code to test this you ONLY need some code AFTER you tested this....... However, as a general rule, I always do create a persistent connection, as on some networks..it don't make a difference, but on others...it makes a HUGE difference. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#4
|
|||
|
|||
Persistanct connections
IMO, with persistent connection it's quite qifficult to check up if MDB is
open or not, see http://groups.google.co.uk/group/mic...63d55d37251713. Vlado "Albert D. Kallal" píše v diskusním příspěvku ... For a post that is 5 days old, it certainly not considered rude to start another post/thread.. I not sure why my name is mentioned here....as I don't see my participation in that previous thread.... To test a persistent connection, simply open up your front end, and then open ANY table (use the tables tab). Simply double click on any linked tabled. So, you are now viewing data in a linked table. Now, minimize the table.... Now, launch your applications main form..and see if the application runs faster. If it runs faster, then the persistent connection is helping, if the application does not improve, then the persistent connection did not help. Remember, a persist connection is simply to FORCE and KEEP open the back end database AT ALL TIMES. So, if you simply launch the front end, and then simply click on a linked table in the table tab to open and view the data in a table (that is linked), you have a persistent connection. DO NOT close this table...but simply minimize it..and then see if performance improve. If the performance does improve, then you can consider writing some code in your start-up code that forces open a persistent connection. however, you don't need to write, or test, or build some code...just click on a table to open it (you do this in the front end). Keep the table open..and then simply then try your main form etc to see if it runs faster. You don't have to write code to test this you ONLY need some code AFTER you tested this....... However, as a general rule, I always do create a persistent connection, as on some networks..it don't make a difference, but on others...it makes a HUGE difference. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#5
|
|||
|
|||
Persistanct connections - ooops
qifficult - difficult
"Vladimír Cvajniga" píše v diskusním příspěvku ... IMO, with persistent connection it's quite qifficult to check up if MDB is open or not, see http://groups.google.co.uk/group/mic...63d55d37251713. Vlado "Albert D. Kallal" píše v diskusním příspěvku ... For a post that is 5 days old, it certainly not considered rude to start another post/thread.. I not sure why my name is mentioned here....as I don't see my participation in that previous thread.... To test a persistent connection, simply open up your front end, and then open ANY table (use the tables tab). Simply double click on any linked tabled. So, you are now viewing data in a linked table. Now, minimize the table.... Now, launch your applications main form..and see if the application runs faster. If it runs faster, then the persistent connection is helping, if the application does not improve, then the persistent connection did not help. Remember, a persist connection is simply to FORCE and KEEP open the back end database AT ALL TIMES. So, if you simply launch the front end, and then simply click on a linked table in the table tab to open and view the data in a table (that is linked), you have a persistent connection. DO NOT close this table...but simply minimize it..and then see if performance improve. If the performance does improve, then you can consider writing some code in your start-up code that forces open a persistent connection. however, you don't need to write, or test, or build some code...just click on a table to open it (you do this in the front end). Keep the table open..and then simply then try your main form etc to see if it runs faster. You don't have to write code to test this you ONLY need some code AFTER you tested this....... However, as a general rule, I always do create a persistent connection, as on some networks..it don't make a difference, but on others...it makes a HUGE difference. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#6
|
|||
|
|||
Persistanct connections
"Vladimír Cvajniga" wrote in message
... IMO, with persistent connection it's quite qifficult to check up if MDB is open or not, see http://groups.google.co.uk/group/mic...63d55d37251713. Why do we have to check anything? Just click on a table to open it..and then minimize it...you are done!!!! Nothing more complex to test here....... If you find the above helps, then of course you can write some code to keep the back end open, but you don't actually have to write any code to test this. I don't think it is a huge complex problem to double click on a table, and then minimize it (if that is too hard..then time for a coffee break!!). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#7
|
|||
|
|||
Persistanct connections
Thank you very much for your input, Mr. Kallal. You are #1!
V. "Albert D. Kallal" píše v diskusním příspěvku ... "Vladimír Cvajniga" wrote in message ... IMO, with persistent connection it's quite qifficult to check up if MDB is open or not, see http://groups.google.co.uk/group/mic...63d55d37251713. Why do we have to check anything? Just click on a table to open it..and then minimize it...you are done!!!! Nothing more complex to test here....... If you find the above helps, then of course you can write some code to keep the back end open, but you don't actually have to write any code to test this. I don't think it is a huge complex problem to double click on a table, and then minimize it (if that is too hard..then time for a coffee break!!). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#8
|
|||
|
|||
Persistanct connections
#1 in NOT being helpful...
I thougth all MVPs were professionals. Unfortunatelly, some of them don't seem to... :-( V. "Vladimír Cvajniga" píše v diskusním příspěvku ... Thank you very much for your input, Mr. Kallal. You are #1! V. "Albert D. Kallal" píše v diskusním příspěvku ... "Vladimír Cvajniga" wrote in message ... IMO, with persistent connection it's quite qifficult to check up if MDB is open or not, see http://groups.google.co.uk/group/mic...63d55d37251713. Why do we have to check anything? Just click on a table to open it..and then minimize it...you are done!!!! Nothing more complex to test here....... If you find the above helps, then of course you can write some code to keep the back end open, but you don't actually have to write any code to test this. I don't think it is a huge complex problem to double click on a table, and then minimize it (if that is too hard..then time for a coffee break!!). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#9
|
|||
|
|||
Persistanct connections
#1 in NOT being helpful...
I thougth all MVPs were professionals. Unfortunatelly, some of them don't seem to... :-( V. "Vladimír Cvajniga" píše v diskusním příspěvku ... Thank you very much for your input, Mr. Kallal. You are #1! V. "Albert D. Kallal" píše v diskusním příspěvku ... "Vladimír Cvajniga" wrote in message ... IMO, with persistent connection it's quite qifficult to check up if MDB is open or not, see http://groups.google.co.uk/group/mic...63d55d37251713. Why do we have to check anything? Just click on a table to open it..and then minimize it...you are done!!!! Nothing more complex to test here....... If you find the above helps, then of course you can write some code to keep the back end open, but you don't actually have to write any code to test this. I don't think it is a huge complex problem to double click on a table, and then minimize it (if that is too hard..then time for a coffee break!!). -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
#10
|
|||
|
|||
Persistanct connections
VladimĂ*r -
I'm sorry to read that you feel this way. I have read the entire thread and, personally, I think Albert has been very helpful to you. It seems to me like you might be making this issue more difficult than it need be. Of course, I cannot talk about the Czech version of Access versus the English version, as I have no way of testing your version. The easiest way to verify a persistent connection is to make sure that you see a .ldb file created for the back-end (BE) database, as soon as you open your front-end (FE) database. Keep a small window open, using Windows Explorer, so that you can keep an eye on the .ldb file. If your BE is on a shared network, you need to do this verification test when you know that no other users have the BE file open. Also, do not press the shift key, when opening your FE database, because you do not want to bypass an Autoexec macro or any startup code. No matter what queries, forms or reports that you close, you should never witness the .ldb file for the BE database being deleted, as long as you have your FE database open. It's really that simple! In June, 2006, I gave a presentation to the Pacific Northwest Access Developer's Group titled "Analyzing Your Database with JetShowPlan". A part of this presentation included timing tests to run queries on a split Access application, with and without a persistant connection. I have included the applicable parts of this presentation in a .zip file, which I invite you to download and take a look at: http://home.comcast.net/~tutorme2/sa...ng_results.zip Tom Wickerath Microsoft Access MVP https://mvp.support.microsoft.com/profile/Tom http://www.access.qbuilt.com/html/ex...tributors.html __________________________________________ "VladimĂ*r Cvajniga" wrote: #1 in NOT being helpful... I thougth all MVPs were professionals. Unfortunatelly, some of them don't seem to... :-( V. |
Thread Tools | |
Display Modes | |
|
|