Am 05.04.2012 09:20, schrieb h.m.br...@xs4all.nl via RT: > Queue: DBD-CSV > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=76276 > > > On Wed, 4 Apr 2012 12:55:14 -0400, "Jens Rehsack via RT" > <bug-dbd-...@rt.cpan.org> wrote: > >> Merjin, > > By now, you'd know how not to switch the i and j, right?
*whistl* >> can you throw it over into SQL::Statement Queue? It's reasonable to >> handle it there. > > Sure. I thought it would be DBD::File, as the *file* is empty and thus > would do the same for all DBD::File related DBD's. I do not expect that any DBD::* code is involved in the bug - but probably it's an non-instantiated table. I try to create a small test case and if I can't figure out what#s going wrong, I ask the originator for more details ... > It might even > warrant a new attribute to allow this as normally in DBI a table always > has columns (but not always rows). If a file is empty, it doesn't even > have columns. Not all databases allow the creation of "empty" tables, as > in a table with no rows at all. Postgres does, but Unify and Oracle do > not. Well, if the table is created with columns specified, you're right. If the originator wants the columns guessed from an empty b.csv, you're wrong from my point of view. DBD::CSV is special (as some DBD::AnyData, too), because it "guesses" columns from data file. Probably an $dbh attribute "f_default_columns" can help out, but before we think further let me dig out the root cause ;) I'm a bit busy with communion of my younger dauther until end of April and then something to clarify with our house renter - I expect I can invest larger blocks of time in mid of May. I hope I can create a test case before ... > I have included the devel list to see how others think So did I - good suggestion. Best, Jens
