When I enter data using Tkinter form in an Excel file when the excel file is closed there is no error but when I enter data using Tkinter form when the excel is already open following error comes:

Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Users\Dani Brothers\Anaconda3\lib\tkinter\__init__.py", line 1705, in __call__
return self.func(*args)
File "D:/Python/Book Bank/New folder/PyCharm/Final/Excel.py", line 61, in SaveBook
workbook.save(filename="BookBank.xlsx")
File "C:\Users\Dani Brothers\Anaconda3\lib\site-packages\openpyxl\workbook\workbook.py", line 392, in save
save_workbook(self, filename)
File "C:\Users\Dani Brothers\Anaconda3\lib\site-packages\openpyxl\writer\excel.py", line 291, in save_workbook
archive = ZipFile(filename, 'w', ZIP_DEFLATED, allowZip64=True)
File "C:\Users\Dani Brothers\Anaconda3\lib\zipfile.py", line 1207, in __init__
self.fp = io.open(file, filemode)
PermissionError: [Errno 13] Permission denied: 'Abc.xlsx'

What to do to correct this error? I have already searched on google search many times but no solution was found.

Am 09.02.22 um 08:46 schrieb NArshad:
> When I enter data using Tkinter form in an Excel file when the excel file is closed there is no error but when I enter data using Tkinter form when the excel is already open following error comes:

> PermissionError: [Errno 13] Permission denied: 'Abc.xlsx'
>
>
>
> What to do to correct this error? I have already searched on google search many times but no solution was found.

It's impossible. Excel locks the file deliberately when it is open, so
that you can't overwrite it from a different program. Otherwise, the
file could become inconsistent.

The correct way to handle it in the GUI is to tell the user via a
message box that the file is open and can't be written.

An alternative to writing the file directly would be that you remote
control Excel; I think it provides a DDE API:
https://support.microsoft.com/en-us/office/dde-function-79e8b21c-2054-4b48-9ceb-d2cf38dc17f9

Christian

On Wednesday, February 9, 2022 at 12:46:49 PM UTC, Christian Gollwitzer wrote:
> Am 09.02.22 um 08:46 schrieb NArshad:
> > When I enter data using Tkinter form in an Excel file when the excel file is closed there is no error but when I enter data using Tkinter form when the excel is already open following error comes:
> > PermissionError: [Errno 13] Permission denied: 'Abc.xlsx'
> >
> >
> >
> > What to do to correct this error? I have already searched on google search many times but no solution was found.
> It's impossible. Excel locks the file deliberately when it is open, so
> that you can't overwrite it from a different program. Otherwise, the
> file could become inconsistent.
>
> The correct way to handle it in the GUI is to tell the user via a
> message box that the file is open and can't be written.
>
> An alternative to writing the file directly would be that you remote
> control Excel; I think it provides a DDE API:
> https://support.microsoft.com/en-us/office/dde-function-79e8b21c-2054-4b48-9ceb-d2cf38dc17f9
>
DDE? Wow, that takes me back...

On 2022-02-09 12:45, Christian Gollwitzer wrote:
> Am 09.02.22 um 08:46 schrieb NArshad:
>> When I enter data using Tkinter form in an Excel file when the excel file is closed there is no error but when I enter data using Tkinter form when the excel is already open following error comes:
>
>> PermissionError: [Errno 13] Permission denied: 'Abc.xlsx'
>>
>>
>>
>> What to do to correct this error? I have already searched on google search many times but no solution was found.
>
> It's impossible. Excel locks the file deliberately when it is open, so
> that you can't overwrite it from a different program. Otherwise, the
> file could become inconsistent.
>
It's the same the other way too; you can't open the file in Excel while
Python has it open.

> The correct way to handle it in the GUI is to tell the user via a
> message box that the file is open and can't be written.
>
> An alternative to writing the file directly would be that you remote
> control Excel; I think it provides a DDE API:
> https://support.microsoft.com/en-us/office/dde-function-79e8b21c-2054-4b48-9ceb-d2cf38dc17f9
>

On Fri, 11 Feb 2022 at 06:41, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
>
> On Wed, 9 Feb 2022 18:50:12 +0000, MRAB <python@mrabarnett.plus.com>
> declaimed the following:
>
> >On 2022-02-09 12:45, Christian Gollwitzer wrote:
>
> >> It's impossible. Excel locks the file deliberately when it is open, so
> >> that you can't overwrite it from a different program. Otherwise, the
> >> file could become inconsistent.
> >>
> >It's the same the other way too; you can't open the file in Excel while
> >Python has it open.
> >
> While not tested with Excel, I /have/ encountered cases where an
> application has locked the file for writing, but multiple readers are
> permitted. Those would fail then if one attempts to write. {The other view
> point is a library that does a complete open/read\write-all/close to memory
> -- such an application might open/read/close, then Excel opens/locks, with
> the application only learning of the change when it attempts the
> open/write/close cycle}
>

Yeah, I doubt Excel is that sophisticated. It's built on an assumption
of single-user operation.

ChrisA

