How do I write to an excel file (xlsx or csv) that is on a shared network drive if another user has it open

I am using the standard writecell. I want to append to that excel file some data. However, that doesnt work if another user has the file open. In LabVIEW I am able to append to a file even if its Open. I tried active X but ran into some issues with openeing the workbook. I checked my excel and Active X is enabled.

filePath = fullfile(app.save_path,app.filename);

try
    excel = actxGetRunningServer('Excel.Application');
catch
    app.SystemMessage.Value='No open instance of Excel found. Ensure the Excel file is open.';
    app.ResultsLamp.Color=[[1 0 0]];
    app.status_reset=0;
end
% Get the workbook (ensure the file path matches the open file)
try
    workbook = excel.Workbooks.Item(filePath);
catch
    app.SystemMessage.Value='The specified file is not open in Excel.';
    pause(3)
    app.SystemMessage.Value='Export failed...check if file is open';
    app.ResultsLamp.Color=[[1 0 0]];
    app.status_reset=0; 
end
% Access the first worksheet (or specify another worksheet by name)
sheet = workbook.Sheets.Item(1); % Modify to your target sheet number or name
% Find the first empty row in column A (modify if using a different column as reference)
row = 1; % Start checking from the first row
while ~isempty(sheet.Cells.Item(row, 1).Value)
    row = row + 1;
end
% Define the range to write data
[numRows, numCols] = size(data);
startCell = sprintf('A%d', row); % Start writing at the first empty row in column A
endCell = sprintf('%s%d', char('A' + numCols - 1), row + numRows - 1);
range = sheet.Range(startCell, endCell);
% Write the data
range.Value = data;
% Optionally save the workbook to preserve the changes
workbook.Save;
% Clean up
excel.Release;
app.SystemMessage.Value='Export successful';

Answer 1

[Walter Roberson]

The fact that you are using activeX tells us that you are using Windows.

The Windows open-file system call accepts a parameter that indicates whether the open is for reading or for writing. Assuming no conflicts occur, the call locks the file and returns a file identifier. If the application is happy to have shared access, the application must then make another call that marks the open file as sharable.

If the open-file call encounters a file that is already marked as open and not shareable, then the open-file call fails.

If the open-file call encounters a file that is already marked as open, and read only access is requested and the file is marked for shared read, then the open-file call succeeds.

If the open-file call encounters a file that is already marked as open, and write access is requested and the file is marked for shared read, then the open-file call fails.

If the open-file call encounters a file that is already marked as open, and write access is requested and the file is marked for shared write, then the open-file call succeeds.

Now, as a matter of practice, most of the time that a file is opened for reading, it is routine to immediately grant shared read access to other processes. It is generally harmless to have multiple read-only readers of the same file.

As a matter of practice, much of the time that a file is open for writing, shared write access is not granted. Applications need to be specially written to avoid problems caused by shared writing, and it is often not worth the bother.

There are additional complications for networked files. Network access is often more crude than what is available for local access. It is common for mechanisms to prevent simultaneous writing of a write-shared file to not work for networked files, with the result that write-sharing is effectively disabled for the networked access (but meanwhile shared writing might still be active for multiple processes that are all present where the file is "local" instead of networked.)

In the case of shared network write-shared access to excel files, it is not surprising that it would fail.

The question becomes more how LabView is able to handle the file.