Closing an opened Excel spreadsheet correctly.

rdemyan via AccessMonster.com

I want to make sure that I'm closing an opened spreadsheet correctly. I've
been having some locking up problems. The following code adds a dummy row to
the spreadsheet to ensure that that the data gets transferred in the correct
format. It seems to be working correctly, but if anyone has any comments on
that I'd appreciate it. Right now, I'm mostly concerned about opening and
closing the spreadsheet. Here's the pertinent part of the code:
Private Sub AddDummyRow()

On Error GoTo Err_Ctrl

Dim xlsApp As Object, xlsWB As Object, xlsWS As Object
Dim mNumRows As Long, i As Integer
Dim boolXL As Boolean

'************************************************* **************
'************************************************* **************
'First, add the dummy row
'************************************************* **************
'************************************************* **************

'Check to see if Excel is running
If fIsAppRunning("Excel") Then
Set xlsApp = GetObject(, "Excel.Application")
boolXL = False
Else
Set xlsApp = CreateObject("Excel.Application")
boolXL = True
End If
'Open the workbook
Set xlsWB = xlsApp.Workbooks.Open(Me.ImportFile)

'Open the selected sheet number
Set xlsWS = xlsWB.Worksheets(CInt(Me.SheetNumber))
'Add the dummy row as the 2nd row in the spreadsheet
'First row is column headers and they will be field names in table
xlsWS.Range("A2").EntireRow.Insert
xlsWS.Cells(2, 1) = "DUMMY"
xlsWS.Cells(2, 2) = "DUMMY"
xlsWS.Cells(2, 3) = "DUMMY"
xlsWS.Cells(2, 4) = "DUMMY"
xlsWS.Cells(2, 5) = "DUMMY"
xlsWS.Cells(2, 6) = 0
xlsWS.Cells(2, 7) = 0
xlsWS.Cells(2, 8) = 0
xlsWS.Cells(2, 9) = 0
xlsWS.Cells(2, 10) = "DUMMY"
xlsWS.Cells(2, 11) = 0
xlsWS.Cells(2, 12) = 0
xlsWS.Cells(2, 13) = "DUMMY"
xlsWS.Cells(2, 14) = "DUMMY"
xlsWS.Cells(2, 15) = "DUMMY"
xlsWS.Cells(2, 16) = "DUMMY"
mNumRows = xlsWS.UsedRange.Columns.Count
'************************************************* **************
'************************************************* **************
'Second, transfer the spreadsheet to the holding table
'************************************************* **************
'************************************************* **************
Call TransferTheSpreadsheet
Exit_Sub: On Error Resume Next

'Close the instance of Excel and don't save changes
Set xlsWS = Nothing
xlsWB.Close False 'Don't save changes to the workbook.
Set xlsWB = Nothing

If boolXL Then
xlsApp.Application.Quit
End If

Set xlsApp = Nothing

DoCmd.SetWarnings True
DoCmd.Hourglass False
DoCmd.Echo True
Exit Sub

--
Message posted via http://www.accessmonster.com

Jul 31 '06 #1

pietlinden

I've read that any time you use a SET statement, you should dereference
and destroy that pointer/variable. Basically, make sure you clean up
your own mess (the stuff you open/set).

Aug 3 '06 #2

pietlinden

I've read that any time you use a SET statement, you should dereference
and destroy that pointer/variable. Basically, make sure you clean up
your own mess (the stuff you open/set). For each of those you should
close the object and dereference (Set objThing = nothing).

Aug 3 '06 #3

RoyVidar

"rdemyan via AccessMonster.com" <u6836@uwewrote in message
<6416064b5f5f9@uwe>:

I want to make sure that I'm closing an opened spreadsheet correctly.
I've been having some locking up problems. The following code adds a
dummy row to the spreadsheet to ensure that that the data gets
transferred in the correct format. It seems to be working correctly,
but if anyone has any comments on that I'd appreciate it. Right now,
I'm mostly concerned about opening and closing the spreadsheet.
Here's the pertinent part of the code:
Private Sub AddDummyRow()

On Error GoTo Err_Ctrl

Dim xlsApp As Object, xlsWB As Object, xlsWS As Object
Dim mNumRows As Long, i As Integer
Dim boolXL As Boolean

'************************************************* **************
'************************************************* **************
'First, add the dummy row
'************************************************* **************
'************************************************* **************

'Check to see if Excel is running
If fIsAppRunning("Excel") Then
Set xlsApp = GetObject(, "Excel.Application")
boolXL = False
Else
Set xlsApp = CreateObject("Excel.Application")
boolXL = True
End If
'Open the workbook
Set xlsWB = xlsApp.Workbooks.Open(Me.ImportFile)

'Open the selected sheet number
Set xlsWS = xlsWB.Worksheets(CInt(Me.SheetNumber))
'Add the dummy row as the 2nd row in the spreadsheet
'First row is column headers and they will be field names in table
xlsWS.Range("A2").EntireRow.Insert
xlsWS.Cells(2, 1) = "DUMMY"
xlsWS.Cells(2, 2) = "DUMMY"
xlsWS.Cells(2, 3) = "DUMMY"
xlsWS.Cells(2, 4) = "DUMMY"
xlsWS.Cells(2, 5) = "DUMMY"
xlsWS.Cells(2, 6) = 0
xlsWS.Cells(2, 7) = 0
xlsWS.Cells(2, 8) = 0
xlsWS.Cells(2, 9) = 0
xlsWS.Cells(2, 10) = "DUMMY"
xlsWS.Cells(2, 11) = 0
xlsWS.Cells(2, 12) = 0
xlsWS.Cells(2, 13) = "DUMMY"
xlsWS.Cells(2, 14) = "DUMMY"
xlsWS.Cells(2, 15) = "DUMMY"
xlsWS.Cells(2, 16) = "DUMMY"
mNumRows = xlsWS.UsedRange.Columns.Count
'************************************************* **************
'************************************************* **************
'Second, transfer the spreadsheet to the holding table
'************************************************* **************
'************************************************* **************
Call TransferTheSpreadsheet
Exit_Sub: On Error Resume Next

