Export subform datasheet to excel.

B

Bdavis

I have a datasheet subform. On the mainform, I'd like to put a command
button that exports the data shown in the subform (data is filtered on the
mainform) to Excel.

And then, if possible, I'd like it to open in excel and execute an excel
macro on the exported data.

The first part is the most important. Thanks in advance!
 
A

aaron.kempf

Docmd.RunCommand cmdExportToExcel or something along those lines; i
dont know where to find that magical list of RunCommand constants

you might just poke throuhg a macro and find the right one

-aaron
 
M

[MVP] S.Clark

The data in the subform can be derived from a query.

Suppose that the recordsource is qryZYX and your ParentID is in a field
called txtparentID

Append the data to an export table:
currentdb.execute "INSERT INTO tblExportSubForm SELECT * from qryZYX WHERE
ParentID=" & txtParentID

Export the table to your spreadsheet
docmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9,
"tblExportSubForm", "c:\myspreadsheet.xls"
 
T

Tom Wickerath

Steve,

Why the need to first append the data to an export table? This will just
contribute to unnecessary database bloat.

Export the query to your spreadsheet
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9, _
"qryName", "c:\myspreadsheet.xls"

where "qryName" is the name of your query. Make the appropriate substitution.

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

The data in the subform can be derived from a query.

Suppose that the recordsource is qryZYX and your ParentID is in a field
called txtparentID

Append the data to an export table:
currentdb.execute "INSERT INTO tblExportSubForm SELECT * from qryZYX WHERE
ParentID=" & txtParentID

Export the table to your spreadsheet
docmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9,
"tblExportSubForm", "c:\myspreadsheet.xls"


--
Steve Clark, Access MVP
http://www.fmsinc.com/consulting
*FREE* Access Tips: http://www.fmsinc.com/free/tips.html
__________________________________________


I have a datasheet subform. On the mainform, I'd like to put a command
button that exports the data shown in the subform (data is filtered on the
mainform) to Excel.

And then, if possible, I'd like it to open in excel and execute an excel
macro on the exported data.

The first part is the most important. Thanks in advance!
 
T

Tom Wickerath

Aaron,

I don't believe there is any runcommand constant associated with exporting
data to Excel. However, in answer to your question about where to find such
constants, you might want to have a look at Terry Wickenden's web site:

http://www.tkwickenden.clara.net/index.htm


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

aaron kempf wrote:

Docmd.RunCommand cmdExportToExcel or something along those lines; i
dont know where to find that magical list of RunCommand constants

you might just poke throuhg a macro and find the right one

-aaron
 
B

Bdavis

Tom,

I think the problem here will be that the query output is filted at the form
level. It's the filted data I want to export, not the entire query result.
 
T

Tom Wickerath

Hi Bdavis,

Here is how I do it, for a QBF (Query by Form) search form that displays the
search results in a subform, and allows the capability to export the results
to Excel. I'm happy to send you a copy of this sample, if you send me a
private e-mail message with a valid reply-to address. My e-mail address can
be found at the bottom of the contributors page indicated in my signature.

Public Function RequerySubform()
On Error GoTo ProcError

Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim qdf As DAO.QueryDef
Dim intRecordCount As Integer

Set db = CurrentDb()
Set qdf = db.QueryDefs("qryMovieSelections")

<snip -- code to build strFullSQL goes here. This string variable serves as
the recordsource for the subform.>

qdf.SQL = strFullSQL
Set rs = db.OpenRecordset("qryMovieSelections")
intRecordCount = rs.RecordCount

If intRecordCount = 0 Then
cmdExportToExcel.Enabled = False
Else
cmdExportToExcel.Enabled = True
End If

<snipped a bit more code here>

ExitProc: 'Clean up
On Error Resume Next
qdf.Close: Set qdf = Nothing
rs.Close: Set rs = Nothing: db.Close: Set db = Nothing
Exit Function
ProcError:
MsgBox "Error " & Err.Number & ": " & Err.Description, , _
"Error in RequerySubform event procedure..."
Resume ExitProc
End Function

Private Sub cmdExportToExcel_Click()
On Error GoTo ProcError

Dim strPath As String
strPath = CurrentProject.Path

DoCmd.OutputTo acOutputQuery, "qryMovieSelections", acFormatXLS, _
strPath & "\MovieSelections.xls" ', AutoStart:=-1

MsgBox "The selected movies have been exported to the file
MovieSelections.xls" & vbCrLf _
& "in the folder:" & vbCrLf & strPath, vbInformation, "Export
Complete..."

