On 9/16/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 9/15/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > In general, initial SQL data is a real pain to manage and if anybody has
> > a good idea on a better approach. I would like to avoid building a full
> > SQL parser in Python for o
On Fri, 2006-09-15 at 20:32 -0700, [EMAIL PROTECTED] wrote:
> Hi Malcolm & James,
>
> I do think the SQL initial data is going to be a problem in a number of
> ways:
>
> 1) database API's (as per this thread)
>
> 2) line breaks ( c.f. http://code.djangoproject.com/ticket/2729 )
>
> 3) database
Hi Malcolm & James,
I do think the SQL initial data is going to be a problem in a number of
ways:
1) database API's (as per this thread)
2) line breaks ( c.f. http://code.djangoproject.com/ticket/2729 )
3) database specific issues. For example - the sql file attached to the
ticket above (2729)
On Fri, 2006-09-15 at 21:22 -0500, James Bennett wrote:
> On 9/15/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > In general, initial SQL data is a real pain to manage and if anybody has
> > a good idea on a better approach. I would like to avoid building a full
> > SQL parser in Python for
On 9/15/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> In general, initial SQL data is a real pain to manage and if anybody has
> a good idea on a better approach. I would like to avoid building a full
> SQL parser in Python for obvious reasons.
Other people already *have* built SQL parsers
Hi Simon,
On Thu, 2006-08-31 at 00:54 -0700, [EMAIL PROTECTED] wrote:
> Hello Djangonauts,
>
> I've found an issue with initial data and SQLite - if any of the fields
> in the initial data has a "%" in it, the import fails. Pysqlite is
> apparently processing the query for string formatting args
