Export ALL to a CSV?

[justw]

I've been an OrangeCd user for a long time and like it a lot but am abandoning Windows as an operationg system. One of the apps I will miss is Orange CD. Is there a way to export all of the fields in the database to a csv so I can import into another database? So far the only option I have is to export via HTML with each CD on it 's own page. This is fine and I can add future cds via an HTML editor but would prefer a csv export then regardless of what I do in the future I can use the csv file as a datasource.

Also, is there a way to transfer my OCD license to someone else? Some of my friends would enjoy using it.

[frederf]

I don't know about CSV, but I think you can export everything to XML.. after that if your new program can't import XML there are other programs that can convert the XML into other formats.. MS Excel can read XML and then you can export to CSV.

But I don't think that in any case the data will be nice and clean.. ;O)

fred

[Paternoster]

[...] Is there a way to export all of the fields in the database to a csv [...]

Go to "Database" Menu and chose "Import and Export ...". What you are looking for is the "Export to plain text" action.

-pn

[justw]

Go to "Database" Menu and chose "Import and Export ...". What you are looking for is the "Export to plain text" action.

-pn

I don't think I can get track titles or times with that.

"I don't know about CSV, but I think you can export everything to XML.. after that if your new program can't import XML there are other programs that can convert the XML into other formats.. MS Excel can read XML and then you can export to CSV."

I'll look into the XML stuff. I'm not that familiar with XML so didn't look at that option.

[Paternoster]

OMG ... you are obviously right. Even that export function is crippled ... :(

My fault! I never checked the csv's for such trivial things like titles and times, but only for some of my self defined fields and stuff. I took it for granted that those basic things would always be included ...

That's a bad joke, isn't it?

-pn

[justw]

yeah, I expect a database program to be able to dump all of it's records and fields into a generic format. I stll need to explore XML but I'm not hopeful.

[andrei_c]

XML is the full export in OrangeCD. It contains everything there is in the database except artwork images.

Andrei

[Paternoster]

Sorry Andrei, but after doing a quick check on this, I can say that the XML export does not contain "everything except the artwork images".

For example there don't seem to be any customised checkbox and field names within the resulting XML file. There surely is something like boolN="1" for a set checkboxN in the common tag, but I can't find a reference to the custom title which is assigned to it, so nobody will ever know what it stands for. And fields and checkboxes that are not yet used in OCD are not even mentioned either.

Besides that "everything except" is already a knock out criterion itself in my opinion. After all, we're talking about creating _full_ database exports! It would be great, if you could at least modify the csv export to really contain everything (including links/paths to the artwork) in the near future!

-pn

[justw]

Yup, I pretty much found the same thing. That's okay with me though as I am leaving the fold.
My second question was about transferring ownership. You can PM me if you like. Or email.

[andrei_c]

For example there don't seem to be any customised checkbox and field names within the resulting XML file. There surely is something like boolN="1" for a set checkboxN in the common tag, but I can't find a reference to the custom title which is assigned to it, so nobody will ever know what it stands for. And fields and checkboxes that are not yet used in OCD are not even mentioned either.
If the value has default value, it does not show up in XML. This is done to reduce file size. It is just common sense, otherwise output XML would be 10x bigger for most users.


Besides that "everything except" is already a knock out criterion itself in my opinion. After all, we're talking about creating _full_ database exports! It would be great, if you could at least modify the csv export to really contain everything (including links/paths to the artwork) in the near future!
Artwork image filenames have format XXXXXXXX.jpg where XXXXXXXX is value of ID attribute in Volume element. It is a link to image... just without directory and extension.

Custom field titles are indeed not exported to XML as well as any user settings, but I never thought it could be a problem. There's less than 30 fields total.

Sorry, I still think XML is as full export as it can be (but I'll give you half point for custom field titles :) )

[Paternoster]

If the value has default value, it does not show up in XML. This is done to reduce file size. It is just common sense, otherwise output XML would be 10x bigger for most users.

Sure, exports would be somewhat bigger, especially within xml which tends to waste a lot of space for repeating redundant stuff by design, but that's why I'd always vote for csv for exports anyways! :p However, it surely wouldn't be that much bigger.

And speaking of common sense ...

Why would anybody do an export if not for being able to import it somewhere else than OCD? One would use the backup/restore function inside of OCD, but everywhere else you can't do it without a reasonable and complete export. And that's where you simply need any and all of the information that is used in the OCD database or you'd just not be able to rebuild it without losing information. And that's surely not what an export is meant for ...


Artwork image filenames have format XXXXXXXX.jpg where XXXXXXXX is value of ID attribute in Volume element. It is a link to image... just without directory and extension.

I know, but what's the motivation for omitting such a tiny bit of information? We're talking about a few bytes for each disc only (15 bytes each in csv plus bytes 15 for the header and ~ <100 bytes each in XML). Who cares about that little bit? Especially compared with not having this information at hand immediately when using the export file?

Just an exaple: My current db backup is about 100 MB, the xml export around 42 MB and the csv export less than 8 MB. None of these values are sizes I'd ever waste a single second of thought on, but why should I ever deal with any of these files as long as they are incomplete? A complete csv shouldn't be much bigger than 10 to 15 MB here and that's still about 1/3 of the utterly useless XML file so size is most likely not the issue here.


Custom field titles are indeed not exported to XML as well as any user settings, but I never thought it could be a problem. There's less than 30 fields total.

Sorry, I still think XML is as full export as it can be (but I'll give you half point for custom field titles :) )

Andrei, I understand that you obviously prefer XML over any other export format, as well as I understand it even more, that you don't want to waste any time and energy on modifying it unless there were essential reasons for it :p, but I surely don't share this liking! In my opinion XML is a complete waste of time and space and I can certainly live with it the way it is, because I'll probably never use it ...

The only thing I need (and probably many other OCD users too) is the possibility to easily and reliably create a complete csv export with any and all fields and values available in OCD. Unfortunately OCD limits the list of "Available Fields" within the "Export to plain text" dialogue, but it shouldn't be too difficult to remove this limitation and make it export all of it's fields here.

As long as you leave the option to deselect single or multiple fields here, everybody can always create exactly that much of an export as (s)he likes or needs and I guess that would be the best for everyone, wouldn't it?

-pn

[frederf]

I (as a programmer) greatly prefer XML. Many programming languages can consume XML natively, and allow you to easily get to the data that you need.

Fred

[Paternoster]

I (as a programmer) greatly prefer XML. Many programming languages can consume XML natively, and allow you to easily get to the data that you need.

Fred

That's perfectly fine for me if you do, but please don't expect everybody else to share that liking.

I (as a programmer) greatly prefer CSV, because it is much less redundant, much more efficient, and I can easily use it with any database (they either import it natively or with some simple helper), (web-)programming language (like perl) and a myriad of tools (like awk) that I often work with and that are more than appropriate to use with the data exported from OCD. And if I'd ever be tempted to import this data into any kind of office application, I can also do that with CSV, even with all that ms crap (god forbid!) ... :p

So I really don't understand, why I should waste my resources or time with anything less reasonable. But the world is flat, isn't it? ;)

-pn

[frederf]

That's perfectly fine for me if you do, but please don't expect everybody else to share that liking.


I certainly wasn't trying to suggest any superiority ;O)

They both have their merits.

I haven't looked but I would bet that there are utilities that would convert between CSV and XML. So given one you could convert to the other.

And I do agree that if you are going to provide an export of the data that it should be complete. You just can't predict what your users are going to want to do with that data.

Fred