Can N function cause problems with existing queries?
<p>We use <code>Oracle 10g</code> and <code>Oracle 11g</code>.</p>

<p>We also have a layer to automatically compose queries, from pseudo-SQL code written in .net (something like SqlAlchemy for Python).</p>

<p>Our layer currently wraps any string in single quotes <code>'</code> and, if contains non-ANSI characters, it automatically compose the <code>UNISTR</code> with special characters written as unicode bytes (like <code>\00E0</code>).</p>

<p>Now we created a method for doing multiple inserts with the following construct:<br>
<code>INSERT INTO ... (...)
          SELECT ... FROM DUAL
UNION ALL SELECT ... FROM DUAL
...</code></p>

<p>This algorithm could compose queries where the same string field is sometimes passed as <code>'my simple string'</code> and sometimes wrapped as <code>UNISTR('my string with special chars like \00E0')</code>.</p>

<p>The described condition causes a <code>ORA-12704: character set mismatch</code>.</p>

<p>One solution is to use the <code>INSERT ALL</code> construct but it is <strong><em>very slow</em></strong> compared to the one used now.</p>

<p>Another solution is to instruct our layer to put <code>N</code> in front of any string (except for the ones already wrapped with <code>UNISTR</code>). This is simple.</p>

<p><strong>I just want to know if this could cause any side-effect on existing queries.</strong></p>

<p>Note: all our fields on DB are either <code>NCHAR</code> or <code>NVARCHAR2</code>.</p>

<hr>

<p>Oracle ref: <a href="http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch7progrunicode.htm">http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch7progrunicode.htm</a></p>