We moved to Sharepoint Online (SPO) this year and are collaborating heavily in Excel365. The experience is something of a disaster and I am hoping that I might get some responses here about "best practice" or peoples' experiences in that environment.
Observation #1:
All Excel's now open with AutoSaveOn=True. This is a total disaster because people often open Office files to simply take a look. Early users were horrified when they realized they had accidentally changed an archive file. We addressed this issue by setting AutoSaveOn=False in Auto_open.
(The AutoSaveOn=True experience requires a complete rethink of accustomed operating patterns. The established pattern when changing a file is: 1) open the original; 2) make changes; 3) save under a new name. With AutoSaveOn=true, you must: 1) make a copy of the file in the file manager; 2) open the copied file; 3) make changes. We have not managed to retrain our user base.)
We now get a different issue. In a network environment where 5 users have an Excel open purely for reference, the 6th user who is editing that file often has to fight against Office/SPO to somehow get it saved. There exists a concept of a "file lock" and someone has it. Who is unclear, and releasing it seems next to impossible. Opening an Office file "read-only" on purpose does not seem to be a concept Microsoft recognizes.
Observation #2:
All our production Excels are XLMs, not least because of the Auto_Open above. That is, working Online is not an option. (Which may be just as well because the online experience does not compare for the Excel pro.) All our users therefore synchronize relevant SPO archives to their OneDrive (OD). This should be a good thing anyway, since we are also nomadic folk, often working from the road when there is no internet. SHOULD NOT be a problem, right?
Right ... Turns out that Excel surreptitiously replaces links to other Excels on the OD with links to SPO such that when you hit the road, Excel will just hang up trying to access stuff on an unavailable Internet/SPO :( The user is forced to repoint all links manually to his OD to make it work.
Except it won't - because the Auto_Open now fails. Turns out, AutoSaveOn is not a valid property in the absence of a network connection. It seems that there are two code bases of Excel. One that is invoked with a network present, the other when there is none.
Observation #3:
When the user has somehow survived the horrific offline experience and returns to a network, the spreadsheet links fail again. Excel now throws a completely incomprehensible hissy-fit, complaining that none of the OD files exist, even though they are patently there. The only way I know to cure this issue is by going thru all links again and repointing them to the identical paths. (Behind the scenes, Excel of course uses this dialog to replace links to OD with links to SPO.)
Conclusion:
It seems that the modern Excel really wants to work in AutoSave mode but Microsoft doesn't really manage the experience. There is also no transparent switching possible between working offline and working online. All of this appears to be owed to two different code bases - online and offline - trading under the same name "Excel". We do not really require the online experience. It would be perfectly adequate for our purposes to work with the offline code on OD only, and OD can update SPO when a network is present.
Question: Does anyone know how to fool Excel into using the offline code base even in the presence of a network connection?
Any other experiences or pointers?
Related
I'm currently writing my master dissertation about version control in Ms Excel and would love to understand the problem more thoroughly. Does anyone face the problem and would be willing to discuss this in a 10min zoom call? Will hopefully be able to provide the solution in 2 months time.
t.muller#lse.ac.uk
Problem description:
If I'm working on a spreadsheet and need input from my co-workers on the same spreadsheet, I'd start to send the sheet around (probably via Email if we worked on excel offline). Unfortunately, we tend to quickly lose an overview of the different versions in the chain, and it sometimes even happens that some of us are mistakenly working on an old version. As soon as we managed to gather the input from everyone, we struggle to get to the root of newly introduced bugs and understand and approve all changes made.
Hi guys,
I'm trying to push data from an excel file to a google spreadsheet, using VBA
User Story : When my user close excel, it automatically pushes the data into a back up on google sheet.
I've read some solutions about the Google API, but i do not understand how to use it.
if someone has an explanation it would be nice
Regards,
Thomas
Mixing Excel and Google is going to be a tough journey. They have a lot of compatible features and implementations and then a whole bunch of things that are just not compatible.
You won't be able to control what your users do in Excel so the "backup" may end up as a poor representation of the excel version.
If it is purely for backup, you could go the MSFT route and use OneDrive/O365 which keeps versions for you if you store in a local OneDrive. You can use auto save to keep your backup up to date.
You could go the google route by using sheets on the desktop browser.
As Thomas suggested, go with an off the shelf sync tool if the data and format is straight forward. I have had very mixed results for even some simple stuff.
Not wishing to start a tech-religion war by recommending one over the other but how you are trying to achieve this feels fraught with risk and may be hard to future-proof.
HTH.
I have been creating a text editor online, just for learning experience. I was curious what the best way to store multiple versions of a text file that is consistently changing is.
I've looked at a variety of options and I am yet to see a cheap, and scale-able option.
I've looked into Google Cloud Storage and Amazon S3. The only issue is that too many requests to save the file start to add up a lot in cost. I'd like files to be saved practically instantly, and also versioned every so often. I've also looked into data deduplication which looks like a great option, but I have not yet found a way to do it without writing my own software.
Any and all advice would be greatly appreciated. Thanks!
This is a very broad question, but the basic answer is usually some flavor of Operational Transform. Basically you don't want to be constantly sending the entire document back and forth between the user(s) and the server, nor do you want to overwrite the whole of the document repeatedly. Instead you want to store diffs. Then you need to deal with the idea that multiple users might be changing the file simultaneously, but possibly in different areas, and dealing with that effectively.
Wikipedia has some good, formal discussion of the idea: https://en.wikipedia.org/wiki/Operational_transformation
You wouldn't need all of that for a document that will only be edited by one person at a time, but even then, the answer is to think in terms of diffs from previous versions and only occasionally persist whole snapshots.
I saw allot of companies offering exe wrappers , but is there any in pdf side security programmatically ?
Well, you can encrypt the PDF. You can also use custom encryption handler and thus make your file unreadable with stock Acrobat or Reader (one will need to install your decryption plugin to Acrobat or Reader to make them understand your encryption). The problem is acrobat's DRM SDK (the one that allow you create encryption plugins) once had enormous cost (smth. like $25K to start). I don't know if this is still the case, though.
Another not-so-bad option is render everything to graphics - this makes text copying harder (though one can print everything and OCR it back).
The short answer is no. When you give someone the ciphertext, key, and cipher they will always be able to reproduce the plaintext. DRM fails universally for just this reason.
The long answer is that you can sometimes try little gimmicky tricks to prevent copying in some circumstances which may "work" if your audience doesn't try breaking it, but not in the general case. You can't really call something secure which is "safe as long as nobody tries to break it".
The PDF format itself has an "owner password" which allows the author to disallow readers from printing the document, modifying it, etc... Of course there's not actually any mechanism for preventing anyone from doing so. If you are trying to prevent the guys in the marketing department from printing it off or something, then maybe. But if you're releasing it out into the Internet, just assume that it can and will be copied however users see fit.
I have an OLD server running DG/UX that will in the near future be unsupported. I have some character based oracle forms that need to be migrated off of this machine. Does anyone know what sort of migration strategy Oralce has for upgrading these Character Based reports. It doesnt have to be the newest version, it doesnt even have to be to a GUI version, but I do need to migrate to a supported OS such as linux.
The easy answer is to tell you to check out Migration from 6i to 10g.
Having done it before, what I think the much more useful answer is to tell you to rewrite those forms and reports from scratch. Probably in another tool - especially if you want to have a web interface, etc. rather than being hobbled by an ancient Java runtime.
There are products out there that will let you translate the old forms code into PL/SQL. Kumaran is an example of one, but I found it buggy and had to do a lot of hand editing of the code to get it work the same as the original.
As far as I'm concerned, the CUI is dead so you might as well go all the way to a GUI. The last time I was looking at it, there was almost no documentation for CUI forms and frequently things that worked in the GUI wouldn't work in the CUI at all.
There are some problems you may run into in converting CUI based forms applications to GUI.
Sometimes there is validation and special processing done when the user moves to the next or previous field/block/etc. When you switch over to a proper GUI, your user can skip those events by just clicking on another field. So you are left with two choices - #1 audit all of the forms or #2 disable navigation in the form with the mouse
Option #1 is less work than redeveloping but look at how much work we've already put into it.
Option #2 your users will HATE you and come after you with pitch forks and torches. They will perceive that they've got nothing of value for all the work you put into it. Then you will end up doing Option #1 anyway.
Sometimes a UI that works fine in (or is required by the limitations of) a CUI is just plain wrong and breaks the UI metaphor that users are used to working with in the rest of the GUI (e.g., a pop-up window with list that you have to select an entry in rather than pull down where you can just pick the right value directly)
When converted to a GUI the CUI may end up with different fonts, text sizes and other formatting defaults than a freshly written form (it did for me). So now either the whole set of forms has to be updated to follow Oracle's new default theme for forms/reports or every new form/report has to reverted back to the old clunky style you had before - or it will stick out like a sore thumb (and your users will want them all to be like the pretty one now).
Not the answer you wanted; huh. But you can use this as an excuse to get out of the Forms/Reports upgrade tread mill and maybe even clean up some of the hacks that have had to happen over the years.