Hunter:

OK, I see what you are saying now... Sorry :( Apparently I wasn't paying attention to what you were saying...

Its odd to me the implementation isn't taking the character stream verbatim and hading through to JDBC - thus allowing JDBC to parse and do the right thing...so I guess Ant is parsing (perhaps partially) and then the JDBC layer gets to parse too?

The problem I had (again this was probably 3 years ago) was that for any given line, the line was assumed to contain an entire SQL statement...if the SQL statement spanned multiple lines, a continuation character had to be included in the file.

Scot

Hunter Peress wrote:
It is treating each line as ONE sql statement.  By using the -line
continuation- character, it should fix the problem - namely the \
character.


So? I gave 2 statements each on its own line. the problem is that ant thinks
the
string inside the first quote is an actual sql comment

the problem is that the ant sql task lacks some parsing:
from SQLExec.java

           // SQL defines "--" as a comment to EOL
           // and in Oracle it may contain a hint
           // so we cannot just remove it, instead we must end it
           if (!keepformat) {
               if (line.indexOf("--") >= 0) {
                   sql.append("\n");
               }
           }

i'm going to hack to make it only parse comments that arent within quotes.


Placing SQL statements in a file makes perfect sense...perhaps he is
trying to put database creation, or population information there?






I've
done it before and I saw no reason why one wouldn't want to do that...

And, this isn't an issue of ctrl-M characters...  I had this problem on
a Linux system using a ViM created file under Linux...  Ant is treating
the newline as a delimiter for the SQL statement.

Martin Gainty wrote:
> Hunter
>
> If Im not mistaken I think you just answered your own question
> so when you put all the SQL statements together on one line then ant can
parse the SQL
> if you break the SQL apart with some varying number of unknown
delimiters ant cannot understand your file contents
> if you absolutely must use a file(I dont know why you would)
> then tell ant what the the SQL statement delimiters are by specifying
your own delimiter within the sql task
>
> Also be wary that Unix does not like nasty ctl-m ^M characters that dos
editors toss in as newline endings
> vi -b on the sql file will at least show you the whitespace characters
so you can delete them
>
> Martin-
> This e-mail communication and any attachments may contain confidential
and privileged information for the use of the
> designated recipients named above. If you are not the intended
recipient, you are hereby notified that you have received
> this communication in error and that any review, disclosure,
dissemination, distribution or copying of it or its
> contents
> ----- Original Message -----
> From: "Hunter Peress" <[EMAIL PROTECTED]>
> To: "Ant Users List" <user@ant.apache.org>; "Martin Gainty" <
[EMAIL PROTECTED]>
> Sent: Tuesday, October 24, 2006 8:15 PM
> Subject: Example: error loading a mysqldump file
>
>
>
>> Ant file:
>>              <sql
>> classpath="../lib/mysql-connector-java-3.1.12-bin.jar
"
>>                   driver="com.mysql.jdbc.Driver"
>>                   url="jdbc:mysql://localhost:3306/"
>>                   userid=""
>>                   password=""
>>                   print="yes"
>>                   src="wtf.sql"
>>              >
>> use what;
>>              </sql>
>>
>> wtf.sql:
>> insert into properties (value) values("<!-- -->");
>> insert into properties (value) values("Hi");
>>
>> Ok so if in mysql console you source wtf.sql there are no problems, its
>> valid mysql. But ant bombs on it.
>> Ant can handle each line ,but put them together in a file and its bad.
>>
>>
>> On 10/24/06, Martin Gainty <[EMAIL PROTECTED]> wrote:
>>
>>> I know if I edit on windo and port to nix I will have <CR><LF>
appended at
>>> end of each line
>>> for small files
>>> vi -b
>>> will show you the extra CR and you can easily delete the CR (which
show up
>>> as ^M) chars
>>>
>>> for comprehensive treatment of entire files to unix run the dostounix
>>> utility
>>> check out this link from the friendly folk from Santa Cruz for details
>>> http://people.ucsc.edu/~chengyus/CE12L/DOSTOUNIX.htm
>>>
>>> Martin --
>>>
>>> This e-mail communication and any attachments may contain confidential
and
>>> privileged information for the use of the
>>> designated recipients named above. If you are not the intended
recipient,
>>> you are hereby notified that you have received
>>> this communication in error and that any review, disclosure,
>>> dissemination, distribution or copying of it or its
>>> contents
>>> ----- Original Message -----
>>> From: "Scot P. Floess" <[EMAIL PROTECTED]>
>>> To: "Ant Users List" <user@ant.apache.org>
>>> Sent: Tuesday, October 24, 2006 10:03 AM
>>> Subject: Re: error loading a mysqldump file
>>>
>>>
>>>
>>>> Can you elaborate more on the error?
>>>>
>>>> Some years ago I was using the sql task and had a file full of SQL
>>>> statements... When I tried to use the sql task I was getting errors
as
>>>> well.   The solution, if memory serves, is that I had to use a \
>>>> character at the end of each line until SQL termination.  So, if I
had
>>>> something like:
>>>>
>>>> create table foo
>>>> (
>>>> bar as int
>>>> );
>>>>
>>>> I had to do this kind of thing:
>>>>
>>>> create table foo \
>>>> ( \
>>>> bar as int \
>>>> );
>>>>
>>>> The problem (again if I can remember correctly) was that each line
>>>> (meaning new line/carriage return) was being interpreted as the
"whole"
>>>> sql statement and submitted.
>>>> Hunter Peress wrote:
>>>>
>>>>> using the sql task's src attribute i source a mysqldump file and it
>>>>> errors.
>>>>> mysql can source the file with no problems.
>>>>> but in ant I source it and theres a syntax error.
>>>>> There is no delimiter being set in the source.
>>>>> also if take individually two insert statement and source those it
>>>>>
>>> works.
>>>
>>>>> but i combine them and i get a syntax error.
>>>>>
>>>>> in the mysqldump the text fields are xml documents so they have
almost
>>>>> every
>>>>> imagineable character.
>>>>>
>>>>> im using standard utf8 encoding.   any ideas?
>>>>>
>>>>>
>>>> --
>>>> Scot P. Floess
>>>> 27 Lake Royale
>>>> Louisburg, NC  27549
>>>>
>>>> 252-478-8087 (Home)
>>>> 919-754-4592 (Work)
>>>>
>>>> Chief Architect JPlate  http://sourceforge.net/projects/jplate
>>>> Chief Architect JavaPIM http://sourceforge.net/projects/javapim
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
> >

--
Scot P. Floess
27 Lake Royale
Louisburg, NC  27549

252-478-8087 (Home)
919-754-4592 (Work)

Chief Architect JPlate  http://sourceforge.net/projects/jplate
Chief Architect JavaPIM http://sourceforge.net/projects/javapim


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Scot P. Floess
27 Lake Royale
Louisburg, NC  27549

252-478-8087 (Home)
919-754-4592 (Work)

Chief Architect JPlate  http://sourceforge.net/projects/jplate
Chief Architect JavaPIM http://sourceforge.net/projects/javapim


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to