'Close the instance of Excel and don't save changes
Set xlsWS = Nothing
xlsWB.Close False 'Don't save changes to the workbook.
Set xlsWB = Nothing

If boolXL Then
xlsApp.Application.Quit
End If

Set xlsApp = Nothing

DoCmd.SetWarnings True
DoCmd.Hourglass False
DoCmd.Echo True
Exit Sub

I think what is perhaps causing the problem here, is that you access/
open the same workbook both through automation, and through the
transfer
thingie at the same time.

I think you should try to ensure that when you invoke the Transfer
thingie, no instance of Excel holds the same file open, so either do
the
automation before the transfer thingie (if it's needed at all, is there
any reason this dummy row, if needed, couldn't be stuffed into the file
at the same time as the header row?), and ensure the workbook is closed
and saved (you might perhaps need a DoEvents or two) before firing the
Transfer thingie, or do the automation afterwards.

--
Roy-Vidar

Aug 3 '06 #4

Ron2006

RoyVidar,

The reason for the dummy line is really very simple.

When importing, Access will read a number of rows - somewhere between
20 and 30 - and determine whether the column is to be alphabetic or
numeric based on what it found in those 20+ lines. If you have a column
that has a mixture of data AND sometimes the first 50 lines or so
happen to be ALL numeric, Access will declare the column as numeric and
NOT import any and all of the cells that contain alphabetic data in
them for that column. The simple workaround is to create a DUMMY row
that forces Access to analyse the column correctly and then run a query
to delete the row.

Ron (been there, done that)

Aug 3 '06 #5

rdemyan via AccessMonster.com

Thanks for the response.

I just want to make sure I understand. You're suggesting that I close all of
the automation variables before I call the subroutine
"TransferTheSpreadsheet".

Seems to make sense. I'll give it a try.

Thanks.

RoyVidar wrote:

>"rdemyan via AccessMonster.com" <u6836@uwewrote in message
<6416064b5f5f9@uwe>:

>I want to make sure that I'm closing an opened spreadsheet correctly.
I've been having some locking up problems. The following code adds a

[quoted text clipped - 81 lines]

> DoCmd.Echo True
Exit Sub

I think what is perhaps causing the problem here, is that you access/
open the same workbook both through automation, and through the
transfer
thingie at the same time.

I think you should try to ensure that when you invoke the Transfer
thingie, no instance of Excel holds the same file open, so either do
the
automation before the transfer thingie (if it's needed at all, is there
any reason this dummy row, if needed, couldn't be stuffed into the file
at the same time as the header row?), and ensure the workbook is closed
and saved (you might perhaps need a DoEvents or two) before firing the
Transfer thingie, or do the automation afterwards.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200608/1

Aug 3 '06 #6

RoyVidar

"rdemyan via AccessMonster.com" <u6836@uwewrote in message
<6438f6bbc77c4@uwe>:

Thanks for the response.

I just want to make sure I understand. You're suggesting that I
close all of the automation variables before I call the subroutine
"TransferTheSpreadsheet".

Seems to make sense. I'll give it a try.

Thanks.

We'll, now I'm not too sure. I got a bit hung up in the name of the
function or sub you're calling, and assumed you were doing a
DoCmd.TransferSpreadSheet.

Now I realize there's no information about what methods you're using
in your sub or function.

If you're using the .TransferSpreadsheet method of the DoCmd object,
then yes, my suggestion is to close and save the workbook, and release
all the variables before this is performed.

If you're not using any of the Transfer.. methods, then I don't know.
Perhaps we would need to see the TransferTheSpreadsheet sub or
function?
Perhaps comment the on error resume next, and see if any errors raise
when you get one of your "locks".

--
Roy-Vidar

Aug 3 '06 #7

rdemyan via AccessMonster.com

Roy,

Yes the DoCmd.TransferSpreadSheet is used in the subroutine that is called.
I've already implemented your suggestion, but haven't had the chance to
really test it out.

I'll report back if I continue to have issues.

Thanks.

RoyVidar wrote:

>"rdemyan via AccessMonster.com" <u6836@uwewrote in message
<6438f6bbc77c4@uwe>:

>Thanks for the response.

[quoted text clipped - 5 lines]

>>
Thanks.

We'll, now I'm not too sure. I got a bit hung up in the name of the
function or sub you're calling, and assumed you were doing a
DoCmd.TransferSpreadSheet.

Now I realize there's no information about what methods you're using
in your sub or function.

If you're using the .TransferSpreadsheet method of the DoCmd object,
then yes, my suggestion is to close and save the workbook, and release
all the variables before this is performed.

If you're not using any of the Transfer.. methods, then I don't know.
Perhaps we would need to see the TransferTheSpreadsheet sub or
function?
Perhaps comment the on error resume next, and see if any errors raise
when you get one of your "locks".

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200608/1

Aug 5 '06 #8