A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Mr. Kallal & Mr. Fenton: What did I do wrong?



 
 
Thread Tools Display Modes
  #1  
Old April 8th, 2007, 07:29 PM posted to microsoft.public.access
Vladimír Cvajniga[_2_]
external usenet poster
 
Posts: 82
Default 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  
Old April 8th, 2007, 09:07 PM posted to microsoft.public.access
Albert D. Kallal
external usenet poster
 
Posts: 2,874
Default 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  
Old April 8th, 2007, 10:06 PM posted to microsoft.public.access
Vladimír Cvajniga[_2_]
external usenet poster
 
Posts: 82
Default 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  
Old April 8th, 2007, 10:13 PM posted to microsoft.public.access
Vladimír Cvajniga[_2_]
external usenet poster
 
Posts: 82
Default 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  
Old April 8th, 2007, 10:16 PM posted to microsoft.public.access
Vladimír Cvajniga[_2_]
external usenet poster
 
Posts: 82
Default 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  
Old April 8th, 2007, 10:24 PM posted to microsoft.public.access
Albert D. Kallal
external usenet poster
 
Posts: 2,874
Default 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  
Old April 8th, 2007, 10:42 PM posted to microsoft.public.access
Vladimír Cvajniga[_2_]
external usenet poster
 
Posts: 82
Default 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  
Old April 8th, 2007, 10:47 PM posted to microsoft.public.access
Vladimír Cvajniga[_2_]
external usenet poster
 
Posts: 82
Default 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  
Old April 8th, 2007, 11:07 PM posted to microsoft.public.access
Vladimír Cvajniga[_2_]
external usenet poster
 
Posts: 82
Default 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  
Old April 9th, 2007, 12:08 AM posted to microsoft.public.access
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 07:22 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.