ExitProc:
Exit Sub
ProcError:
MsgBox "Error " & Err.Number & ": " & Err.Description, , _
"Error in cmdExportToExcel_Click event procedure..."
Resume ExitProc
End Sub


My QBF form is an unbound form, so you'd have to do a slight modification in
order to incorporate ParentID=" & txtParentID, but that should be rather easy.

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:
Tom,

I think the problem here will be that the query output is filted at the form
level. It's the filted data I want to export, not the entire query result.
__________________________________________

:

Steve,

Why the need to first append the data to an export table? This will just
contribute to unnecessary database bloat.

Export the query to your spreadsheet
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9, _
"qryName", "c:\myspreadsheet.xls"

where "qryName" is the name of your query. Make the appropriate substitution.

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

The data in the subform can be derived from a query.

Suppose that the recordsource is qryZYX and your ParentID is in a field
called txtparentID

Append the data to an export table:
currentdb.execute "INSERT INTO tblExportSubForm SELECT * from qryZYX WHERE
ParentID=" & txtParentID

Export the table to your spreadsheet
docmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9,
"tblExportSubForm", "c:\myspreadsheet.xls"


--
Steve Clark, Access MVP
http://www.fmsinc.com/consulting
*FREE* Access Tips: http://www.fmsinc.com/free/tips.html
__________________________________________


I have a datasheet subform. On the mainform, I'd like to put a command
button that exports the data shown in the subform (data is filtered on the
mainform) to Excel.

And then, if possible, I'd like it to open in excel and execute an excel
macro on the exported data.

The first part is the most important. Thanks in advance!
 
A

aaron.kempf

tom

it won't contribute to unneccessary database bloat if you use a real
friggin database engine.. like MSDE or SQL Server.. i mean..

MDB IS FOR SISSIES
 
T

Tom Wickerath

That's your opinion only. Funny, I've never heard anyone else share this
opinion. Aaron, you remind me of someone who constantly paddles upstream, and
then wonders why they work so hard and never get anywhere.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

aaron wrote:

tom

it won't contribute to unneccessary database bloat if you use a real
friggin database engine.. like MSDE or SQL Server.. i mean..

MDB IS FOR SISSIES
 
A

aaron.kempf

oh tom

you're the idiot that sits around and uses a junior-size database

i mean-- aren't you tired of all these workarounds?

queries on top of queries that just spew 'the expression is too
compelx'

that kinda crap doesn't happen with ADP
and you-- tom wickerath-- should personally be shot on live television
for preaching an obsolete database

you should personally be sued by all shareholders in Microsoft
Corporation; for you are betraying your company and your clients.

a) countless unresolved bugs in MDB
b) countless unresolved bugs in DAP
c) countless unresolved bugs in ADP

you are the reason that excel is such a contagious disease-- i mean--
because you've done such a crap job with access; these lamers HAVE TO
use excel.. i mean-- they use apps that have been TESTED vs use a
product that redmond doesn't take seriously. Excel has been tested;
redmond takes excel seriously.

Access isn't stable, fast enough or secure enough to warrant you
getting a single paycheck.

MDB is crap; your baby database is wimpy wimpy wimpy

i mean-- you can't even enforce RI against large tables; i mean-- what
the **** are you guys thinking??

Access 2000 is _SLOWER_ than Access 97-- I've worked for many clients
in the past few years that refuse to move into the 21st century.. do
you know why?

BECAUSE ACCESS IS MARKETED TOWARDS BABIES NOT PROFESSIONALS.
BECAUSE ACCESS IS TESTED BY BABIES NOT PROFESSIONALS.
BECAUSE ACCESS IS WRITTEN BY BABIES NOT PROFESSIONALS.

I mean-- i swear to god Tom; i just want to know who the **** you think
you are; selling a product like this

Queries on top of queries just randomly crap out.

Deploying the Access Runtime is IMPOSSIBLE (it should come with every
non-professional office installation)

little things like testing mdb against sharepoint? why in the **** does
it take 2 hours to write 10k records?

Who the **** do you think that you are tom?

You guys are clinging to the Itanium of the office suite; when x64 has
obviously won the war. I'm talking figuratively; not physically.

PULL YOUR FUCKING HEAD OUT OF YOUR ASS. START TAKING ADP SERIOUSLY.
START FIXING BUGS INSTEAD OF SELLING US NEW BUGGY FEATURES.

and that little presentation you gave at PNWAUG?? about 6-7 weeks ago??


i swear to god;

