On 19 November 2012 at 13:55, Nicola Chiapolini wrote:
| > | < $stmt = $stmt . qq{where date > '1970-01-01' };
| > | ---
| > | > $stmt = $stmt . qq{where date > '19700101' };
| >
| > This is very likely to break the other platforms. Please check (I
| > only use Postgresql but keep MySQL around) before making willy-nilly
| > changes.
| Unfortunately I do not have either pg- nor mySql at hand right now. I'll
| update this bugreport if I get around to do proper checking. For now
| this can just serve as a hint for others using SQlite.
You can at least check the code carefully for similar instances. Some of the
DB return date types, some don't. I think I standardize internally; this
seems to be missing at that command + db intersection. Maybe you can up with
something smarter and test it.
Not the setup and test scripts included. They should approximate a full
regression test of setting up a db and running reports. This breaks every
couple of years when a symbol changes.
You have to _at least_ demonstrate that your change does not harm the full
set on your db backend, and ideally quickly install another backend to test
there too. It is not that involved.
I am currently too busy with other more pressing projects of mine.
| Finally, thanks for a useful tool
As I said, I am user nb 1 and still quite happy. I have been meaning to
rewrite the front-end (analysis etc) in R which I'll get to one day...
Dirk
--
Dirk Eddelbuettel | [email protected] | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
