In excel is it bad to have about 1000 embedded if statements? I have about 1000 options that I want to pre-populate in other excel fields, what is the best way to do this other then inefficient if statements?
only 7 if statements can be embedded in one another in older versions of excel. 2007 allows more, but it gets unwieldly after that.
A better option may be to build a table with all your different options, then use the VLOOKUP formula to pull the result.
Whether you use Excel or another tool, the important thing is to design it well with a good flow of information that is easy to follow. Excel works great for large spreadsheet projects as long as they are well designed. The additional benefit to a well designed Excel file is that more people can open them.
Yes, it is bad.
Excel is not a good tool to use for complex programs. It would be better to buy Resolver One which gives you a spreadsheet interface, but actually generates Python code under the hood. That way you can audit and test the code for correctness, and you are less tempted to create awfully complex, and often buggy, spreadsheets.
There is a group called the European Spreadsheet Risks Interest Group that holds an annual conference about the risks inherent in complex buggy spreadsheets. A lot of the papers presented at this conference are available on their website.
Related
I have an excel sheet I've received from someone with information about their personal library recently, and they've asked me to add the library of congress number to every book on the sheet. There's thousands of books on this thing, and it would take forever to search the library of congress website and copy-paste everything on here. Is there a built-in function or a way to have a column search the website for each book and copy the appropriate number?
Err... No.
This specific functionality (searching the library of congress) is so specific, that it makes no sense for Microsoft to add it to Excel. There would be probably 3 people in total that would EVER use it.
A more generic functionality (take an arbitrary webpage and look for some arbitrary information in it) would on the other hand be too vague. Either it would be useless or it would need to have a bazillion parameters to get it to do what you need to. And you'd need to spend months trying to configure it just right.
Actually, Excel does kinda offer this generic functionality - it's called the VBA. You can write custom programs there that can do pretty much anything under the sun. The downside - it's programming. If you know what you're doing, you can probably get it done in a couple of days, maybe a week. If you don't know... good luck. You'll need it!
I have a friend that is working on a company without any real IT people, and they've gone the classical corporate route of stringing things together with Excel macros whenever they need something. I was trying to figure out what alternatives are available for someone that isn't a programmer by trade.
What is an easy alternative to Excel when you want to distribute data offline together with forms for manipulating it, that doesn't have a steep learning curve? I was going to suggest he learn Python and SQL-lite, but I'm hoping StackOverflow can come up with a wiser answer.
Honestly, for non developers (and if you do not have a dev staff in-house) there really isn't anything wrong with Excel.
That being said, Lightswitch is a new and fairly interesting option for basic forms over data work (although it's still a bit green).
IMO once you go down the route of languages like Python, etc. you're really looking at someone who is going to have to be a programmer (and they may be shooting themselves in the foot on a regular basis).
In that type of environment users end up with Excel or Access to manipulate data. Excel is convenient where cells in row are calculated the same way, but with exceptional cases. Access is better for calculating over multiple rows easily, data management forms (yes Excel can do it too, but Access is easier) and formatted reports.
The best situation I've arrived at in this type of environment is standing up read only "data warehouse" that Excel and Access users can link or download data from to manipulate on their own. For this situation SQL Server is probably the right choice and I use quotes around "data warehouse" because I don't mean it in the technical sense, but rather just a convenient repository. That way you have one definitive system of record. Then any report generated in either tool repeatedly becomes a candidate for incorporation into that warehouse.
We have Product Backlog in an Excel Spreadsheet that we also commit to SVN, so everyone can open use it and update to latest version.
The problem we have is:
How do you enable Excel spreadsheet to be simultaneously used by many people and not override each other's data. Some kind of merging data? Is it at all possible?
We would like to keep our data in Excel spreadsheet since it provides all the functionality we need. We tried Google spreadsheets that are much better in terms of collaboration, but they don't support cell drop-down values...
EDIT
I've found out that I can also save my Excel file in XML format (XML Spreadsheet 2003). This format preserves all formating, formulas, conditional styles etc. Only graphs fall out, but I can live with that. I suppose that SVN Merge tools more or less support XML file merging when multiple people work on it.
So I thought of this feature, but I don't know how much does Excel change XML document between saves. Maybe it reorders a lot of stuff hence making it impossible for merge tools to work with expected results. Anyone has any experience with this?. It would basically make it possible for multiple people working on the same file.
EDIT2
I've tried managing Excel spreadsheets in a plain XML file (XML Spreadsheet 2003 file format) that makes it possible for SVN to merge it since it's a text file. I've learned to not use conditinal formatting, because it doesn't always work, so you'll have problems reopening the file. Also graphs won't be preserved.
Testing outcome: I've tried simultaneous work on the same XML, but Excel works with these files in no particular order (looks like it converts it to Excel and back to XML when saving it), so even if you make a small change to data, your XML will look completely different. So this format is a no go for collaborative purposes with merge capabilities.
FYI note: I've moved my operations from Excel to a more collaborative and similarly capable solution: Google Spreadsheets. Simultaneous collaboration is just working and working great (hopefully Microsoft will someday make collaboration this way on all its Office range) and it supports versioning as well as all the capabilities I'm using in Excel. COnditional formatting and with some additional script code I can use conditional formatting on whole rows based on single cells as well, so I can easily background colour whole rows of when set particular story status to "Completed".
Excel data can be merged but it's somewhat hard and error prone.
What I've found useful is to put the svn:needs-lock property on that kind of hard-to-merge files. The file will be read-only by default to communicate "do not edit this" and acquiring a svn lock makes it a read-write file, while preventing other users from acquiring a lock at the same time. It's a communication mechanism, not a 100% foolproof merge conflict prevention mechanism.
More information in svnbook.
Excel has a built-in share/merge capability (search the help for "share workbook") but it's meant for live copies on shared drives. Still, for this particular problem that might be a better solution than SVN.
Excel doesn't support the scenario you described, you need to use a multi-user database, or an proper work-tracking system. There are some hosted ones you can try (Jira, FogBugz) but you're not going to get multi-user with Excel (unless you use the shared spreadsheet option, but as David Moles said, that's meant for shared xls files on a file server).
SVN allows eveyone to get the latest version and work on the latest version without a "checking out" / "make read-only". This enables multi-users working the same file, and would assume that the Merge features only work on Text docuements (code files)
(This is based on my possibly limited experience with SVN)
Its probabaly time to upgrade from an Excel system to a more systematic multi-user database system.
I wonder if you're using the right tools for the job. Perhaps you should be investigating some Scrum tools to help you manage your projects.
Excel works well in a simple, non-shared scenario but I would investigate something more powerful to allow your team to manage the scrum process simultaneously.
After hearing about this project on several podcasts, I've started using Zen. It's based on a kanban board.
I'm pretty sure TortoiseSVN has some hooks (merge-docx.js, et al) which enable you to merge complex file types like office documents.
Or perhaps something like this (at a push)
have you looked at the Greenhopper planning backlog tool.
You could try XLLoop. This lets you write excel functions (UDFs) on an external server. It includes server implementations in many different languages.
So instead of keeping the data on your spreadsheet, you could have it stored in an external database then create a template excel sheet that calls the functions on your server. This will allow the data to be automatically updated and also allow multiple people to use the sheet at the same time.
BTW, I work on the project so let me know if you have any questions.
I'd like to give my boyfriend a taste of programming. If it was up to me, I'd teach Scheme, Haskell or F# but since he'd rather learn something that can be useful in his job as a fiscal consultant, i.e. programming Excel.
What are the options for programming Excel? Which one would you recommend for someone who's just learning to program and yet wants to get things done? Are there any books / resources you recommend for him (advanced Excel user, beginner programmer) or me (intermediate Excel user, advanced programmer)?
Thanks. I've started a blog about programming Excel to document our findings.
As a long time (business) Excel user and programmer, I recommend starting with a good VBA book that focuses on the key features of the Basic language, and how to communicate with the Excel objects (workbooks, sheets, etc). I wouldn't worry about userforms, initially - I haven't used those for years - and I wouldn't worry too much about databases at first either.
I suggest focusing on two areas in particular, starting with the Basic language itself, writing output to the Immediate window with Debug.Print and ignoring the fact that Excel is attached. You can get very good practice in this by solving some of the Euler problems, which favour pure code solutions with no user interface.
After that, I would learn how to talk to the Excel objects, and read as many Excel forums and web pages as possible to pick up tips. For example, it is much faster to read and write many cells at once, than one at a time.
And yes, VBA is not as full featured as most 'professional' languages, but it has one crucial advantage over most of them - it is much easier to write and for the average user to check, modify and maintain - and checkability and flexibility are crucial in the business world. Together with Excel, it is an amazing business tool.
There's basically two big options: he can write VBA code (macro's) or .NET code.
VBA code, being built on a simple language, has a low threshold. But if he's interested in programming in general, he might be much better off learning .NET (preferably C#). It's much more powerful than VBA and will teach him a lot more about proper software construction and essential concepts behind it.
I think it would be best to have him program some silly little Winforms applications first to get the basics down, and then look in to Excel interop. You can find a bunch of examples of C# / Excel intererop code by googling for "C# Excel". Here is one example:
http://dotnetperls.com/Content/Excel-Interop-Performance.aspx
VBA is VB6, in terms of runtime at least. It has enough OO capability to allow understanding of encapsulation and (sorta, without wanting to start a religious war) polymorphism/inheritance, if you'll accept that interfaces provide some aspects of those. If he spends a lot of time in Excel, then I'd expect there to be some repetitive things he does at present that could benefit from recording a macro, then learning to clean it up. That can lead to writing his own worksheet functions, loops, all kinds of useful stuff. If he's genuinely advanced (pop quiz: does he know about putting formulae in names? Is he comfortable with array formulae?) then there will be things that he's annoyed with where VBA can help.
I think I'd ignore .Net for now, it's too big and it will take too long for him to be able to produce his own solutions.
Alternatively, just teach him Ruby. It's what I'll be starting my kids on when they move on from Scratch.
VBA is a great starting point for someone new to development and wants to get a handle on the basics. It is possible to program Excel through many different languages by leveraging the Excel or Word COM libraries. This can be done easily in languages such as C# but is not suitable for someone starting off with programming.
Just word of caution. Although VBA is a fully featured programming language and is capable of supporting complex applications it can encourage poor programming practises. I have seen this occur in large organisations that use Excel extensively for actuarial calculations. Essentially the code was written by actuaries with finacial calculations in mind - not software engineering.
In the long run enterprise programming languages such as Java or C# are better.
Macros are one way to program Excel.
Check out this YouTube video:
http://in.youtube.com/watch?v=k_fWcffRAG4
It demonstrates how to Record and use Macro.
You can do a great deal with VBA, probably more than someone in finance would ever wish to do. VBA is intended, I believe, for just such people, but it generally gets bad press. I think that if you, a programmer, taught your boyfriend VBA, he would develop some understanding of programming and also have to hand an extremely useful tool for work, far in advance of anything that can be achieved by recording macros. In addition, it is a very short step from VBA to VBScript.
I have an old Excel 4 macro that I use to run monthly invoices. It is about 3000 lines and has many Excel 5 Dialog Box sheets (for dialog boxes). I would like to know what the easiest way would be to change it into VBA and if it is worth it. Also, if once I have converted it to VBA, how to create a standalone application out of it?
I have attempted this before and in the end you do need to rewrite it as Biri has said.
I did quite a bit of this work when our company was upgrading from Windows NT to Windows XP. I often found that it is easier not to look at the old code at all and start again from scratch. You can spend so much time trying to work out what the Excel 4 did especially around the "strange" dialog box notation. In the end if you know what the inputs are and the outputs then it often more time effective and cleaner to rewrite.
Whether to use VBA or not is in some ways another question but VBA is rather powerful and extensible so although I would rather use other tools like .NET in many circumstances it works well and is easy to deploy.
In terms of is it worth it? If you could say that you were never ever going to need to change your Excel 4 macro again then maybe not. But in Business there is always something that changes eg tax rates, especially end of year things. Given how hard it is to find somone to support Excel 4 and even find documentation on it I would say it is risky not to move to VBA but that is something to balance up.
(Disclaimer: I develop the Excel-DNA library)
Instead of moving the macro to VBA, which uses a COM automation object model that differs from the Excel macro language, rather move it to VB.NET (or C#) running with the Excel-DNA library.
Excel-DNA allows you to use the C API, which mirrors the macro language very closely. For every macro command, like your dialogs, there is a C API function that takes the same parameters. For example, the equivalent of DIALOG.BOX would be xlfDialogBox - there is some discussion and example in this thread: http://groups.google.com/group/exceldna/browse_thread/thread/53a8253269fdf0a5.
One big advantage of this move is that you can then gradually change parts of your code to use the COM automation interface - Excel-DNA allows you to mix and match the COM interfaces and C API.
AFAIK there is no possibility to somehow convert it. You have to basically rewrite in in VBA.
If you have converted to VBA, you cannot run as a standalone application. As VBA states Visual Basic for Application, it is living inside an application (Word, Excel, Scala, whatever).
You have to learn a standard language (not a macro-language) to create standalone applications. But you have to learn much more than the language itself. You have to learn different techniques, for example database handling instead of Excel sheet handling, printing instead of Excel printing, and so on. So basically you will lose a lot of function which is evident if you use Excel.
Here is a good artikel about this topic: http://msdn.microsoft.com/en-us/library/aa192490.aspx
You can download VB2008-Express for free at: http://www.microsoft.com/express/default.aspx