Need a workaround to export result from query builder (csv export facepalm)

[Richard Freggi]

So after reading QWERTY's book I was aware of the inbuilt query result window limitation: it does not escape the commas that are in the query result, meaning that the export to csv is useless as Excel and any other reader cannot differentiate between 'real' commas and value separator commas.  I always export to tab delimited for this reason.  On the other hand, the #Package# and #Branch# features are very useful, so I would like to keep using the inbuilt editor. I imagine that in the 15 versions of EA so far published, roughly a bajillion users must have run into the same roadblock, so has anyone found a workarond?  Thanks!

[qwerty]

Well, I usually run a script using repository.SQLQuery which gives me any (even binary) data in the format I need.

For your very question: it's EAUI. Probably everybody got used to it. Most fugitives come back after suffering in foreign regions even more :-/

q.

[Richard Freggi]

OK Mr. Sparx and Co., you thought you could ruin my Saturday afternoon with your inane csv export.  Well, the gloves come off now.

I just had a whole bucket of ice cream (Mmmmm, Movenpick, the best!!!) and glucose is flowing thru my gray matter again.

Here's the game plan: I'm going to add a '{%}'  or something similar after each attribute in my SELECT queries.  The moronic csv export will spit that out as ,{%}, together with the rest of the real data.  I will set ,{%}, as my customs field separator in Excel.  Done.

Actually my first plan was to use obscene invectives as custom separators: it would have made me feel much better, but this extract is for work...

Game.  Set.  Match.

[Richard Freggi]

Oh, And PLEASE: SQLite as one of the options for repository database type.  And an option for Tab delimited export for everything.  Thanks!

[Geert Bellekens]

Have you tried it in v15? I know they fixed the problem with the newlines, maybe they did the same with comma's?

Geert

[Richard Freggi]

I'm using build 13.10 professional, if they fix the issue of data model foreign keys not updating when primary keys are changed or deleted in the parent table I'll buy the version 15 license... but that's another can of worms... (due to Sparx philosophy to have the relationship and not the parent table own the key constraints, which is actually correct afaik, so no easy answers on that one)