[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql
Subject:    Re: Weird M$ Pasting issue
From:       SGreen () unimin ! com
Date:       2006-03-29 21:12:26
Message-ID: OF72E78854.94A2619B-ON85257140.007379FE-85257140.00744B81 () unimin ! com
[Download RAW message or body]

--=_alternative 00744B7785257140_=
Content-Type: text/plain; charset="US-ASCII"

Vinny <xaymaca@gmail.com> wrote on 03/29/2006 03:52:33 PM:

> Hello All,
> I am running across a very weird problem.
> Sometimes when a person paste text from a Worddoc
> into the text field of our webapp, the insert fails. Unfortunately
> I am not seeing the failure in the logs. There are a lot of factors
> to consider. The path to mysql looks like this.
> 
> Firefox (OSX)   ->  JDBC ->  Mysql (on linux)
> the field we are pasting to is a TEXT field.
> 
> when I paste into an emacs editor. I see what looks like formatting 
code.
> Not sure why that is getting pasted into the text field and also not 
sure
> why the jdbc prepared statements are not making the text safe for 
insert.
> Anyone have a clue as to what might be happening?
> 
> --
> Ghetto Java: http://www.ghettojava.com
> 
> -- 

Didn't you leave out an important component or two in your transfer chain? 
Doesn't the data actually take a route more like:  Firefox (OSX) -> Web 
Server -> Server-side scripting language or CGI ->  JDBC ->  Mysql (on 
linux)?  The fact that there is some processing stage at the server means 
that we can isolate the problem to either before or after it arrives at 
your server.

What is the actual data that Firefox is sending to your server-side code? 
Verify that your server is receiving what you think you are pasting. If 
what you paste is not what you receive, then Firefox may be to blame.

Check how your server-side code mangles the incoming information. You may 
be unintentionally changing the incoming data somehow.

How are you setting up your JDBC connection to MySQL? I haven't used JDBC 
so I can't say if what you are doing is correct but someone on the list 
will surely pitch in and help. 

Are you trying to work with characters that fall outside the range of 
US-ASCII?  When working with Unicode, UTF-8, and a whole slew of other 
charactersets, you have to ensure that all of the components of your data 
processing chain are using the same characterset and collation.

These are just the first places I would look. Others will probably suggest 
more.

Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
--=_alternative 00744B7785257140_=--
[prev in list] [next in list] [prev in thread] [next in thread]