From: bugbear on
Thomas Andersson wrote:
> I there an easy way to stora all elements of an array tab delimitered in a
> string (need to prepare collected data for import to a database).?

What import formats does your database support?

BugBear
From: Thomas Andersson on
bugbear wrote:

>> I there an easy way to stora all elements of an array tab
>> delimitered in a string (need to prepare collected data for import
>> to a database).?
>
> What import formats does your database support?

MS Access 2007, the import itself should be a problem. I also realized that
the array was not neccessary anyway, now I just concatenate the collected
data with tabs inserted to a string that I later write out with linefeed to
a txt file.


From: Sherm Pendley on
"Thomas Andersson" <thomas(a)tifozi.net> writes:

> Sherm Pendley wrote:
>
>>> I there an easy way to stora all elements of an array tab
>>> delimitered in a string (need to prepare collected data for import
>>> to a database).?
>>
>> join() is the opposite of split().
>>
>> my $record = join("\t", @fields);
>>
>> However! Note that this simple approach is fragile - if any of your
>> fields contain tab characters, it will break. You might want to use
>> map() to quote each field before joining them together:
>>
>> my $record = join("\t", map("\"$_\"", @fields))
>>
>> That can break too, if your fields can contain quotes *and* tabs.
>> There comes a point where it's easier to use DBI to connect to your
>> database and insert your data directly. :-)
>
> Thank you, my array will contain single words or numbers only so shouldn't
> be a problem. Might colons be a problem?

Not if you're using tabs as field separators. The general pattern is
that whatever characters you're assigning special meaning to - i.e.
tabs as field separators, quote marks as string delimiters, etc. -
need to be handled differently whenever they are used as "normal"
characters instead.

That's why there comes a point where it's easier to just use DBI and
insert the data directly - exporting to a text file can be easier in the
simplest case, but grows in complexity if you start having to handle
a bunch of special cases and escape sequences.

> (I know my script fails at
> collecting the fields containing a time ref and I assume it's due to the
> colon).

More likely, it's due to the database expecting a different format; for
example, if it's a datetime field in MySQL, you can't supply just the
time by itself. Or, if it's expecting YY/MM/DD, and you give it a date
that's formatted as 12/20/67, it will see that date as being invalid.

I'd need to see the field definition, and an example of a failed input
to tell for sure though - without that, all I can offer is vague gen-
eralizations.

sherm--

--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
From: Thomas Andersson on
Sherm Pendley wrote:

>> Thank you, my array will contain single words or numbers only so
>> shouldn't be a problem. Might colons be a problem?
>
> Not if you're using tabs as field separators. The general pattern is
> that whatever characters you're assigning special meaning to - i.e.
> tabs as field separators, quote marks as string delimiters, etc. -
> need to be handled differently whenever they are used as "normal"
> characters instead.

Turns out the colon wasn't the problem, the cell contained more data than I
knew so now I have to figure out a new solution.

> That's why there comes a point where it's easier to just use DBI and
> insert the data directly - exporting to a text file can be easier in
> the simplest case, but grows in complexity if you start having to
> handle a bunch of special cases and escape sequences.

That will be added as I learn, trying to start simple at first, remember a
week ago I had never seen a line of perl code in my life.

>> (I know my script fails at
>> collecting the fields containing a time ref and I assume it's due to
>> the colon).
>
> More likely, it's due to the database expecting a different format;
> for example, if it's a datetime field in MySQL, you can't supply just
> the time by itself. Or, if it's expecting YY/MM/DD, and you give it a
> date that's formatted as 12/20/67, it will see that date as being
> invalid.
>
> I'd need to see the field definition, and an example of a failed input
> to tell for sure though - without that, all I can offer is vague gen-
> eralizations.

I'm using HTML::TreeBuilder to create a html tree to navigate through by
feeding my data collector sub the coordinates of my data. It works fine for
all cells containing strings of text or numbers, what caused it to fail was
that the meanies had inserted the date in a link within the cell. Now I need
figure out how to only collect the interesting data and bypass the link.


From: bugbear on
Thomas Andersson wrote:
> bugbear wrote:
>
>>> I there an easy way to stora all elements of an array tab
>>> delimitered in a string (need to prepare collected data for import
>>> to a database).?
>> What import formats does your database support?
>
> MS Access 2007, the import itself should be a problem. I also realized that
> the array was not neccessary anyway, now I just concatenate the collected
> data with tabs inserted to a string that I later write out with linefeed to
> a txt file.

As long as there are no tabs in the data, yeah, that'll be fine.

BugBear