PermissionError: [Errno 13] Permission denied: 'Abc.xlsx'

[Dennis Lee Bieber]

On Tue, 8 Feb 2022 23:46:15 -0800 (PST), NArshad <narshad.380 at 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
	wlfraed at ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/