473,881 Members | 1,759 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Form Slow, Then Fast

I have a very puzzling situation with a database. It's an Access 2000 mdb
with a SQL 7 back end, with forms bound using ODBC linked tables. At our
remote location (accessed via a T1 line) the time it took to go to a record
was very slow. The go to mechanism was a box that the user typed the index
value into a combo box, with very simple code attached:

with me.RecordsetClo ne
.FindFirst "[Index] = " & me.cboGoTo
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
end with

Now, one would say that going to a record is slow because I'm using
..FindFirst over a T1 line. And that's what I thought. However, as I was
working with the form, commenting out various sections not related to the Go
To, I found that the Go To functionality changed, though I didn't modify the
code.

Previously, going to a record near the end of the 50,000 record recordset
took about 1-2 seconds, but going to a record near the beginning, took about
20 seconds. After the form changed, going to any record in the recordset
took about 1-2 seconds.

So the question remains: why did it take so long to go to a record near the
beginning of the recordset, but not near the end (and the ones in the middle
took an amount of time about halfway between the two), and what changed so
that now the form is working fine for all records?

I've compared the changed form with the previous copy, and I don't see any
differences. I've compared all code in the form module, and I've compared
all form properties. The forms are identical as far as I could tell. But
something happened as I was commenting/uncommenting code in the form that
got rid of the problem with it taking a long time to go to some of the
records.

My first thought was that something got recompiled, and now the form is
fast. So I went back to the original version and changed some code and
recompiled, also did a compact and repair. But it was still slow. I also
tried doing an explicit decompile and then recompiled it. But it was still
slow.

So this is very frustrating that the form is now working fine, but I can't
see anything that's changed. If I don't see why the form is now fast, then
there's no reason to believe that it might not at some point go back to
being slow again. And then I'd just have to hope that something changes. It
would be good to figure this out.

Any ideas as to what might have changed here to cause the form's Go To to be
fast would be appreciated.

Thanks,

Neil
Nov 13 '05 #1
8 1748
Hi

Could anyone (or a job) be affecting the backend?

John

"Neil" <no****@nospam. net> wrote in message
news:WA******** ********@newsre ad1.news.pas.ea rthlink.net...
I have a very puzzling situation with a database. It's an Access 2000 mdb
with a SQL 7 back end, with forms bound using ODBC linked tables. At our
remote location (accessed via a T1 line) the time it took to go to a record
was very slow. The go to mechanism was a box that the user typed the index
value into a combo box, with very simple code attached:

with me.RecordsetClo ne
.FindFirst "[Index] = " & me.cboGoTo
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
end with

Now, one would say that going to a record is slow because I'm using
.FindFirst over a T1 line. And that's what I thought. However, as I was
working with the form, commenting out various sections not related to the
Go To, I found that the Go To functionality changed, though I didn't
modify the code.

Previously, going to a record near the end of the 50,000 record recordset
took about 1-2 seconds, but going to a record near the beginning, took
about 20 seconds. After the form changed, going to any record in the
recordset took about 1-2 seconds.

So the question remains: why did it take so long to go to a record near
the beginning of the recordset, but not near the end (and the ones in the
middle took an amount of time about halfway between the two), and what
changed so that now the form is working fine for all records?

I've compared the changed form with the previous copy, and I don't see any
differences. I've compared all code in the form module, and I've compared
all form properties. The forms are identical as far as I could tell. But
something happened as I was commenting/uncommenting code in the form that
got rid of the problem with it taking a long time to go to some of the
records.

My first thought was that something got recompiled, and now the form is
fast. So I went back to the original version and changed some code and
recompiled, also did a compact and repair. But it was still slow. I also
tried doing an explicit decompile and then recompiled it. But it was still
slow.

So this is very frustrating that the form is now working fine, but I can't
see anything that's changed. If I don't see why the form is now fast, then
there's no reason to believe that it might not at some point go back to
being slow again. And then I'd just have to hope that something changes.
It would be good to figure this out.

