You must edit the windows registry:

System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\View Source Editor\Editor Name]
Value Name: (Default)
Data Type: REG_SZ (String Value)
Value Data: Path and Filename of Editor

To determine an Oracle database's character set:

select value from nls_database_parameters where parameter='NLS_CHARACTERSET'

UTF8 was the UTF-8 encoded character set in Oracle8 and 8i.

AL32UTF8 is the UTF-8 encoded character set introduced in Oracle9i.

VB6 reports UTF8 characters as 3 bytes, and AL32UTF8 characters as 4 bytes.

How "character-based" sizing in Oracle works

It requires setting an instance or session parameter (e.g., alter session set NLS_LENGTH_SEMANTICS = 'CHAR';).  This is available starting in 9i.  Then, subsequent column declarations such as VARCHAR2(10) really mean 10 characters and not 10 bytes.  You can also be explicit on the declaration by saying VARCHAR2(10 CHAR), but that is not as flexible obviously (because it will always mean CHAR even if the database is currently set to default to BYTE).

When doing a DESC command, the keyword "BYTE" or "CHAR" only shows up in the parentheses (as in your dump below) if the table is declared in the mode opposite what your current SQL*Plus session is set to.

Writing East Asian characters languages (such as Japanese)

In order for a VB6 or .Net application to write Japanese characters to an Oracle UTF8 database, the East Asian language files must be installed on the machine running the application that writes to the database.  This is done in XP and Windows 2003 from Start->Control Panel->Regional and Language Options->Language tab.  If they are not installed, no error will occur but the Japanese characters will be written as question marks.  It is unclear why this is the case however it has been confirmed with a UTF8 Oracle database, VB6 and .Net applications, and Japanese characters.  It is assumed that this applies to all East Asian languages as well as AL32UTF8 databases.

Snippet from an Oracle document describing these character sets' support and origin:

~~~~~~~~~~~~~~~ begin snip ~~~~~~~~~~~~~~~

UTF8

UTF8 was the UTF-8 encoded character set in Oracle8 and 8i. It followed the Unicode 2.1 standard between Oracle 8.0 and 8.1.6, and was upgraded to Unicode version 3.0 for versions 8.1.7, 9i and 10g. To maintain compatibility with existing installations this character set will remain at Unicode 3.0 in future Oracle releases. Although specific supplementary characters were not assigned to Unicode until version 3.1, the allocation for these characters were already defined in 3.0. So if supplementary characters are inserted in a UTF8 database, it will not corrupt the actual data inside the database. They will be treated as 2 separate undefined characters, occupying 6 bytes in storage. We recommend that customers switch to AL32UTF8 for full supplementary character support.

AL32UTF8

This is the UTF-8 encoded character set introduced in Oracle9i. AL32UTF8 is the database character set that supports the latest version (4.01 in Oracle 10.2) of the Unicode standard. It also provides support for the newly defined supplementary characters. All supplementary characters are stored as 4 bytes. AL32UTF8 was introduced because when UTF8 was designed (in the times of Oracle8) there was no concept of supplementary characters, therefore UTF8 has a maximum of 3 bytes per character. Changing the design of UTF8 would break backward compatibility, so a new character set was introduced. The introduction of surrogate pairs should mean that no significant architecture changes are needed in future versions of the Unicode standard, so currently the plan is to keep enhancing AL32UTF8 as necessary to support future version of the Unicode standard. For example in Oracle 10.1 this character set implemented the Unicode 3.2 standard, in Oracle 10.2 that has been updated to support the Unicode 4.01 standard.

~~~~~~~~~~~~~~~ end snip ~~~~~~~~~~~~~~~

Obtain the IUSR account password:  cscript.exe adsutil.vbs get w3svc/anonymoususerpass
Obtain the IWAM account password:  cscript.exe adsutil.vbs get w3svc/wamuserpass

Set the IUSR account password:  cscript.exe adsutil.vbs set w3svc/anonymoususerpass "password"
Set the IWAM account password:  cscript.exe adsutil.vbs set w3svc/wamuserpass "password"

If the password appears as asterisks, edit the adsutil.vbs file and

change

IsSecureProperty = True

to

IsSecureProperty = False

Reference:

See PRB: Configured Identity Is Incorrect for IWAM Account for details.

Example:

C:\Inetpub\AdminScripts>cscript adsutil.vbs get W3SVC/anonymoususerpass

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

anonymoususerpass               : (STRING) "mypassword"

alter system flush shared_pool; -- flushes the cache

select * from v$sqlarea; -- for baseline

-- execute your code/sql here

select * from v$sqlarea; -- compare to baseline

keywords: sql history, past sql, previous sql statement

If you copy a .net application to a network share and try to run it, you will be default get a unhelpful error message.

"... has encountered a problem and needs to close.  We are sorry for the inconvenience."

There are at least 2 ways around this:

1. You can use the .NET Framework configuration tool (Mscorcfg.msc) to change the security policy.

For .net 10, 1.1 see: http://support.microsoft.com/kb/832742

For .net 2.0: This is only installed with the SDK, so you'll likely need to use CasPol.exe below.

The easiest way to modify your security policy is by using the Microsoft .NET Framework Configuration utility from the control panel. You can also run this tool from the command line by running mscorcfg.msc.

1. Expand the Runtime Security Policy folder
2. Expand the Machine policy level
3. Expand the Code Groups folder

To modify the polcy to trust a specific strong name:

1. Right click on All_Code, and select New
2. Create a new code group for your strong name, and hit next
3. Select a strong name membership condition from the drop down box
4. Hit the import button, and select your assembly. The configuration tool will import your public key. If you want to trust everything you sign with this key, leave the name and version boxes unchecked
5. Select the FullTrust permission set

To modify the policy to allow full trust for all Intranet assemblies:

1. Expand the All_Code code group
2. Right click the LocalIntranet_Zone code group, and select properties
3. Switch to the Permission Set tab, and select FullTrust

2. On the clinet pc you can give full trust access to the whole share which allows running any .net apps frim that share (or just an individual file if you wish) as follows:

CasPol.exe -m -ag 1.2 -url file://storage/files/* FullTrust

See: http://blogs.gotdotnet.com/shawnfa/archive/2004/12/30/344554.aspx