I have a continuous form that lists records from a query. One of the
columns is an amount field, In the footer of the form I place a text
box that displays the total (sum) of the amount.
The data in the form is linked from a one-to-many table relationship.
In this instance, I really can't sum the value from the one's table
since if there were 3 records in the many table for a record id, the
value would be summed 3 times. IOW, I may be displaying 3000 records in
the form but I really want to sum 1000 records.
Furthermore, the records displayed on the form can be filtered from a
multitude of ways The fltered data may be filtered on both the one and
many table's data.
I could create a query that sums the amount field from the "one" table
but I need the query to reflect the current filter on the form.
If I create a query like "Select Sum(Amount) From Table1 Where ID IN
(Select....), the query takes a long time to run.
Currently I create a SQL string that selects the unique IDs that are
displayed on the form based on the filter, create a temp querydef for
the SQL string, then create another SQL string that sums the amount
where the ID is inner joiined on the temp query. I open this as a
recordset, grab the value, and then delete the query. This method works
and is near instantaneous. The problem is that this form is opened many
times throughout the day and adds bloat to the database.
Is there a method you use that can query a table based on the data
displayed in a form from a one-to-many that could give a count or a sum
that would be fast and have less bloat?
..
15  7929 
Am I missing something here?
If you have a field in your form's recordset named Amount, can't you put a
textbox in the footer with a controlsource of
=Sum(Amount)
?
Won't that textbox update when you filter the form?
Is there something else you need?
- Turtle
"U N Me" <un**@together.com> wrote in message
news:3F***************@together.com... I have a continuous form that lists records from a query. One of the
columns is an amount field, In the footer of the form I place a text
box that displays the total (sum) of the amount.
The data in the form is linked from a one-to-many table relationship.
In this instance, I really can't sum the value from the one's table
since if there were 3 records in the many table for a record id, the
value would be summed 3 times. IOW, I may be displaying 3000 records in
the form but I really want to sum 1000 records.
Furthermore, the records displayed on the form can be filtered from a
multitude of ways The fltered data may be filtered on both the one and
many table's data.
I could create a query that sums the amount field from the "one" table
but I need the query to reflect the current filter on the form.
If I create a query like "Select Sum(Amount) From Table1 Where ID IN
(Select....), the query takes a long time to run.
Currently I create a SQL string that selects the unique IDs that are
displayed on the form based on the filter, create a temp querydef for
the SQL string, then create another SQL string that sums the amount
where the ID is inner joiined on the temp query. I open this as a
recordset, grab the value, and then delete the query. This method works
and is near instantaneous. The problem is that this form is opened many
times throughout the day and adds bloat to the database.
Is there a method you use that can query a table based on the data
displayed in a form from a one-to-many that could give a count or a sum
that would be fast and have less bloat?
.
Thanks for the reply.
MacDermott wrote: Am I missing something here?
Yes.
If you have a field in your form's recordset named Amount, can't you put a
textbox in the footer with a controlsource of
=Sum(Amount)
No, that won't work. Let's look at 2 SQL statements.
SQL statement 1)
Select ID, Amount From Table.
Entering =Sum(Amount) would work and present the correct value. That is not a
representation of my problem.
SQL statement 2)
Select ID, Amount, Table2.Something from Table1 Inner Join Table2 On
Table1.ID = Table2.ID
This is a representation of my problem. Entering an =Sum(Amount) would not
work because if there are records from Table2 (a many table), the sum of
Amount would also include duplicates. For example, table1 contains 3 records
with ID value of 1,2, and 3. In Table2. related to Table1, there are two
ID=1, three Id=2, and five ID=3. Using your suggestion, the =Sum(Amount)
would sum up all 10 records displayed on the form.
Next, I am filtering the form's recordset in a variety of ways. It would be
nice if I could do this:
Select Sum(Amount) From Table1 Inner Join (Select Distinct Form's Rs.query
+ filter) On Table1.ID = rs.ID
I could create a query to do the above....except I'd be lacking the filter.
The filter may be on date ranges, company names, and other flags. many of the
fields in Table2.
Won't that textbox update when you filter the form?
Is there something else you need?
A better method than the one I am using.
- Turtle
"U N Me" <un**@together.com> wrote in message
news:3F***************@together.com... I have a continuous form that lists records from a query. One of the
columns is an amount field, In the footer of the form I place a text
box that displays the total (sum) of the amount.
The data in the form is linked from a one-to-many table relationship.
In this instance, I really can't sum the value from the one's table
since if there were 3 records in the many table for a record id, the
value would be summed 3 times. IOW, I may be displaying 3000 records in
the form but I really want to sum 1000 records.
Furthermore, the records displayed on the form can be filtered from a
multitude of ways The fltered data may be filtered on both the one and
many table's data.
I could create a query that sums the amount field from the "one" table
but I need the query to reflect the current filter on the form.
If I create a query like "Select Sum(Amount) From Table1 Where ID IN
(Select....), the query takes a long time to run.
Currently I create a SQL string that selects the unique IDs that are
displayed on the form based on the filter, create a temp querydef for
the SQL string, then create another SQL string that sums the amount
where the ID is inner joiined on the temp query. I open this as a
recordset, grab the value, and then delete the query. This method works
and is near instantaneous. The problem is that this form is opened many
times throughout the day and adds bloat to the database.
Is there a method you use that can query a table based on the data
displayed in a form from a one-to-many that could give a count or a sum
that would be fast and have less bloat?
So you have 2 tables and you're spilling this information onto a form and
this is okay, but when you try to total, it's no good because some of the
figures are themselves totals? Eliminate the table 1 amount from this
altogether and calculate whatever totals and subtotals you need from the
table 2 amount only. If you HAVE to retrieve both amounts, perhaps because
of the positioning on the form or something, retrieve the table 1 and table
2 amounts into separate fields.
Robert Crouser
"U N Me" <un**@together.com> wrote in message
news:3F***************@together.com... Thanks for the reply.
MacDermott wrote:
Am I missing something here?
Yes.
If you have a field in your form's recordset named Amount, can't you put
a textbox in the footer with a controlsource of
=Sum(Amount)
No, that won't work. Let's look at 2 SQL statements.
SQL statement 1)
Select ID, Amount From Table.
Entering =Sum(Amount) would work and present the correct value. That is
not a representation of my problem.
SQL statement 2)
Select ID, Amount, Table2.Something from Table1 Inner Join Table2 On
Table1.ID = Table2.ID
This is a representation of my problem. Entering an =Sum(Amount) would
not work because if there are records from Table2 (a many table), the sum of
Amount would also include duplicates. For example, table1 contains 3
records with ID value of 1,2, and 3. In Table2. related to Table1, there are two
ID=1, three Id=2, and five ID=3. Using your suggestion, the =Sum(Amount)
would sum up all 10 records displayed on the form.
Next, I am filtering the form's recordset in a variety of ways. It would
be nice if I could do this:
Select Sum(Amount) From Table1 Inner Join (Select Distinct Form's
Rs.query + filter) On Table1.ID = rs.ID
I could create a query to do the above....except I'd be lacking the
filter. The filter may be on date ranges, company names, and other flags. many of
the fields in Table2.
Won't that textbox update when you filter the form?
Is there something else you need?
A better method than the one I am using.
- Turtle
"U N Me" <un**@together.com> wrote in message
news:3F***************@together.com... I have a continuous form that lists records from a query. One of the
columns is an amount field, In the footer of the form I place a text
box that displays the total (sum) of the amount.
The data in the form is linked from a one-to-many table relationship.
In this instance, I really can't sum the value from the one's table
since if there were 3 records in the many table for a record id, the
value would be summed 3 times. IOW, I may be displaying 3000 records
in the form but I really want to sum 1000 records.
Furthermore, the records displayed on the form can be filtered from a
multitude of ways The fltered data may be filtered on both the one
and many table's data.
I could create a query that sums the amount field from the "one" table
but I need the query to reflect the current filter on the form.
If I create a query like "Select Sum(Amount) From Table1 Where ID IN
(Select....), the query takes a long time to run.
Currently I create a SQL string that selects the unique IDs that are
displayed on the form based on the filter, create a temp querydef for
the SQL string, then create another SQL string that sums the amount
where the ID is inner joiined on the temp query. I open this as a
recordset, grab the value, and then delete the query. This method
works and is near instantaneous. The problem is that this form is opened
many times throughout the day and adds bloat to the database.
Is there a method you use that can query a table based on the data
displayed in a form from a one-to-many that could give a count or a
sum that would be fast and have less bloat?
Robert wrote: So you have 2 tables and you're spilling this information onto a form and
this is okay, but when you try to total, it's no good because some of the
figures are themselves totals?
No. I hope this clarifies the problem.
Let's say Table1 had many fields that include 2 fields, ID and Amount
1,$100
2,$200
3,$300
Table2 has 5 records with many fields including the fields T1ID and Employee
1,"Joe"
1,"Sam"
2,"Mike"
2,"John"
3,"Larry"
If the sql for the form was "Select table1.id, amount, name from table1 inner
join table2 on table1.id = table2.t1id" I would see 4 records displayed;
1,$100,"Joe"
1,$100,"Sam" 'duplicate in sum
2,$200,"Mike"
2,$200,"John" 'duplicate in sum
3,$300,"Larry"
using an =Sum(Amount) the value would display $900. That is not correct. I
want to see $600.
This is a continuous form. It is basically a lookup/informational form, not a
data entry form, and putting this into a form/subform would defeat the purpose.
The filter can be on any/many fields contained in both Table1 and
Table2....mostly Table2.
Eliminate the table 1 amount from this
altogether and calculate whatever totals and subtotals you need from the
table 2 amount only.
That is not what I want.
If you HAVE to retrieve both amounts,
The amount comes from table1, not from both tables
perhaps because
of the positioning on the form or something, retrieve the table 1 and table
2 amounts into separate fields.
What I am currently doing is a "Select Distinct ID" sql on the forms
recordsource with the form's filter, making this a temp query in the QueryDefs
collection, and then running a SQL that innerjoins to the temp query to sum the
amount. Using an InnerJoin is very fast. If I were to do a
Select Sum(Amount) From Table1 where Table1.ID in (Select .....) where the
Select is the recordsource SQL of the form, it adds consideralbe overhead.
Robert Crouser
Yes, this clarifies the problem. Your table with the duplicate id's is
unusual and throws people. So you have a working form, but your problem is
a performance issue. Any performance experts out there ?
"U N Me" <un**@together.com> wrote in message
news:3F***************@together.com... Robert wrote:
So you have 2 tables and you're spilling this information onto a form
and this is okay, but when you try to total, it's no good because some of
the figures are themselves totals?
No. I hope this clarifies the problem.
Let's say Table1 had many fields that include 2 fields, ID and Amount
1,$100
2,$200
3,$300
Table2 has 5 records with many fields including the fields T1ID and
Employee 1,"Joe"
1,"Sam"
2,"Mike"
2,"John"
3,"Larry"
If the sql for the form was "Select table1.id, amount, name from table1
inner join table2 on table1.id = table2.t1id" I would see 4 records displayed;
1,$100,"Joe"
1,$100,"Sam" 'duplicate in sum
2,$200,"Mike"
2,$200,"John" 'duplicate in sum
3,$300,"Larry"
using an =Sum(Amount) the value would display $900. That is not correct.
I want to see $600.
This is a continuous form. It is basically a lookup/informational form,
not a data entry form, and putting this into a form/subform would defeat the
purpose.
The filter can be on any/many fields contained in both Table1 and
Table2....mostly Table2.
Eliminate the table 1 amount from this
altogether and calculate whatever totals and subtotals you need from the
table 2 amount only.
That is not what I want.
If you HAVE to retrieve both amounts,
The amount comes from table1, not from both tables
perhaps because
of the positioning on the form or something, retrieve the table 1 and
table 2 amounts into separate fields.
What I am currently doing is a "Select Distinct ID" sql on the forms
recordsource with the form's filter, making this a temp query in the
QueryDefs collection, and then running a SQL that innerjoins to the temp query to
sum the amount. Using an InnerJoin is very fast. If I were to do a
Select Sum(Amount) From Table1 where Table1.ID in (Select .....) where
the Select is the recordsource SQL of the form, it adds consideralbe overhead.
Robert Crouser
U N Me <un**@together.com> wrote in news:3F***************@together.com: If the sql for the form was "Select table1.id, amount, name from
table1 inner join table2 on table1.id = table2.t1id" I would see 4
records displayed; 1,$100,"Joe"
1,$100,"Sam" 'duplicate in sum
2,$200,"Mike"
2,$200,"John" 'duplicate in sum
3,$300,"Larry"
using an =Sum(Amount) the value would display $900. That is not
correct. I want to see $600.
Leave the inner join SQL as you have it there. Instead of =Sum(Amount),
use =Sum(Amount)/=Count(Amount).
I'm kinda hesitant to get into this, but anway... here goes.
Could you explain/diagram/whatever the relationship between what looks
like a Person table and an Invoice or whatever table? It looks
backwards to me. Do you mean that
Amount--(1,M)---Person ???
Explain how the two entities are related in plain old business
English... Does this amount represent a total bill or something that
multiple clients can pay? Why don't we take a step backward. Explain
the business rules/relationships and then I'm sure someone can figure
out how to do what you want. But without understanding the logic
behind all this, it's really a waste of time, because there's no way
of telling if the solution is correct.
Since you say this is an informational form rather than a data entry form,
perhaps you could use a report instead.
Using a Report/Subreport format, you can display all of your data, and still
sum the data from the main report.
HTH
- Turtle
"U N Me" <un**@together.com> wrote in message
news:3F***************@together.com... Robert wrote:
So you have 2 tables and you're spilling this information onto a form
and this is okay, but when you try to total, it's no good because some of
the figures are themselves totals?
No. I hope this clarifies the problem.
Let's say Table1 had many fields that include 2 fields, ID and Amount
1,$100
2,$200
3,$300
Table2 has 5 records with many fields including the fields T1ID and
Employee 1,"Joe"
1,"Sam"
2,"Mike"
2,"John"
3,"Larry"
If the sql for the form was "Select table1.id, amount, name from table1
inner join table2 on table1.id = table2.t1id" I would see 4 records displayed;
1,$100,"Joe"
1,$100,"Sam" 'duplicate in sum
2,$200,"Mike"
2,$200,"John" 'duplicate in sum
3,$300,"Larry"
using an =Sum(Amount) the value would display $900. That is not correct.
I want to see $600.
This is a continuous form. It is basically a lookup/informational form,
not a data entry form, and putting this into a form/subform would defeat the
purpose.
The filter can be on any/many fields contained in both Table1 and
Table2....mostly Table2.
Eliminate the table 1 amount from this
altogether and calculate whatever totals and subtotals you need from the
table 2 amount only.
That is not what I want.
If you HAVE to retrieve both amounts,
The amount comes from table1, not from both tables
perhaps because
of the positioning on the form or something, retrieve the table 1 and
table 2 amounts into separate fields.
What I am currently doing is a "Select Distinct ID" sql on the forms
recordsource with the form's filter, making this a temp query in the
QueryDefs collection, and then running a SQL that innerjoins to the temp query to
sum the amount. Using an InnerJoin is very fast. If I were to do a
Select Sum(Amount) From Table1 where Table1.ID in (Select .....) where
the Select is the recordsource SQL of the form, it adds consideralbe overhead.
Robert Crouser
Ross Presser <rp******@NOSPAM.imtek.com.invalid> wrote in
news:Xn**********************@129.250.170.93: U N Me <un**@together.com> wrote in news:3F***************@together.com:
If the sql for the form was "Select table1.id, amount, name from
table1 inner join table2 on table1.id = table2.t1id" I would see 4
records displayed; 1,$100,"Joe"
1,$100,"Sam" 'duplicate in sum
2,$200,"Mike"
2,$200,"John" 'duplicate in sum
3,$300,"Larry"
using an =Sum(Amount) the value would display $900. That is not
correct. I want to see $600.
Leave the inner join SQL as you have it there. Instead of =Sum(Amount),
use =Sum(Amount)/=Count(Amount).
D'oh! Remove the second = sign. Sorry, head cold is reducing my
alertness.
=Sum(Amount)/Count(Amount)
Pieter Linden wrote: I'm kinda hesitant to get into this, but anway... here goes.
Could you explain/diagram/whatever the relationship between what looks
like a Person table and an Invoice or whatever table? It looks
backwards to me. Do you mean that
Amount--(1,M)---Person ???
Yes. Here's a more descriptive example. There is a bid. The bid is
$1000. There are 3 companies attached to a bid. Next record. The bid
is $500. There are 2 companies for this bid, etc, etc for remaining
records.
If these records were displayed on a form, the bid number, the bid amount,
and all companies associated with the bid would be displayed. However,
there would be as any many records for each bid as there are records in
the many table that contains companies.
Thus, for the first bid, the 3 companies will be listed and the amount
$1000 would be listed 3 times.
Using this example, if the form is filtered for bid# 1, then an
=Sum(Amount) would be equal to $3000. That is not correct. The bid is
$1000. Although three lines are displayed in this example, the amount
from the one's table should only be added 1 time.
Explain how the two entities are related in plain old business
English... Does this amount represent a total bill or something that
multiple clients can pay? Why don't we take a step backward. Explain
the business rules/relationships and then I'm sure someone can figure
out how to do what you want. But without understanding the logic
behind all this, it's really a waste of time, because there's no way
of telling if the solution is correct.
If I create a query and get data from a 1-to-many table (table1 and
Table2) relationship, I will end up with as many rows as there are in
Table2.
The SQL Select statement (which will get the correct result),
Select Sum(Amount) From Table1 where BidID In (Select ...the SQL
select and filter from the form)
is EXTREMELY SLOW!
When I create a querydef of the SQL select and filter distinct bid ids
from the forms recordsource and then innerjoin Table1 bidid to the temp
querydef bidid, the result is blazingly fast. But it adds bloat
What I would LIKE to do is inner joiin, w/o creating a temp querydef, on
the forms recordset.
Select Sum(AMount) From Table1 InnerJoin (Select Distinct BidNo from form
recordset + filter) On BidID = BidID
Let's look at this another way. Let's say I had Query1, Query2, and
Query3. This is a dumb example, but I am sure you have strung queries
together.
Query1 SQL is "Select EmpID, Name, PayRate, Sex From Employee"
Query2 SQL is "Select * From Query1 Where Sex = 'M'"
Query3 SQL is "Select Sum(PayRate) From Query2"
What I would like to do is createa SQL statement on the fly that has the
SQL statements from Query1 and Query2
Select Sum(PayRate) From (Select * From (Select EmpID, Name, PayRate, Sex
From Employee) Where Sex 'M')
The above line basically does what Query3 does. However, to get the
results of query3, there are 2 sub queries that make up the result. I
guess Access97 doesn't allow subqueries unless the subquery is a
querydef...but it's what I would want. At this time, I don't think it can
be done.
Ross Presser wrote: Ross Presser <rp******@NOSPAM.imtek.com.invalid> wrote in
news:Xn**********************@129.250.170.93:
U N Me <un**@together.com> wrote in news:3F***************@together.com:
If the sql for the form was "Select table1.id, amount, name from
table1 inner join table2 on table1.id = table2.t1id" I would see 4
records displayed; 1,$100,"Joe"
1,$100,"Sam" 'duplicate in sum
2,$200,"Mike"
2,$200,"John" 'duplicate in sum
3,$300,"Larry"
using an =Sum(Amount) the value would display $900. That is not
correct. I want to see $600.
Leave the inner join SQL as you have it there. Instead of =Sum(Amount),
use =Sum(Amount)/=Count(Amount).
D'oh! Remove the second = sign. Sorry, head cold is reducing my
alertness.
=Sum(Amount)/Count(Amount)
Hi Ross, I don't see how that will help me. The Sum of the Amount is $900 and
the count is 5 using the above example. That would result in $180.
I wish it was easy as that <g>.
MacDermott wrote: Since you say this is an informational form rather than a data entry form,
perhaps you could use a report instead.
Using a Report/Subreport format, you can display all of your data, and still
sum the data from the main report.
HTH
It would be nice. But it needs to be a form....as if I dbl-click on the field I
go to the record. However, I may check your method out. Maybe, instead of
showing the sum in a text box in the footer band of the form, I can use a
subform that displays the sum value.
I'm not 100% sure what you're proposing, but I don't think you can use a
subform in the detail section of a continuous form.
If you're OK with displaying the sum for the current record in the form
footer (or header), a subform will work for that.
HTH
- Turtle
"U N Me" <un**@together.com> wrote in message
news:3F***************@together.com... MacDermott wrote:
Since you say this is an informational form rather than a data entry
form, perhaps you could use a report instead.
Using a Report/Subreport format, you can display all of your data, and
still sum the data from the main report.
HTH
It would be nice. But it needs to be a form....as if I dbl-click on the
field I go to the record. However, I may check your method out. Maybe, instead
of showing the sum in a text box in the footer band of the form, I can use a
subform that displays the sum value.
It might be a lot of work, but how about using a TreeView control?
- Turtle
"U N Me" <un**@together.com> wrote in message
news:3F***************@together.com... Pieter Linden wrote:
I'm kinda hesitant to get into this, but anway... here goes.
Could you explain/diagram/whatever the relationship between what looks
like a Person table and an Invoice or whatever table? It looks
backwards to me. Do you mean that
Amount--(1,M)---Person ???
Yes. Here's a more descriptive example. There is a bid. The bid is
$1000. There are 3 companies attached to a bid. Next record. The bid
is $500. There are 2 companies for this bid, etc, etc for remaining
records.
If these records were displayed on a form, the bid number, the bid amount,
and all companies associated with the bid would be displayed. However,
there would be as any many records for each bid as there are records in
the many table that contains companies.
Thus, for the first bid, the 3 companies will be listed and the amount
$1000 would be listed 3 times.
Using this example, if the form is filtered for bid# 1, then an
=Sum(Amount) would be equal to $3000. That is not correct. The bid is
$1000. Although three lines are displayed in this example, the amount
from the one's table should only be added 1 time.
Explain how the two entities are related in plain old business
English... Does this amount represent a total bill or something that
multiple clients can pay? Why don't we take a step backward. Explain
the business rules/relationships and then I'm sure someone can figure
out how to do what you want. But without understanding the logic
behind all this, it's really a waste of time, because there's no way
of telling if the solution is correct.
If I create a query and get data from a 1-to-many table (table1 and
Table2) relationship, I will end up with as many rows as there are in
Table2.
The SQL Select statement (which will get the correct result),
Select Sum(Amount) From Table1 where BidID In (Select ...the SQL
select and filter from the form)
is EXTREMELY SLOW!
When I create a querydef of the SQL select and filter distinct bid ids
from the forms recordsource and then innerjoin Table1 bidid to the temp
querydef bidid, the result is blazingly fast. But it adds bloat
What I would LIKE to do is inner joiin, w/o creating a temp querydef, on
the forms recordset.
Select Sum(AMount) From Table1 InnerJoin (Select Distinct BidNo from form
recordset + filter) On BidID = BidID
Let's look at this another way. Let's say I had Query1, Query2, and
Query3. This is a dumb example, but I am sure you have strung queries
together.
Query1 SQL is "Select EmpID, Name, PayRate, Sex From Employee"
Query2 SQL is "Select * From Query1 Where Sex = 'M'"
Query3 SQL is "Select Sum(PayRate) From Query2"
What I would like to do is createa SQL statement on the fly that has the
SQL statements from Query1 and Query2
Select Sum(PayRate) From (Select * From (Select EmpID, Name, PayRate, Sex
From Employee) Where Sex 'M')
The above line basically does what Query3 does. However, to get the
results of query3, there are 2 sub queries that make up the result. I
guess Access97 doesn't allow subqueries unless the subquery is a
querydef...but it's what I would want. At this time, I don't think it can
be done.
U N Me <un**@together.com> wrote in news:3F***************@together.com: Hi Ross, I don't see how that will help me. The Sum of the Amount is
$900 and the count is 5 using the above example. That would result in
$180.
I wish it was easy as that <g>.
How about using this as the inner join SQL:
select table1.id, table1.amount from table1 inner join tabel2 on table1.id
= table2.t1id group by table1.id, table1.amount
and using =Sum(Amount) in the control? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Sudhakar Sankar |
last post by:
Hi all,
I am using a COM+ component to fetch the Recordset from the database.
My coding is as follows:
' ------ In COM+ Application --------------
Function executeResultQuery(Con as...
|
by: Rob Meade |
last post by:
evenin'
k - I've got a recordset that I'm dumping another recordset into - because
the source comes from a database that I cant update (probably makes more
sense to me that bit) - anyway, I need...
|
by: Rob Meade |
last post by:
Lo all,
I have a local recordset which is not linked to a database.
Some of the fields in this recordset contain html tags.
I have a function which is called when I'm calculating my...
|
by: deko |
last post by:
For some reason this does not seem to be working...
Am I missing something basic?
Dim rst As DAO.Recordset
Dim db As DAO.Database
Set db = CurrentDb
Set rst = db.OpenRecordset("qryEmailS") '...
|
by: Jeff |
last post by:
I have an increasingly-complicated query string that sends results to
an Excel file; I've broken the query somehow.
Currently using Access 2007, DAO recordset via late binding (we don't
have...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
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...
|
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...
|
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,...
|
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...
| |