Any ideas as to what might have changed here to cause the form's Go To to
be fast would be appreciated.

Thanks,

Neil

Nov 13 '05 #2
Neil wrote:
I have a very puzzling situation with a database. It's an Access 2000 mdb
with a SQL 7 back end, with forms bound using ODBC linked tables. At our
remote location (accessed via a T1 line) the time it took to go to a record
was very slow. The go to mechanism was a box that the user typed the index
value into a combo box, with very simple code attached:

with me.RecordsetClo ne
.FindFirst "[Index] = " & me.cboGoTo
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
end with

Now, one would say that going to a record is slow because I'm using
.FindFirst over a T1 line. And that's what I thought. However, as I was
working with the form, commenting out various sections not related to the Go
To, I found that the Go To functionality changed, though I didn't modify the
code.

Previously, going to a record near the end of the 50,000 record recordset
took about 1-2 seconds, but going to a record near the beginning, took about
20 seconds. After the form changed, going to any record in the recordset
took about 1-2 seconds.

So the question remains: why did it take so long to go to a record near the
beginning of the recordset, but not near the end (and the ones in the middle
took an amount of time about halfway between the two), and what changed so
that now the form is working fine for all records?

I've compared the changed form with the previous copy, and I don't see any
differences. I've compared all code in the form module, and I've compared
all form properties. The forms are identical as far as I could tell. But
something happened as I was commenting/uncommenting code in the form that
got rid of the problem with it taking a long time to go to some of the
records.

My first thought was that something got recompiled, and now the form is
fast. So I went back to the original version and changed some code and
recompiled, also did a compact and repair. But it was still slow. I also
tried doing an explicit decompile and then recompiled it. But it was still
slow.

So this is very frustrating that the form is now working fine, but I can't
see anything that's changed. If I don't see why the form is now fast, then
there's no reason to believe that it might not at some point go back to
being slow again. And then I'd just have to hope that something changes. It
would be good to figure this out.

Any ideas as to what might have changed here to cause the form's Go To to be
fast would be appreciated.

Well, there may be lot's of reasons, but I didn't see
anything in your description that ruled out a first time
through delay. The first time you access the recordset may
require a bunch of connection activities to take place.
Another likely cause is that the first search fills the
memory cache so subsequent searches don't have to go back to
the server as often as the it did the first time. To
verify/refute this hypothesis, reboot your system between
each timing test.

Note that you can often avoid all this kind of stuff by
filtering the form's dataset instead of loading all the
records and then searching for the one you want, especially
if the filter field is indexed.

--
Marsh
MVP [MS Access]
Nov 13 '05 #3
The problem might actually be your combo box. The combo box holds locks on
the server side until its last record has been read. If you go to the last
row in the combo box (or ask for its list count in code) the locks are
released. If you don't access slowly populates list items in the background,
and can take a very long time to complete, even if the number of rows is
small, but especially if it is large.

On Sun, 16 Oct 2005 19:10:46 GMT, "Neil" <no****@nospam. net> wrote:
I have a very puzzling situation with a database. It's an Access 2000 mdb
with a SQL 7 back end, with forms bound using ODBC linked tables. At our
remote location (accessed via a T1 line) the time it took to go to a record
was very slow. The go to mechanism was a box that the user typed the index
value into a combo box, with very simple code attached:

with me.RecordsetClo ne
.FindFirst "[Index] = " & me.cboGoTo
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
end with

Now, one would say that going to a record is slow because I'm using
.FindFirst over a T1 line. And that's what I thought. However, as I was
working with the form, commenting out various sections not related to the Go
To, I found that the Go To functionality changed, though I didn't modify the
code.

Previously, going to a record near the end of the 50,000 record recordset
took about 1-2 seconds, but going to a record near the beginning, took about
20 seconds. After the form changed, going to any record in the recordset
took about 1-2 seconds.

So the question remains: why did it take so long to go to a record near the
beginning of the recordset, but not near the end (and the ones in the middle
took an amount of time about halfway between the two), and what changed so
that now the form is working fine for all records?

