My final fix was to open the document in Office 2003. thejn I saved it as an Excel 4.0 WORKBOOK. Workbook being bold because the first option is worksheet, which didn't work.

Once it was in Excel 4 format I was able to open that with Office 2007, which promptly told me that the document was unreadable, but that it would try to recover the document, at which point it would ask me where to save the new one.

That resulted in a readable document that could be edited and saved without error. The only real problem with the resulting document was external links were severed, and charts were no longer correctly sized.

Beats entering them all again.

My $0.02 on 07 is that is is a nice new interface that takes a lot of getting used to after using the old interface for roughly 15 years. Considering that there's practically no new functionality for the average user, it is pretty unacceptable that this wasn't implemented as a skin that could be turned on or off at will.

I just installed excel 2007 and when I open an old file (created on excel 2000 I guess), Excel show the message “Line Print Settings” as an incompatible resource if I try to save in the new 2007 format (.XLSX). But it saves the file, ok. The true problem happens when I try to save this file back as a excel97-2003 file (.XLS), Excel will simply close and refuse to save the file. If I try to run “prepare – check for compatibility problems” excel will close suddenly too.

I am simply unable to recover a file converted to the new format. I guess this could be a potential problem to much people.

Not sure what the car example has to do with open source or with monopolies. Microsoft is a closed source based monopolist. I also consider open source to be a part of the context for discussion.

Simply, the car companies are not monopolies. If they were though (forgetting for a minute that they would be regulated much more), how would you describe open source for cars unless there was a manufacturer that opened up all the designs and chips used in the car (boiling them down to cots components). So the car industry neither has open source nor monopolies. Your example was horrible.

Anyway, the “solution” is simple: provide the source for macros (and compile that after they are loaded) or at least some sort of byte codes. OR, define the binary specs and then other products can build a compatibility layer of some sort.

Of course, this would STILL BE A GAME. Microsoft has every business incentive to extend the standard in a closed fashion. Practicality dictates they would do that anyway as long as they control the apps and the OS and insist on integration as a way to define the value of their products. This would happen no matter what protocol/spec is defined.

The way out is not to rely on a closed source monopolist as your vendor.

>> Most databases, including FOSS ones, use proprietary internal formats for exactly the same reason. They also provide document interchange (export) formats. Excel is doing nothing differently here.

FOSS databases are open source. This means the “internal formats” are defined openly (if a bit implicitly). Also, since when are macros something that should not be interchanged across products? To say they are not means that part of the document format is closed. No part of a format is closed when we use FOSS. No part need be closed when we use closed apps but inevitably this will happen, all the more so when the vendor is a monopolist since their position is strengthened when they actually violate the standard.

In short, FOSS is the way to make sure that everything is open and can be reproduced in other apps. Also, in theory, internal formats can be specified for closed source apps, too. That this would interfere with the obscurity cloud behind which closed source vendors want to hide in the first place is another story.

This the file created under XL 2003
329,,,,,,,,,,,,,,A
956,,,,,,,,,,,,,,A
994,,,,,,,,,,,,,,A
1061,,,,,,,,,,,,,,E
1697,,,,,,,,,,,,,,A
2205,,,,,,,,,,,,,,A
2688,,,,,,,,,,,,,,A
3144,,,,,,,,,,,,,,A
3291,,,,,,,,,,,,,,A
4658,,,,,,,,,,,,,,A
4984,,,,,,,,,,,,,,A

And the one under XL 2007 will look like this…
329;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
956;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
994;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
1061;;;;;;;;;;;;;;E;;;;;;;;;;;;;;;;;;;;
1697;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
2205;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
2688;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
3144;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
3291;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
4658;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;
4984;;;;;;;;;;;;;;A;;;;;;;;;;;;;;;;;;;;

I need the format of the old version when I need to upload to an AS/400 file, this is the way the programm as been created but MS change it… So nothing works anymore!

This link does not exist

Page not Found
The page you requested cannot be found.

The following is the most likely location:
Office 2007 .bin file format by Stephane Rodriguez.
Undocumented binary file formats coming in the Office 2007 timeframe

URL: http://www.codeproject.com/cs/library/office2007bin.asp

[b]Is it right or not?[/b]

Any help please?

The bigger question is this: What has the industry failed to do, that end-users think 200MB spreadsheets are preferable to databases? Have we failed to make databases easy enough to use? Is this a matter of users not wanting to explicitly model data up front?

If you want people to get work done as easily as possible, to be as productive as possible, you might as well give them the data in Excel.

The problem is to get, say, 145meg+ of data, into an Excel spreadsheet as fast as possible. XML is just too slow, way too verbose.

Here is the real life example of putting General Ledger data into Excel:

145 meg raw data – Tab Delimited

14 meg xlsb Compressed

207 meg xlsb Uncompressed

1485 meg xlm 2003 spreadsheet

Almost 1.5 gig for for xlm is Unusable. 207 meg is not.

What I need is the fastest way to get 145 meg into an Excel spreadsheet. Fastest being defined as Open (or import into) in Excel, save in Excel format, close.

What is the fastest way to get data into Excel ?

This user interface is close to be a worst case scenario for implementing such standard format policies because its makes impossible to obtain even a reasonable degree of user compliance.

“… [ODF as a Malaysian Standard] may send a confusing signal to the user community and lead to unnecessary cost”

is an example of the “doesnt make sense” concerns amongst others.

yk.

The minimal steps to reproduce the crash:

1) Launch Excel
2) Do Nothing
3) Exit Excel

The message is “Microsoft Office Excel has encountered a problem and needs to close. We are sorry for the inconvenience”.

I’m on XP SP2.

I’ve been sending in the automated error reports when this happens. I just did another so you can see what I’m talking about.

Anonymous, Your logic is circular and can be summarized as, “No one else can read Excel macros, thus there is no reason to document how to do so”. But I can imagine a good number of reasons why someone would want this capability. Considering the virus vector provided by scripts in Office documents, I could see a security company might want to sell a product that scanned incoming Office documents at the gateway and identified potentially malicious macros based on what API’s they call. You could define sandboxes and perhaps only let in documents with macros that limited themselves to a specific subset of API calls. One could also imagine a company offering a service where documents could be uploaded and scripts inserted or updated to accomplish a particular task.

There are plenty of innovative things that could be done in this area, but by having a proprietary binary format for the scripts, Microsoft locks everyone else out. This is unfortunate considering the code was entered by the user as plain text to start with.

As for the XLSB format, it’s simply an option for users who have huge complex spreadsheets and are willing to forego standards in the name of performance. The kinds of spreadsheets that XLSB is used for are not viable in either Open XML or ODF, and those users have decided that they’d rather optimize performance than use an open standard format. Again, the user gets to choose, and the default format of Open XML is always there for Office users.

I posted about XLSB on my blog a few months ago, including a link to Stephane’s original article, here:
http://blogs.msdn.com/dmahugh/archive/2006/08/22/712835.aspx

Rob, not sure what to say about Excel crashing dozens of times for you. I’m running it on Vista with no problems, and I’ve not heard that feedback before. What’s something specific that causes a crash? Do you get an error message?

Thanks,
Doug