Select 1 From Employees Union Select EmployeeID From Employees

i swear; it would be a TON more efficient to do it this way right?

SELECT Employees.EmployeeID
FROM Employees
UNION
select 1 from employees


that way you get your 37 records, and your one record; you get the
distinct (because of the union statement (instead of union all for
example) and then you squash it back down to 38 records

i mean-- might not make a huge difference on a small table

but if you did that against a large table; it really might have some
drastic performance implications

i mean-- your code took 37 records, plus 37 records to equal 74
records; and then it distincted them back down to 38.

at least that's what i assume.

it just looked ass-backwards to me.

and i sit here and question-- all of your qualifications

is there a single living, breathing lifeform that works on microsoft
access in Redmond?
Is the Access team run by excel dorks?? is that why you are sooooo
unsuccessful??

or are we going to find out some day that it was a sponge that wrote ms
access?

WHY DO YOU SETTLE FOR MEDIOCRITY TOM??

YOU ARE THE ONE PERSON HERE THAT _CAN_ GET SOMETHING DONE ABOUT THIS.
I've gotten fired from Redmond _TWICE_ because i'm not willing to sit
here and not scream bloody murder.

you guys are snake-oil salesmen.
Bill Gates is guilty of TREASON for this little feature called 'Sql
Authentication'.

you sell products that are IMPOSSIBLE TO SECURE (simple dictionary
attack against your enterprise-level database; i mean-- who the ****
thinks up these holes? is larry ellison working for your company in
disguise; just thinking-- 'how can i screw with microsoft customers
today?')

that is the only thing that explains why the hell you guys sell crappy
products.

you sell products that are INCONSISTENT

and you sell products that are BUGGY AS HELL.

maybe instead of jerking off with the latest MS iPod; or jerking it to
a Xbox 360; why dont you assholes spend some of OUR hard-earned money
to fix EXISTING BUGS IN EXISTING PRODUCTS.

$40 billion in cash is almost enough to buy Oracle or Sybase or
something.. i mean-- it's obvious that redmond is too drunk to take the
db industry seriously

so either
a) fix your bugs yourself
b) buy someone that can find your bugs for you

i mean-- basic basic functionality here

do you ever USE this product? have you ever used it in the real world?

how many times have you had an Access GPF or IPF in the past 5 years?
because i've seen hundreds, asshole

how many times have you had to turn around and drive back to work;
because some acceess database was hosed?
i mean-- 'uh, the record is being updated; plz try again'

NO SERIOUSLY TOM

HOW MANY TIMES HAVE YOU ASSHOLES REALLY _USED_ MDB?

how many times have you gotten called at 3am because somebody can't
make SOUP because of a stupid MDB locking problem??

MDB is buggy as hell; and i mean-- simple things like queries on top of
queries?

this shit should just WORK the first time
it should work the 2nd time.

Access MDB is unable to fit the ACID model. It isn't reliable enough
for a single goddamn record.

i'm tired of rewriting shit just because access throws a tissy fit

im tired of rebooting servers because MDB locking sucks balls

im tired of all the hassle; access should be marketed towards the top
of the barrel; the sales execs; the light programmers-- as it is,
access ins't marketed. you guys just sit around and spew new buggy
features every version.

Access is the best IDE in the WORLD.
not visual studio; not dreamweaver-- not adobe can compete with ms
access.

it's just time that you and your fratboy asshole butt buddies start
taking it seriously.


i mean seriously tom. is access REALLY useable?

can you build queries on top of queries?
when and why and how does it spew for you?
 
A

aaron.kempf

sorry kids

i meant this

SELECT Employees.EmployeeID
FROM Employees
UNION
select 1


big difference--- it wouldn't scan the employees table twice

sorry about that
 
T

Tom Wickerath

Aaron,

I'm really surprised that your tirade of a post was not filtered out by the
MS web portal. I do actually admit to enjoying the entertainment value that a
fruitcake like you constantly provides.

I'm only going to answer selected parts of your latest tirade.
queries on top of queries that just spew 'the expression is too compelx'

I've never found the need to build queries on top of queries as you
describe, except for a rare use of one query as the source for another. I
have helped troubleshoot many Access applications in the past, built by
others, which used queries built on queries, built on still more queries,
etc., etc., etc. I suspect that these are the type of queries that you
complain about crapping out, but when written properly this type of query
design is generally not necessary.
can you build queries on top of queries? (from the end of your tirade)
I don't have the need. One can usually write more efficient SQL that does
not require such constructs.
a) countless unresolved bugs in MDB
b) countless unresolved bugs in DAP
c) countless unresolved bugs in ADP