I've compared the changed form with the previous copy, and I don't see any
differences. I've compared all code in the form module, and I've compared
all form properties. The forms are identical as far as I could tell. But
something happened as I was commenting/uncommenting code in the form that
got rid of the problem with it taking a long time to go to some of the
records.

My first thought was that something got recompiled, and now the form is
fast. So I went back to the original version and changed some code and
recompiled, also did a compact and repair. But it was still slow. I also
tried doing an explicit decompile and then recompiled it. But it was still
slow.

So this is very frustrating that the form is now working fine, but I can't
see anything that's changed. If I don't see why the form is now fast, then
there's no reason to believe that it might not at some point go back to
being slow again. And then I'd just have to hope that something changes. It
would be good to figure this out.

Any ideas as to what might have changed here to cause the form's Go To to be
fast would be appreciated.

Thanks,

Neil


Nov 13 '05 #4
No, I've tried it too many times and at too many different times of day for
it to be environmental. The results are always the same: the old version of
the form takes 20-25 seconds to go to record 100, and it takes 1-2 seconds
to go to record 50,000 (with records between those two varying in times
proportionally) ; the new version of the form takes 1-2 seconds to go to any
record, even though I didn't explicitly change anything, and I cannot find
any differences between the two forms.

N

"John Bell" <jb************ @hotmail.com> wrote in message
news:43******** *************** @news.zen.co.uk ...
Hi

Could anyone (or a job) be affecting the backend?

John

"Neil" <no****@nospam. net> wrote in message
news:WA******** ********@newsre ad1.news.pas.ea rthlink.net...
I have a very puzzling situation with a database. It's an Access 2000 mdb
with a SQL 7 back end, with forms bound using ODBC linked tables. At our
remote location (accessed via a T1 line) the time it took to go to a
record was very slow. The go to mechanism was a box that the user typed
the index value into a combo box, with very simple code attached:

with me.RecordsetClo ne
.FindFirst "[Index] = " & me.cboGoTo
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
end with

Now, one would say that going to a record is slow because I'm using
.FindFirst over a T1 line. And that's what I thought. However, as I was
working with the form, commenting out various sections not related to the
Go To, I found that the Go To functionality changed, though I didn't
modify the code.

Previously, going to a record near the end of the 50,000 record recordset
took about 1-2 seconds, but going to a record near the beginning, took
about 20 seconds. After the form changed, going to any record in the
recordset took about 1-2 seconds.

So the question remains: why did it take so long to go to a record near
the beginning of the recordset, but not near the end (and the ones in the
middle took an amount of time about halfway between the two), and what
changed so that now the form is working fine for all records?

I've compared the changed form with the previous copy, and I don't see
any differences. I've compared all code in the form module, and I've
compared all form properties. The forms are identical as far as I could
tell. But something happened as I was commenting/uncommenting code in the
form that got rid of the problem with it taking a long time to go to some
of the records.

My first thought was that something got recompiled, and now the form is
fast. So I went back to the original version and changed some code and
recompiled, also did a compact and repair. But it was still slow. I also
tried doing an explicit decompile and then recompiled it. But it was
still slow.

So this is very frustrating that the form is now working fine, but I
can't see anything that's changed. If I don't see why the form is now
fast, then there's no reason to believe that it might not at some point
go back to being slow again. And then I'd just have to hope that
something changes. It would be good to figure this out.

Any ideas as to what might have changed here to cause the form's Go To to
be fast would be appreciated.

Thanks,

Neil


Nov 13 '05 #5
Well, there may be lot's of reasons, but I didn't see
anything in your description that ruled out a first time
through delay. The first time you access the recordset may
require a bunch of connection activities to take place.
Yes, I should have mentioned that I did these tests repeatedly to rule that
out: go to record 100 (very slow); then manually move back to the first
record; then go to record 100 (still very slow); then back to the first
record; then go to record 50,000 (very fast); then back to the first record;
then go to record 100 (very slow); etc.

