Let’s create something practical… for us Poser users — I’m sure others can see and apply this to something more in line with what they do.

Let’s also use no-cost software. I’m going to use Libre-Office. This alternative is available for Windows as well, so you don’t have to install GNULinux … not just yet, anyway.

Objective: I’ve done a fair bit of purchasing at the Daz 3D site (much to my embarrassment). I have those .exes all in a folder somewhere on my backup drive. Are they all installed? heck no. And I have no idea what is and isn’t installed, what part of it is clothing, what part scenery, figures, textures… whatever. No clue. So, my current objective is to figure out what I have installed and what I haven’t. However, given that this is my program, I can make it do whatever I want — within the scope of my abilities — which is why I’m specifying ‘current objective’.

Anyway, at some time in the past I saved the data from that accounts (purchases) page to a spreadsheet. Just to get an idea how much I was spending, or saving or something. Anyway, it amounts to a good-sized sheet. I’m going to use this as the data basis for this exercise.

So, the first bit is this:

— Open your browser, navigate to the Daz3D site, and log in. Bring up the My Account page and set the Itemised Order History to 50 items per page
— Open a new Libre-Office workbook (a workbook is made up of spreadsheets, default being 3 to start off with)
— On the Daz page, highlight and copy the grid contents with [Ctrl] [C]
— On the spreadsheet, made the ‘C’ column roughly 15cm wide
— Right-click on the A5 cell and select ‘Paste Special’ from the menu and then, just go with the defaults (Ok and Ok).
— Do this for each page in your Accounts page… then do the same for the My Orders pages

You should end up with something that looks like:

Good start. We’ve got 4 columns — we’re going to call them ‘fields’, since that’s what they’ll be known as in a database — of which 3 are potentially useful. The Reset entry in column ‘D’ serves no purpose, so let’s get rid of it.

The first field — A — is the transaction number, or Purchase Order number or whatever you want to call it. If you had bought more than one item that day in the same setting, they would all share the same number. So, the entries in that field are not necessarily going to be unique, which is an important point to remember (IOW, can’t use this field as a primary key index field).

The next field contains — ostensibly — date information. However, in its present form, it’s pretty much useless. This touches on this odd and illogical date format which everyone in the US still cling to but which is a nightmare to deal with programmatically: Month/Day/Year. Why? Anyway, it’s pretty clear looking at the date 3rd from the bottom that ‘9/29/10’ is in M/D/YY format.

Before we close, we’re going to look at some assumptions: assumptions we need to make before we start creating a solution for this:

• If one date is M/D/YY then they all are
• None of the YY numbers are in the 80s or 90s so we can assume that all years are going to be after year 2000
• The ‘/’ delimits month from day and day from year (is ‘delimits’ the word I want? separates, then )

And yes, this does require a solution. Sorry, but there’s more to the world than just the US. To my knowledge, the US is the *only* country that insists on this odd date format.