Get ProcessID for Excel Instance started by Access Session

if this have something to do with your previous question that is giving you error, try this codes

Private Sub LoadTPR(strFile As String)
      Const strProcedure As String = "LoadTPR"
      Dim xlObj as Object

      Dim strCsv As String
    On Error GoTo ErrorHandler
 
    strCsv = CurrentProject.Path & "\TPR.csv"
      ' Delete csv file
    On Error Resume Next
    Kill strCsv
    Err.Clear
    On Error GoTo ErrorHandler
	set xlObj=createobject("excel.application")
		xlObj.workbooks.open strFile, False, False
		xlObj.visible=true  ' if you don't want to see the excel application, just comment this line
		
			with xlObj
				.worksheets(1).select
				.columns("L:L").numberFormat="0"
				.columns("P:P").numberFormat="0"
				.columns("O:O").numberFormat="0.00"
				.columns("M:N").numberFormat="0.000000"
			    .activeworkbook.saveas strcsv,FileFormat:=6, createbackup:=false
				.activeworkbook.saved=true
			end with
			
			xlObj.quit
			set xlObj=nothing
			
   DoCmd.SetWarnings False
   DoCmd.TransferText acImportDelim, "TPR Import Specification", "tblTPR", strCsv
	DoCmd.SetWarnings True

ErrExit:
		xlObj.quit
		set xlObj=nothing
        exit sub

ErrorHandler:
   DoCmd.Hourglass False
   Debug.Print strProcedure & " Error: " & Err.Description & " (" & Err & ") on line " & Erl
   Err.clear
   Resume ErrExit
End Sub

Select allOpen in new window

I'm at home now, working in Access 2010 on a Windows 7 Ultimate platform. Having trouble finding GetWindowThreadProcessId. Is there some reference I should be adding to the db?

GetWindowThreadProcessId was declared on the 4th line of code that I gave.  It is embedded in Windows...

I use Windows 7 Home Premium... Access 2010... I included all the code in my standard module.

Yes I included the declare, but Access isn't finding it. Won't compile(?). I am running 64 bit.

what does the error message say?

As a matter of note, I am running 64 bit as well...

I tried compiling again. Got the error. Copied the code into a separate module so I could get a better snapshot to post, and it now compiled. I'm doing some runs right now with more than one instance of Excel in the stack. Will get back to you in a couple of minutes.

Works great, fhlio_admin. Let me wrap some things up here then I'll award the points and close this out in the next couple of minutes.
Thank you very much

Capicorn1: I guess you could say this question is tangentially related to the earlier question. That code code is working; but I continued to dig in since I was trying to figure out why the code would work on the first iteration and not for any subsequent tries. That, in turn, led me to working on managing multiple instances of Excel in the stack.
I'm looking at ways to ensure that any instances of Excel started within an Access session are explicitly ended when I'm done with the instance. I've found that quitting the application ('xlsApp.Quit') works pretty well, but I want to cover my bases.
The intent behind getting the ProcessID is to be able to kill the specific Excel instance.
For some time I've had the following KillExcel sub in my toolbox:

Public Sub KillExcel()
   Dim s As String
   On Error Resume Next
   s = "TASKKILL /F /IM Excel.exe"
   Shell s, vbHide
   On Error GoTo 0
End Sub

But that sub is a little ham-fisted. Users often have multiple workbooks opened up on the desktop along with the Access database, and I can't have my apps indiscriminately blowing their opened workbooks out of the water. Knowing the ProcessID allows me to modify the sub as follows:

Public Sub KillExcel(Optional lngPID As Long = 0)
   Dim s As String
   On Error Resume Next
   If Not lngPID = 0 Then
      s = "TASKKILL /pid " & lngPID
   Else
      s = "TASKKILL /F /IM Excel.exe"
   End If
   Shell s, vbHide
   Err.Clear
End Sub

Now, so long as I know the ProcessID, I can surgically force the correct instance of Excel off the stack.

fhlio_admin: Thank you very much.
Todd

Todd,
test the codes i posted and  see if the you still get the error you were getting before.
i been using the same coding in my app and never had a problem.