I should have noted that. Sorry.
Another likely cause is that the first search fills the
memory cache so subsequent searches don't have to go back to
the server as often as the it did the first time. To
verify/refute this hypothesis, reboot your system between
each timing test.
How would that explain why it's very fast when going to a record at the end
of the set?

Note that you can often avoid all this kind of stuff by
filtering the form's dataset instead of loading all the
records and then searching for the one you want, especially
if the filter field is indexed.
Yes, indeed. This is something the client wants, though, as they like being
able to switch back and forth between form view and datasheet view.
Otherwise, yes, that would be a better way to go.

Thanks,

N

--
Marsh
MVP [MS Access]

Nov 13 '05 #6

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:ef******** *************** *********@4ax.c om...
The problem might actually be your combo box. The combo box holds locks
on
the server side until its last record has been read. If you go to the
last
row in the combo box (or ask for its list count in code) the locks are
released.
Well, I think you've hit the nail on the head. I tried it with a text box,
and the problem wasn't there. That also explains the last-fast-first-slow
phenomenon, which I found very puzzling. Thanks! (I have to admit that I
posted this sort of like a message in a bottle, without much hope that
anything would come from it. Needless to say, I'm overjoyed here.)
If you don't access slowly populates list items in the background,
and can take a very long time to complete, even if the number of rows is
small, but especially if it is large.
I think you forgot a noun or a verb in the above, so I don't really
understand what you're saying. Could you rephrase it?

I'll just note that I didn't consider the combo boxes because the two forms
were identical, and I didn't recall changing anything there. So when I
compared the two forms, I only compared the code modules and the form
properties. I didn't examine the combo box properties.

However, in light of the above, I took a closer look at the combo boxes,
since, even though your explanation makes sense, it doesn't explain why go
to's are always fast on the new version of the form, even with the combo box
there. So I took a look at the two combo boxes, and, on the new version of
the form, where there's no problem, that combo box is *not* set to limit to
list, whereas the original one was. (I must have changed it as I was working
with the form.) So, apparently, that's the difference.

To confirm this, I went into the new version of the form, set the combo to
limit to list, and, voila!, it was slow like the other. Then I changed it
back to not limit to list, and it was fast again.

So I'm relieved to know that it's not a gremlin that's causing this.

Thanks again for your help.

Neil


On Sun, 16 Oct 2005 19:10:46 GMT, "Neil" <no****@nospam. net> wrote:
I have a very puzzling situation with a database. It's an Access 2000 mdb
with a SQL 7 back end, with forms bound using ODBC linked tables. At our
remote location (accessed via a T1 line) the time it took to go to a
record
was very slow. The go to mechanism was a box that the user typed the index
value into a combo box, with very simple code attached:

with me.RecordsetClo ne
.FindFirst "[Index] = " & me.cboGoTo
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
end with

Now, one would say that going to a record is slow because I'm using
.FindFirst over a T1 line. And that's what I thought. However, as I was
working with the form, commenting out various sections not related to the
Go
To, I found that the Go To functionality changed, though I didn't modify
the
code.

Previously, going to a record near the end of the 50,000 record recordset
took about 1-2 seconds, but going to a record near the beginning, took
about
20 seconds. After the form changed, going to any record in the recordset
took about 1-2 seconds.

So the question remains: why did it take so long to go to a record near
the
beginning of the recordset, but not near the end (and the ones in the
middle
took an amount of time about halfway between the two), and what changed so
that now the form is working fine for all records?

I've compared the changed form with the previous copy, and I don't see any
differences . I've compared all code in the form module, and I've compared
all form properties. The forms are identical as far as I could tell. But
something happened as I was commenting/uncommenting code in the form that
got rid of the problem with it taking a long time to go to some of the
records.

My first thought was that something got recompiled, and now the form is
fast. So I went back to the original version and changed some code and
recompiled, also did a compact and repair. But it was still slow. I also
tried doing an explicit decompile and then recompiled it. But it was still
slow.

So this is very frustrating that the form is now working fine, but I can't
see anything that's changed. If I don't see why the form is now fast, then
there's no reason to believe that it might not at some point go back to
being slow again. And then I'd just have to hope that something changes.
It
would be good to figure this out.

Any ideas as to what might have changed here to cause the form's Go To to
be
fast would be appreciated.

Thanks,

Neil

Nov 13 '05 #7
On Sun, 16 Oct 2005 20:19:38 GMT, "Neil" <no****@nospam. net> wrote:

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:ef******* *************** **********@4ax. com...
The problem might actually be your combo box. The combo box holds locks
on
the server side until its last record has been read. If you go to the
last
row in the combo box (or ask for its list count in code) the locks are
released.
Well, I think you've hit the nail on the head. I tried it with a text box,
and the problem wasn't there. That also explains the last-fast-first-slow
phenomenon, which I found very puzzling. Thanks! (I have to admit that I
posted this sort of like a message in a bottle, without much hope that
anything would come from it. Needless to say, I'm overjoyed here.)
If you don't access slowly populates list items in the background,
and can take a very long time to complete, even if the number of rows is
small, but especially if it is large.


I think you forgot a noun or a verb in the above, so I don't really
understand what you're saying. Could you rephrase it?


I was missing a comma. To rephrase... If you don't read the whole list by
selecting the last row in the combo box or by getting its list count, Access
will slowly retrieve the combo box rows in the background, it may take a very
long time, and some locks will be held for duration. Locks can be held for a
long time even by combo boxes with fairly few rows.

I'll just note that I didn't consider the combo boxes because the two forms
were identical, and I didn't recall changing anything there. So when I
compared the two forms, I only compared the code modules and the form
properties. I didn't examine the combo box properties.

However, in light of the above, I took a closer look at the combo boxes,
since, even though your explanation makes sense, it doesn't explain why go
to's are always fast on the new version of the form, even with the combo box
there. So I took a look at the two combo boxes, and, on the new version of
the form, where there's no problem, that combo box is *not* set to limit to
list, whereas the original one was. (I must have changed it as I was working
with the form.) So, apparently, that's the difference.

To confirm this, I went into the new version of the form, set the combo to
limit to list, and, voila!, it was slow like the other. Then I changed it
back to not limit to list, and it was fast again.

So I'm relieved to know that it's not a gremlin that's causing this.

Thanks again for your help.

Neil


On Sun, 16 Oct 2005 19:10:46 GMT, "Neil" <no****@nospam. net> wrote:
I have a very puzzling situation with a database. It's an Access 2000 mdb
with a SQL 7 back end, with forms bound using ODBC linked tables. At our
remote location (accessed via a T1 line) the time it took to go to a
record
was very slow. The go to mechanism was a box that the user typed the index
value into a combo box, with very simple code attached:

with me.RecordsetClo ne
.FindFirst "[Index] = " & me.cboGoTo
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
end with

Now, one would say that going to a record is slow because I'm using
.FindFirst over a T1 line. And that's what I thought. However, as I was
working with the form, commenting out various sections not related to the
Go
To, I found that the Go To functionality changed, though I didn't modify
the
code.

Previously , going to a record near the end of the 50,000 record recordset
took about 1-2 seconds, but going to a record near the beginning, took
about
20 seconds. After the form changed, going to any record in the recordset
took about 1-2 seconds.

So the question remains: why did it take so long to go to a record near
the
beginning of the recordset, but not near the end (and the ones in the
middle
took an amount of time about halfway between the two), and what changed so
that now the form is working fine for all records?

I've compared the changed form with the previous copy, and I don't see any
difference s. I've compared all code in the form module, and I've compared
all form properties. The forms are identical as far as I could tell. But
something happened as I was commenting/uncommenting code in the form that
got rid of the problem with it taking a long time to go to some of the
records.

My first thought was that something got recompiled, and now the form is
fast. So I went back to the original version and changed some code and
recompiled , also did a compact and repair. But it was still slow. I also
tried doing an explicit decompile and then recompiled it. But it was still
slow.

So this is very frustrating that the form is now working fine, but I can't
see anything that's changed. If I don't see why the form is now fast, then
there's no reason to believe that it might not at some point go back to
being slow again. And then I'd just have to hope that something changes.
It
would be good to figure this out.

Any ideas as to what might have changed here to cause the form's Go To to
be
fast would be appreciated.

Thanks,

Neil


Nov 13 '05 #8
>>> If you don't access slowly populates list items in the background,
and can take a very long time to complete, even if the number of rows is
small, but especially if it is large.
I think you forgot a noun or a verb in the above, so I don't really
understand what you're saying. Could you rephrase it?


I was missing a comma. To rephrase... If you don't read the whole list by
selecting the last row in the combo box or by getting its list count,
Access
will slowly retrieve the combo box rows in the background, it may take a
very
long time, and some locks will be held for duration. Locks can be held
for a
long time even by combo boxes with fairly few rows.


Right. (Isn't it fun working with a product like Access whose name can be a
noun or a verb? :-) )

What's strange, though, is that it happened multiple times. You'd think that
after the combo box went to the last record (and a resulting fast go to),
that it would have the list in cache and subsequent go to's would be fast.
But each time it was slow, even one right after the other.

Also, another interesting point is how the limit to list was the pivital
feature. You would think that, whether limit to list was set or not, that
Access would still need to populate the whole list, so the results would be
the same. I guess it has to cross-check the list with limit to list, so
maybe that's the difference.

N

I'll just note that I didn't consider the combo boxes because the two
forms
were identical, and I didn't recall changing anything there. So when I
compared the two forms, I only compared the code modules and the form
properties. I didn't examine the combo box properties.

However, in light of the above, I took a closer look at the combo boxes,
since, even though your explanation makes sense, it doesn't explain why go
to's are always fast on the new version of the form, even with the combo
box
there. So I took a look at the two combo boxes, and, on the new version of
the form, where there's no problem, that combo box is *not* set to limit
to
list, whereas the original one was. (I must have changed it as I was
working
with the form.) So, apparently, that's the difference.

To confirm this, I went into the new version of the form, set the combo to
limit to list, and, voila!, it was slow like the other. Then I changed it
back to not limit to list, and it was fast again.

So I'm relieved to know that it's not a gremlin that's causing this.

Thanks again for your help.

Neil


On Sun, 16 Oct 2005 19:10:46 GMT, "Neil" <no****@nospam. net> wrote:

I have a very puzzling situation with a database. It's an Access 2000
mdb
with a SQL 7 back end, with forms bound using ODBC linked tables. At our
remote location (accessed via a T1 line) the time it took to go to a
record
was very slow. The go to mechanism was a box that the user typed the
index
value into a combo box, with very simple code attached:

with me.RecordsetClo ne
.FindFirst "[Index] = " & me.cboGoTo
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
end with

Now, one would say that going to a record is slow because I'm using
.FindFirs t over a T1 line. And that's what I thought. However, as I was
working with the form, commenting out various sections not related to
the
Go
To, I found that the Go To functionality changed, though I didn't modify
the
code.

Previousl y, going to a record near the end of the 50,000 record
recordset
took about 1-2 seconds, but going to a record near the beginning, took
about
20 seconds. After the form changed, going to any record in the recordset
took about 1-2 seconds.

So the question remains: why did it take so long to go to a record near
the
beginning of the recordset, but not near the end (and the ones in the
middle
took an amount of time about halfway between the two), and what changed
so
that now the form is working fine for all records?

I've compared the changed form with the previous copy, and I don't see
any
differences . I've compared all code in the form module, and I've
compared
all form properties. The forms are identical as far as I could tell. But
something happened as I was commenting/uncommenting code in the form
that
got rid of the problem with it taking a long time to go to some of the
records.

My first thought was that something got recompiled, and now the form is
fast. So I went back to the original version and changed some code and
recompile d, also did a compact and repair. But it was still slow. I also
tried doing an explicit decompile and then recompiled it. But it was
still
slow.

So this is very frustrating that the form is now working fine, but I
can't
see anything that's changed. If I don't see why the form is now fast,
then
there's no reason to believe that it might not at some point go back to
being slow again. And then I'd just have to hope that something changes.
It
would be good to figure this out.

Any ideas as to what might have changed here to cause the form's Go To
to
be
fast would be appreciated.

Thanks,

Neil

Nov 13 '05 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
1941
by: elji | last post by:
In my form, I have 4 objects that I want to work together: <input name="price" type="text" id="price" value="100" size="4"> <input name="quantity" type="text" id="quantity" value="1" size="2"> <input name="shipping" type="radio" value="slow">
8
2899
by: Neil | last post by:
I have a very puzzling situation with a database. It's an Access 2000 mdb with a SQL 7 back end, with forms bound using ODBC linked tables. At our remote location (accessed via a T1 line) the time it took to go to a record was very slow. The go to mechanism was a box that the user typed the index value into a combo box, with very simple code attached: with me.RecordsetClone .FindFirst " = " & me.cboGoTo If Not .NoMatch Then Me.Bookmark...
22
3327
by: Marc Mones | last post by:
Hello, I'working with IBM DB2 V8.1 and CLI/ODBC. I've got a problem with the following statement: ******************************************************************************** SELECT S_ART, S_SPRACHE, S_MANDANT, S_NR, S_SUB, S_OWNER, S_SATZ FROM SY0001_00005 WHERE S_ART = ? AND S_SPRACHE = ? AND S_MANDANT = ? AND S_NR = ? AND
2
3358
by: David | last post by:
Hi, We have an internal network of 3 users. Myself & one other currently have individual copies of the front-end MS Access forms and via our individual ODBC links we have used the: File > Get External Data > Link Tables > select ODBC Databases facility to link to our back-end MySQL Server. On both our machines the tables appear in the window very quickly and if we hit 'Select All', all the tables start loading really quickly into our...
3
7414
by: Brian Keating EI9FXB | last post by:
Hello again, I've already placed a few posts on this topic. This time i've a simple application that exhibits my problem, I've placed sample solution 8k on my website should anyone be interested in having a look. http://briankeating.net/transfer/test.zip To recap the problem I expected (and found). I've a main GUI thead (main form), this GUI thread has an UpdateTextBox function that appends a string in a textbox and It also has a button...
3
2895
by: Jennyfer J Barco | last post by:
In my application I have a datagrid. The code calls a Stored procedure and brings like 200 records. I created a dataset and then a dataview to bind the results of the query to my grid using MyGrid.DataBind() Once the records are loaded, to handle the next, previous button is too slow. I have in the same screen OptionsBox and everytime I click in any option I show some text fields in the screen. Anything the user does is very slow. When...
50
5760
by: diffuser78 | last post by:
I have just started to learn python. Some said that its slow. Can somebody pin point the issue. Thans
2
2349
by: reidarT | last post by:
I want a windows form to act like the one in Outlook when you get a new message and it is visible for about a couple of seconds and then the opacity decreases and the form dissapears in the end I have tried with Dim p As Integer Dim Vent As Integer For p = 100 To 0 Step -1 Me.Opacity = p For Vent = 1 To 100000
39
2900
by: cm_gui | last post by:
Python is slow. Almost all of the web applications written in Python are slow. Zope/Plone is slow, sloow, so very slooow. Even Google Apps is not faster. Neither is Youtube. Facebook and Wikipedia (Mediawiki), written in PHP, are so much faster than Python. Okay, they probably use caching or some code compilation -- but Google Apps and those Zope sites probably also use caching. I've yet to see a web application written in...
0
10716
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10812
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10399
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9552
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7952
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5780
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5976
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4597
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3223
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.