Am 10.02.22 um 20:43 schrieb Chris Angelico:
> On Fri, 11 Feb 2022 at 06:41, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
>> While not tested with Excel, I /have/ encountered cases where an
>> application has locked the file for writing, but multiple readers are
>> permitted. Those would fail then if one attempts to write. {The other view
>> point is a library that does a complete open/read\write-all/close to memory
>> -- such an application might open/read/close, then Excel opens/locks, with
>> the application only learning of the change when it attempts the
>> open/write/close cycle}
>>
>
> Yeah, I doubt Excel is that sophisticated. It's built on an assumption
> of single-user operation.
>

It guards against multiple user opening the same file over network
drives. All MS applications create lock files with weird names like
~.original-name.xlsx etc. If you open a file on the network share, and a
colleague tries to open it from a second machine, then he will get the
message "File locked by user xy from machine z". See here for word:
https://support.microsoft.com/en-us/topic/-the-document-is-locked-for-editing-by-another-user-error-message-when-you-try-to-open-a-document-in-word-10b92aeb-2e23-25e0-9110-370af6edb638

I believe (haven't tested) that this is cooperative locking only and it
doesn't help if you alter the file from another program. On the same
machine though, I think that Excel opens the file with a flag to lock it
from other processes. At least that was my observation and also what the
OP has described.

Hence it is impossible to concurrently write from Python into an open
Excel file. One might ask what the real problem is the user is trying to
solve. Is Excel a requirement, can it be swapped by a database engine?

Best regards,

Christian

On Fri, 11 Feb 2022 at 07:57, Christian Gollwitzer <auriocus@gmx.de> wrote:
>
> Am 10.02.22 um 20:43 schrieb Chris Angelico:
> > On Fri, 11 Feb 2022 at 06:41, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> >> While not tested with Excel, I /have/ encountered cases where an
> >> application has locked the file for writing, but multiple readers are
> >> permitted. Those would fail then if one attempts to write. {The other view
> >> point is a library that does a complete open/read\write-all/close to memory
> >> -- such an application might open/read/close, then Excel opens/locks, with
> >> the application only learning of the change when it attempts the
> >> open/write/close cycle}
> >>
> >
> > Yeah, I doubt Excel is that sophisticated. It's built on an assumption
> > of single-user operation.
> >
>
> It guards against multiple user opening the same file over network
> drives. All MS applications create lock files with weird names like
> ~.original-name.xlsx etc. If you open a file on the network share, and a
> colleague tries to open it from a second machine, then he will get the
> message "File locked by user xy from machine z". See here for word:
> https://support.microsoft.com/en-us/topic/-the-document-is-locked-for-editing-by-another-user-error-message-when-you-try-to-open-a-document-in-word-10b92aeb-2e23-25e0-9110-370af6edb638
>

Yeah, but that's still just hard locking, no "one writer multiple
readers" system or anything.

> I believe (haven't tested) that this is cooperative locking only and it
> doesn't help if you alter the file from another program. On the same
> machine though, I think that Excel opens the file with a flag to lock it
> from other processes. At least that was my observation and also what the
> OP has described.
>

That sounds right; and, again, it's just a simple exclusive lock.
Excel doesn't have the sophistication to need or want anything more
than simple "I have this file, nobody else touch it" exclusive
locking.

ChrisA

On 2022-02-11 08:11:32 +1100, Chris Angelico wrote:
> Excel doesn't have the sophistication to need or want anything more
> than simple "I have this file, nobody else touch it" exclusive
> locking.

Interestingly, Excel did have the ability for multiple users editing the
same file at some time (maybe early 2000s? Way before Google docs or
Office 365). It had to be explicitely enabled and it didn't work very
reliably (at least not with Samba as file servers), so we never really
used it but it is clear that somebody at MS thought that users needed or
at least wanted that ability.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 2022-02-11 18:20:19 -0500, Dennis Lee Bieber wrote:
> On Fri, 11 Feb 2022 20:37:57 +0100, "Peter J. Holzer" <hjp-python@hjp.at>
> declaimed the following:
>
> >Interestingly, Excel did have the ability for multiple users editing the
> >same file at some time (maybe early 2000s? Way before Google docs or
^^^^^^^^^^
> >Office 365). It had to be explicitely enabled and it didn't work very
^^^^^^^^^^
> >reliably (at least not with Samba as file servers), so we never really
> >used it but it is clear that somebody at MS thought that users needed or
> >at least wanted that ability.
>
> A quick Google does find mention of "shared workbooks":
> https://docs.microsoft.com/en-us/office/troubleshoot/excel/use-shared-workbook

| To make changes to a shared workbook that was created in Microsoft Excel 97
| or a later version of Excel, you must use Excel 97 or a later version of Excel.

So apparently that ability was added in Excel 97.

> The preferred mode requires "Microsoft 365 subscription" and latest
> Office version:

Yes, these days you would use Office 365 for that kind of functionality,
but that didn't exist at that time (neither did cloud storage systems).

Network file systems like NFS or SMB did exist, though, and people
wanted (or at least MS thought they wanted) to collaborate on Excel
files. So Excel provided a way to do that.

That was sort of the point: That Excel was not *always* single-user.
There have been ways that multiple users could simultaneously edit the
same file for 25 years.

> However -- the key feature is that these are Excel-Excel(-Excel...)
> operations

I'm pretty sure that that worked entirely through the file system. So
the only thing stopping you from implementing it in a different program
was the lack of documentation (as was typical for MS in the 1990's).

But again, this wasn't my point. My point was that Excel files are
designed to be used only by a single process isn't true.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"