Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PermissionError: [Errno 13] Permission denied: 'Abc.xlsx'
1,970 views
Skip to first unread message
NArshad
Feb 9, 2022, 2:47:04 AM2/9/22
to
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.
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.
Christian Gollwitzer
Feb 9, 2022, 7:46:49 AM2/9/22
to
Am 09.02.22 um 08:46 schrieb NArshad:
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
> 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
>
>
>
> What to do to correct this error? I have already searched on google search many times but no solution was found.
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
jkn
Feb 9, 2022, 10:25:29 AM2/9/22
to
MRAB
Feb 9, 2022, 1:54:29 PM2/9/22
to
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
> 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.
>
Python has it open.
Dennis Lee Bieber
Feb 9, 2022, 2:19:47 PM2/9/22
to
On Tue, 8 Feb 2022 23:46:15 -0800 (PST), NArshad <narsh...@gmail.com>
declaimed the following:
>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:
>
<SNIP>
>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.
Well -- at the basic level... Make sure that only ONE user/application
has access to the file at any given moment.
Excel (and spreadsheets opened by it) are single-user applications for
a reason -- to prevent the data in the file from being changed without the
application knowing about it. They are not databases designed to allow
multiple users to make changes.
YOU will have to implement transaction control over the file. At the
rudimentary level (since you can't change how Excel itself operates)
whenever you intend to save changes to the data you have to notify any user
that has the file open that they need to close/save the file; when that has
been done you have to reread the file (because they may have made changes
to the contents that you haven't seen yet), reapply any of your changes (if
still valid conditions), then save the file. You can then notify the other
users that the file is updated and can be opened by them. If you don't
reread/validate the data before applying your changes, you would wipe out
any changes made by others.
Now, if you have total control over the applications that will access
the file (which essentially means: NOBODY will use Excel itself) you could
write a client/server scheme. In this scheme you would have one process
(the server) as the only program that does anything with the spreadsheet
file and its contents. Your client programs would connect (TCP sockets most
likely) to the server process and send it "commands" (something to be
defined/documented is an interface control document); the server would
parse the commands and implement changes to the file data, and/or return
any requested data to the client. That, at least avoids the file level
conflicts. You still have to figure out how to handle the case where two
clients try to update the same record (record level locking).
One possibility is to have every record contain a time-stamp of the
last change -- and I'm going to assume the "commands" are record based, not
cell based -- and the command protocol for update sends back the time-stamp
originally read; the server code would compare the time-stamp with what
that record has in the file -- if they are the same, update the entire
record including a new time-stamp; if different, return a "conflict" status
with the current state of the record (with time-stamp) -- the client can
then compare the new record with the stale one, make any changes, and retry
the update. NOTE: this takes care of single record conflicts, but will help
if a "transaction" has to update multiple records since there is no history
to allow "all or none succeed" logic to be implemented.
"Commands"
READREC <recno>
returns status (no such record) and (if valid) specified
record including last time-stamp
WRITEREC <recno> <record including last time-stamp>
returns status (update conflict and current record contents
with time-stamp); if recno is unused, can pass 0 for timestamp to write new
record; upon write the time-stamp is updated
UPDATE
basically same as WRITEREC
FIND <column list> <find-string>
returns list of recno for records matching the search (not
the records themselves)
A proper client/server database handles most of the problem of keeping
the data (file) uncorrupted... Though clients attempting to update the same
record will have one succeed, the other get an exception -- which would be
handled by: rereading the record(s) one attempted to update, confirming the
conditions for the update are still valid, and reapplying the update.
Multiple record updates within a transaction are possible.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
declaimed the following:
>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.
has access to the file at any given moment.
Excel (and spreadsheets opened by it) are single-user applications for
a reason -- to prevent the data in the file from being changed without the
application knowing about it. They are not databases designed to allow
multiple users to make changes.
YOU will have to implement transaction control over the file. At the
rudimentary level (since you can't change how Excel itself operates)
whenever you intend to save changes to the data you have to notify any user
that has the file open that they need to close/save the file; when that has
been done you have to reread the file (because they may have made changes
to the contents that you haven't seen yet), reapply any of your changes (if
still valid conditions), then save the file. You can then notify the other
users that the file is updated and can be opened by them. If you don't
reread/validate the data before applying your changes, you would wipe out
any changes made by others.
Now, if you have total control over the applications that will access
the file (which essentially means: NOBODY will use Excel itself) you could
write a client/server scheme. In this scheme you would have one process
(the server) as the only program that does anything with the spreadsheet
file and its contents. Your client programs would connect (TCP sockets most
likely) to the server process and send it "commands" (something to be
defined/documented is an interface control document); the server would
parse the commands and implement changes to the file data, and/or return
any requested data to the client. That, at least avoids the file level
conflicts. You still have to figure out how to handle the case where two
clients try to update the same record (record level locking).
One possibility is to have every record contain a time-stamp of the
last change -- and I'm going to assume the "commands" are record based, not
cell based -- and the command protocol for update sends back the time-stamp
originally read; the server code would compare the time-stamp with what
that record has in the file -- if they are the same, update the entire
record including a new time-stamp; if different, return a "conflict" status
with the current state of the record (with time-stamp) -- the client can
then compare the new record with the stale one, make any changes, and retry
the update. NOTE: this takes care of single record conflicts, but will help
if a "transaction" has to update multiple records since there is no history
to allow "all or none succeed" logic to be implemented.
"Commands"
READREC <recno>
returns status (no such record) and (if valid) specified
record including last time-stamp
WRITEREC <recno> <record including last time-stamp>
returns status (update conflict and current record contents
with time-stamp); if recno is unused, can pass 0 for timestamp to write new
record; upon write the time-stamp is updated
UPDATE
basically same as WRITEREC
FIND <column list> <find-string>
returns list of recno for records matching the search (not
the records themselves)
A proper client/server database handles most of the problem of keeping
the data (file) uncorrupted... Though clients attempting to update the same
record will have one succeed, the other get an exception -- which would be
handled by: rereading the record(s) one attempted to update, confirming the
conditions for the update are still valid, and reapplying the update.
Multiple record updates within a transaction are possible.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Dennis Lee Bieber
Feb 10, 2022, 1:22:32 PM2/10/22
to
On Wed, 9 Feb 2022 18:50:12 +0000, MRAB <pyt...@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}
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.
>
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}
Chris Angelico
Feb 10, 2022, 2:44:15 PM2/10/22
to
On Fri, 11 Feb 2022 at 06:41, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>
> On Wed, 9 Feb 2022 18:50:12 +0000, MRAB <pyt...@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
>
> On Wed, 9 Feb 2022 18:50:12 +0000, MRAB <pyt...@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}
>
of single-user operation.
ChrisA
Christian Gollwitzer
Feb 10, 2022, 3:43:38 PM2/10/22
to
Am 10.02.22 um 20:43 schrieb Chris Angelico:
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
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
Chris Angelico
Feb 10, 2022, 4:13:13 PM2/10/22
to
On Fri, 11 Feb 2022 at 07:57, Christian Gollwitzer <auri...@gmx.de> wrote:
>
> Am 10.02.22 um 20:43 schrieb Chris Angelico:
> > On Fri, 11 Feb 2022 at 06:41, Dennis Lee Bieber <wlf...@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
>
> Am 10.02.22 um 20:43 schrieb Chris Angelico:
> > On Fri, 11 Feb 2022 at 06:41, Dennis Lee Bieber <wlf...@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
>
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.
>
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
Dennis Lee Bieber
Feb 10, 2022, 6:01:12 PM2/10/22
to
On Thu, 10 Feb 2022 21:39:05 +0100, Christian Gollwitzer <auri...@gmx.de>
declaimed the following:
>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?
>
Based upon the path names shown by the OP, this is just a continuation
of the January thread...
Message-ID: <199c23c7-de58-44ae...@googlegroups.com>
Subject: What to write or search on github to get the code for what is
written below:
From: NArshad <narsh...@gmail.com>
Injection-Date: Thu, 06 Jan 2022 18:55:30 +0000
... in which the OP insists they are required to manipulate a (never fully
specified) spreadsheet maintained in an Excel format file. The main
take-away in the current thread is that the OP has relinquished the idea of
a web-based application, for a local Tkinter GUI (and apparently has
actually written some code finally, as they produced a traceback message
sequence <G> -- however, the code-first_then-come-here lesson isn't
sticking if you look at their second thread of the week).
declaimed the following:
>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?
>
of the January thread...
Message-ID: <199c23c7-de58-44ae...@googlegroups.com>
Subject: What to write or search on github to get the code for what is
written below:
From: NArshad <narsh...@gmail.com>
Injection-Date: Thu, 06 Jan 2022 18:55:30 +0000
... in which the OP insists they are required to manipulate a (never fully
specified) spreadsheet maintained in an Excel format file. The main
take-away in the current thread is that the OP has relinquished the idea of
a web-based application, for a local Tkinter GUI (and apparently has
actually written some code finally, as they produced a traceback message
sequence <G> -- however, the code-first_then-come-here lesson isn't
sticking if you look at their second thread of the week).
Peter J. Holzer
Feb 11, 2022, 2:39:17 PM2/11/22
to
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
> Excel doesn't have the sophistication to need or want anything more
> than simple "I have this file, nobody else touch it" exclusive
> locking.
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.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Dennis Lee Bieber
Feb 11, 2022, 6:21:24 PM2/11/22
to
On Fri, 11 Feb 2022 20:37:57 +0100, "Peter J. Holzer" <hjp-p...@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
https://support.microsoft.com/en-us/office/what-happened-to-shared-workbooks-150fc205-990a-4763-82f1-6c259303fe05
The preferred mode requires "Microsoft 365 subscription" and latest
Office version:
https://support.microsoft.com/en-us/office/collaborate-on-excel-workbooks-at-the-same-time-with-co-authoring-7152aa8b-b791-414c-a3bb-3024e46fb104
However -- the key feature is that these are Excel-Excel(-Excel...)
operations (and the co-author mode needs M$ subscription and use of
OneDrive cloud storage).
Most Python libraries are working directly with the Excel format data
file, not by running Excel.
Caveat: there is a product that appears to use the Excel component API
to control Excel itself, not just read/write xls(*) files -- so it might
understand the older shared workbook mode, but I'd recommend a detailed
study of the API and the sharing operations first:
https://www.xlwings.org/
https://docs.xlwings.org/en/stable/
"""
xlwings (Open Source) is a BSD-licensed Python library that makes it easy
to call Python from Excel and vice versa:
* Scripting: Automate/interact with Excel from Python using a syntax
close to VBA.
* Macros: Replace VBA macros with clean and powerful Python code.
* UDFs: Write User Defined Functions (UDFs) in Python (Windows only).
"""
If running under Windows, similar capability should be possible using
the win32py (or whatever the current name is) extension... Or with more
difficulty, ctypes!
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.
https://docs.microsoft.com/en-us/office/troubleshoot/excel/use-shared-workbook
https://support.microsoft.com/en-us/office/what-happened-to-shared-workbooks-150fc205-990a-4763-82f1-6c259303fe05
The preferred mode requires "Microsoft 365 subscription" and latest
Office version:
https://support.microsoft.com/en-us/office/collaborate-on-excel-workbooks-at-the-same-time-with-co-authoring-7152aa8b-b791-414c-a3bb-3024e46fb104
However -- the key feature is that these are Excel-Excel(-Excel...)
operations (and the co-author mode needs M$ subscription and use of
OneDrive cloud storage).
Most Python libraries are working directly with the Excel format data
file, not by running Excel.
Caveat: there is a product that appears to use the Excel component API
to control Excel itself, not just read/write xls(*) files -- so it might
understand the older shared workbook mode, but I'd recommend a detailed
study of the API and the sharing operations first:
https://www.xlwings.org/
https://docs.xlwings.org/en/stable/
"""
xlwings (Open Source) is a BSD-licensed Python library that makes it easy
to call Python from Excel and vice versa:
* Scripting: Automate/interact with Excel from Python using a syntax
close to VBA.
* Macros: Replace VBA macros with clean and powerful Python code.
* UDFs: Write User Defined Functions (UDFs) in Python (Windows only).
"""
If running under Windows, similar capability should be possible using
the win32py (or whatever the current name is) extension... Or with more
difficulty, ctypes!
Peter J. Holzer
Feb 12, 2022, 3:18:29 PM2/12/22
to
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-p...@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
^^^^^^^^^^
> On Fri, 11 Feb 2022 20:37:57 +0100, "Peter J. Holzer" <hjp-p...@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
> >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
| 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:
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
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.
0 new messages