Alex Queiroz wrote:
However that's a bit clumsy. What kind of error are you seeing when you say 'it crashes'?
I must fetch all rows of the result, otherwise the database will be in an inconsistent state and all subsequent queries crash the application. Fetching all rows automatically finishes the previous statement, so I must evaluate the spine of the list.
Odd. That sounds like a suprising library design to me. What's the point in returning a lazy list if you then leave everything in an inconsistent state until the list is fully evaluated? In that circumstance I'd rather have a strict list. I was intrigued and went and read the library documentation. It says "...Please note that the careless use of this function can lead to some unpleasant behavior...But then, similar caveats apply with hGetContents..." I don't know if I agree; these caveats seem definably worse than those which apply with hGetContents, if they can in fact cause crashes. The worse problem with hGetContents is that if someone else writes to that file while you're reading, you can see a mixture of old and new data. This seems to be far worse: you can't even make two queries unless you guarantee you finish the first completely first. Personally I'd inclined to suggest use of the strict FetchRow which the library provides than struggle with explicit uses of seq to fight an over-lazy IO action. Jules