You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Excel formulas not showing correctly on share account version of file
I inherited ownership of a shared spreadsheet from a retiring colleague. I moved the 'original' spreadsheet to my own (local) Dropbox folder on my machine. I have subsequently edited the spreadsheet t...
EWeberMU wrote:
I am not using a reference to the file's name on my own local computer. As a result, when the file gets synced to each shared Dropbox user's file, this "filename" reference should now reference whatever their file name is (including path location, etc.) Unless there is some literal translation that is getting embedded within the CELL function that I can't control, this shouldn't be an issue. What do you think?
I was originally thinking that you replaced the path to the file with the word "filename" in an attempt to expunge the actual name of the file. That being said, if filename is truly nothing more than a reference to itself, and Office doesn't try to replace that with the full path, then it should be fine. If Office is replacing filename and instead embedding the full path and saving it within the file, it won't work.
Either way, Dropbox isn't the cause. It simply can't change your file in that manner. All Dropbox does is move files around. There's not even anything special about the Dropbox folder. It's just a folder like any other on the computer.
Have them drag the file out of the Dropbox folder on their computer and then open it. What happens?
I have discovered the details about this situation that points to a new problem. The problem is that when some of my colleagues received an Email notice from Dropbox that the Excel spreadsheet has been updated, if those users do not have the Dropbox app installed on their local machines, but DO have an Office 365 account, then the web link in the Email opens the Excel file in a cloud-based location presumably instead of using their local installation of Excel and the synced version of the file. As a result of this web-based Excel program, it cannot resolve the file name properly. A work-around solution was to have my colleagues install the Dropbox app on their local machines. That way, when the open the file that way, then Excel is working with their local, synced file. The larger problem that this points to is that any document that expects to work with 'file information' when the physical file is being processed in a dynamic (think SaaS or cloud) implementation may discover that the non-local program may not have the ability to access information about the non-local file properties. With more and more people and organizations moving to SaaS programs, this may be something that needs to be considered.
Update to my question below:
I found my solution here:THank you
Rich
Super User II
Super User IIDropbox does not alter your files so it likely has nothing to do with the error. All Dropbox does is sync the file from one computer to another. The file is the same on both ends.
You appear to be referencing an external file in the formula. Office usually uses the full path to a file, and the full path to a file stored in Dropbox will be different from one computer to another. Meaning, it will work on the computer that created it, but on another computer the formula is looking for a file that does not exist.
You appear to be referencing an external file in the formula. Office usually uses the full path to a file, and the full path to a file stored in Dropbox will be different from one computer to another. Meaning, it will work on the computer that created it, but on another computer the formula is looking for a file that does not exist.
Hey Rich,
Thanks for replying but I don't think your response is correct. I am using the CELL function with a "filename" parameter. The actual parameter is the literal keyword "filename" in quotes. I am not using a reference to the file's name on my own local computer. As a result, when the file gets synced to each shared Dropbox user's file, this "filename" reference should now reference whatever their file name is (including path location, etc.) Unless there is some literal translation that is getting embedded within the CELL function that I can't control, this shouldn't be an issue. What do you think?
- MarkGoing to be honest and say I'm not 100% sure around the 'filename' command - google is best bet for that, however, Rich's response around Dropbox not changing anything is spot on. So somewhere along the line the formulae isnt working between the machines and isnt playing well with things.
You may get more specific advice and help on the Microsoft forumsHey Mark,
Thanks for the follow-up and I do agree with both your's and Rich's responses... The problem is when I raised this issue on Micro$oft's forums, they are saying that my assessment was correct - that the formula looks for the 'current' file's name when processing the "filename" keyword parameter of the CELL function so, if it is not working when used 'within some third party's sharing facility', then it must be that third-party's sharing or syncing process that is causing the problem... In other words... they are pointing the finger at Dropbox... And Dropbox is saying it's a Microsoft Excel issue... and us poor end user's are left without a solution... Not trying to shoot or shout at the messengers... (I really do appreciate your efforts!!!) I'm just frustrated that I can't find a solution.
- MarkDropbox is no different to a USB pen or email.
It simply transfers the files between users. And it has the added bonus in it that hashchecks the files to make sure they are exact replicas of the original, unlike say a USB move.
- Rich
EWeberMU wrote:
I am not using a reference to the file's name on my own local computer. As a result, when the file gets synced to each shared Dropbox user's file, this "filename" reference should now reference whatever their file name is (including path location, etc.) Unless there is some literal translation that is getting embedded within the CELL function that I can't control, this shouldn't be an issue. What do you think?
I was originally thinking that you replaced the path to the file with the word "filename" in an attempt to expunge the actual name of the file. That being said, if filename is truly nothing more than a reference to itself, and Office doesn't try to replace that with the full path, then it should be fine. If Office is replacing filename and instead embedding the full path and saving it within the file, it won't work.
Either way, Dropbox isn't the cause. It simply can't change your file in that manner. All Dropbox does is move files around. There's not even anything special about the Dropbox folder. It's just a folder like any other on the computer.
Have them drag the file out of the Dropbox folder on their computer and then open it. What happens?
I have discovered the details about this situation that points to a new problem. The problem is that when some of my colleagues received an Email notice from Dropbox that the Excel spreadsheet has been updated, if those users do not have the Dropbox app installed on their local machines, but DO have an Office 365 account, then the web link in the Email opens the Excel file in a cloud-based location presumably instead of using their local installation of Excel and the synced version of the file. As a result of this web-based Excel program, it cannot resolve the file name properly. A work-around solution was to have my colleagues install the Dropbox app on their local machines. That way, when the open the file that way, then Excel is working with their local, synced file. The larger problem that this points to is that any document that expects to work with 'file information' when the physical file is being processed in a dynamic (think SaaS or cloud) implementation may discover that the non-local program may not have the ability to access information about the non-local file properties. With more and more people and organizations moving to SaaS programs, this may be something that needs to be considered.
Update to my question below:
I found my solution here:THank you