Aaron, if you really feel this way, then 1.) why have you written in the
past that DAP's and ADP's rock? and 2.) why not just adopt a different
platform, such as Oracle for your data storage needs? I'm sure Microsoft
won't be harmed in the least by one disgruntled former employee making the
decision to migrate away from all Microsoft products. By the way, *anyone*
who thinks that DAP's rock is truly an idiot.
i mean-- you can't even enforce RI against large tables;
No idea what you mean here. I've never had any trouble with this.
Deploying the Access Runtime is IMPOSSIBLE
I wouldn't say impossible, but I agree that it can be more difficult.
Frankly, it's not worth it for me to mess with runtime, unless I have an
installation of at least 15 to 20 clients minimum. My clients always have
Access available anyway, so I've not had to concern myself with runtime
issues.
and that little presentation you gave at PNWAUG?? about 6-7 weeks ago??
i swear to god;
Select 1 From Employees Union Select EmployeeID From Employees

Sorry, but I have no idea what you are talking about. My last presentation
to the PNWADG was on December 20th, which was 10 days ago, not 6-7 weeks ago.
This presentation did not include any discussion of SQL statements. Perhaps
this was presented at the Dec. 13 meeting of the AccessSIG group, but I was
not able to attend that meeting. You've obviously got me confused with
someone else. Frankly, I have no memory of a presentation 6-7 weeks ago that
involved such a SQL statement. This would have had to have been one of the
November meetings (Nov. 8 or Nov. 15), but I was not a presenter at either
meeting bucko.
YOU ARE THE ONE PERSON HERE THAT _CAN_ GET SOMETHING DONE
ABOUT THIS.
You act like I work at Microsoft. I do not. Aaron, your eyes are closed and
you've only one oar in the water – and you have no idea why you're not
getting anywhere. But it doesn’t stop you from bragging about how far you've
gone past everybody else in the race. ;-)


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
 
A

aaron.kempf

good stuff

while im sitting around bitching about BUGS you sit around and laugh

stop making excuses

does anyone know where i can report bugs to a gov't agency?
i mean-- MS doesn't do jack shit about it

MS is fraudulently selling buggy software

and i know it was just over a moth ago; the 12/10 meeting was tableau
you were showing .NET right?? and you had this SQL statement; it just
drove me crazy

select 1 from employees
union
select employeeid from employees

you note how that's taking 37 copies of the same record on top of 37
distinct records?

it just drives me crazy

you guys are clinging to a sinking ship; the titanic of the database
world

MDB is dead and gone yet MS is too drunk to take ADP seriously

i mean

SERIOUSLY
why does query on top of query just blatantly not work?

why don't other people bitch about it?

RI against large tables?

have an orders table that is 1.1gb

have an order details table that is 1.5 gb

i mean... you can't do jack shit with RI with large tables right??

because they're all in their own 'backend' gag me with a friggin spoon

MDB isn't a 'BACKEND' it is a frontend with a frontend

ADP and DAP do fucking rock

but MS has accepted mediocrity

and i am here to tell these fat and lazy MS project managers that they
need to quit the bullshit and start fixing bugs.

come out with a goddamn patch for ADP against SQL 2005 if you know
whats good for you

fucking piece of shit crack smoking company
and a bunch of MDB _SISSIES_

it's no longer 1997 kids
 
A

aaron.kempf

wait a second

you've never found the need to use queries on top of queries?

what the **** are you talking about?

like seriously; is the workaround so ingrained in you that you dont
even think about it?

DOES A REAL DATABASE MAKE YOU PUSH EVERYTHING AND ANYTHING INTO A TEMP
TABLE?

REAL QUERY ENGINES DON'T REQUIRE THIS.

And you're all worried about bloat.

SHIT KID; ADP IS THE ANSWER TO BLOAT DORK!!!
 
A

aaron.kempf

no serious TOM

why do you screw with a bloated database?

i mean-- aren't you tired of having to reboot windows servers just
because some MDB locks up?

MDB isn't ready for primetime; it never has been.
and you lamers are too retarded to bitch and moan about it.

there is a better way.

it isn't bug free-- i'll be the first to admit it.

but when it comes down to either

a) having difficulty learning how to write sprocs
or
b) losing data?

you know where I made that decision.

losing data with MDB is unavoidable. It doesn't have real backup and
restore capabilities; there are no JOBS.
and the ETL for MDB? GAG ME WITH A SPOON.
 
Top