Sunday, July 9, 2017

Oracle Tutorial

Command to connect to Oracle Database using command line interface :


  • SQLPLUS SCHEMA_NAME/PASSWORD@//HOSTNAME/ORACLE_SID
  • SQLPLUS SCHEMA_NAME/PASSWORD@ORACLE_SID


Friday, March 1, 2013

Create DB with New Character Set

Creating DB with New Character Set

Steps to create new Database with desired Character Set using Wizard.
 
1 ) Configuration Management Tool Menu
2 ) Click on DataBase Configuration Assistance
3 ) Next
4 ) Create DataBase
5 ) Next
6 ) Global Database Name : IODB
                    SID  : IODB
7) User the Same Administrative Password
   Manish03
8) Next
9) Next
10) Next
11) If required, change character set.
12) Next
13) Next
14) Finish.

Thursday, February 28, 2013

DB:ORACLE:Import Utility
Syntax :-
imp DBUSERNAME/DBPASSWORD@CONNECTIONSTRING file=D:\sample.dmp FULL=yes

There are multiple aspects while importing Dump file to Database which requires careful consideration which are followings :-

i) Username with which this dump is created
ii) Table Space which it is using.
iii) Character Set which it is reffering.


Common Issues :- Ref : http://docs.oracle.com/cd/B10500_01/server.920/a96529/ch10.htm
Issue 1 :

IMP-00038: Could not convert to environment character set's handle
IMP-00000: Import terminated unsuccessfully

It  clears that from error message that issue is with Conversion. Lets investigate this further :-

Concepts :
                            In the database data dictionary, schema object names cannot exceed 30 bytes in length.
Schema objects are tables, clusters, views, indexes, synonyms, tablespaces, and usernames. You must rename schema objects if their names exceed 30 bytes in the new database character set. For example, one Thai character in the Thai national character set requires 1 byte. In UTF8, it requires 3 bytes. If you have defined a table whose name is 11 Thai characters, then the table name must be shortened to 10 or fewer Thai characters when you change the database character set to UTF8.

If existing Oracle usernames or passwords are created based on characters that will change in size in the new character set, users will experience login difficulties due to authentication failures after the migration to a new character set. This is because the encrypted usernames and passwords stored in the data dictionary are not updated during migration to a new character set. For example, if the current database character set is WE8MSWIN1252 and the new database character set is UTF8, then the length of the username scött (o with an umlaut) will change from 5 bytes to 6 bytes. In UTF8, scött will no longer be able to log in because of the difference in the username. Oracle Corporation recommends that usernames and passwords be based on ASCII characters. If they are not, you must reset the affected usernames and passwords after migrating to a new character set.

When CHAR data contains characters that will be expanded after migration to a new character set, space padding will not be removed during database export by default. This means that these rows will be rejected upon import into the database with the new character set. The workaround is to set the BLANK_TRIMMING initialization parameter to TRUE before importing the CHAR data.

Interpretations :-
1.Replacement Characters that Result from Using the Export and Import Utilities

The Export and Import utilities can convert character sets from the original database character set to the new database character set. However, character set conversions can sometimes cause data loss or data corruption. For example, if you are migrating from character set A to character set B, the destination character set B should be a superset of character set A. The destination character, B, is a superset if it contains all the characters defined in character set A. Characters that are not available in character set B are converted to replacement characters, which are often specified as ? or ¿ or a character that is related to the unavailable character. For example, ä(a with an umlaut) can be replaced by a. Replacement characters are defined by the target character set.

To reduce the risk of losing data, choose a destination character set with a similar character repertoire. Migrating to Unicode can be an attractive option because UTF8 contains characters from most legacy character sets.

2.Invalid Data That Results from Setting the Client's NLS_LANG Parameter Incorrectly


Another character set migration scenario that can cause the loss of data is migrating a database that contains invalid data. Invalid data usually occurs in a database because the NLS_LANG parameter is not set properly on the client. The NLS_LANG value should reflect the client operating system code page. For example, in an English Windows environment, the code page is WE8MSWIN1252. When the NLS_LANG parameter is set properly, the database can automatically convert incoming data from the client operating system. When the NLS_LANG parameter is not set properly, then the data coming into the database is not converted properly. For example, suppose that the database character set is UTF8, the client is an English Windows operating system, and the NLS_LANG setting on the client is UTF8. Data coming into the database is encoded in WE8MSWIN1252 and is not converted to UTF8 data because the NLS_LANG setting on the client matches the database character set. Thus Oracle assumes that no conversion is necessary, and invalid data is entered into the database.

The second possible problem is having data from mixed character sets inside the database. For example, if the data character set is WE8MSWIN1252, and two separate Windows clients using German and Greek are both using the NLS_LANG character set setting as WE8MSWIN1252, then the database will contain a mixture of German and Greek characters.

 


Wednesday, December 8, 2010

JSF(Java Server Faces) : Introduction

JSF(Java Server Faces), initially implemented by Sun as a Framework and released as JSF version 1.0. Its next release was JSF version 1.1, however, its currently used release is JSF 1.2 under JEE 5.

JSF 1.2 is technology and is intended to develop web based applications quickly. JSF technology specification given by SUN Microsystem and implemented by two vendors :-

1. SUN RI(Reference Implementation)
2. Apache (My Faces)

Other vendor do exists in this arena as given below :-
* Rich Faces
* A4J (AJAX 4 JSF)
* Ice Faces

Like Struts framework, JSF is also implemented based on two popular design patters :-
* Front Controller
* MVC design pattern


----------------------------------------------------
Presentation | Controller | Model Layer
----------------------------------------------------
JSP I/P --> FacesServlet<-->JSF BEAN

web.xml (DD) Model
faces-config.xml
JSP O/P <--

----------------------------------------------------

FacesContext :
--------------
javax.faces.context
Class FacesContext

java.lang.Object extended by javax.faces.context.FacesContext

public abstract class FacesContext extends java.lang.Object


FacesContext contains all of the per-request state information related to the processing of a single JavaServer Faces request, and the rendering of the corresponding response. It is passed to, and potentially modified by, each phase of the request processing lifecycle.

A FacesContext instance is associated with a particular request at the beginning of request processing, by a call to the getFacesContext() method of the FacesContextFactory instance associated with the current web application. The instance remains active until its release() method is called, after which no further references to this instance are allowed. While a FacesContext instance is active, it must not be referenced from any thread other than the one upon which the servlet container executing this web application utilizes for the processing of this request.


FacesContext object is created by the Framework Servlet (i.e FacesServlet). Whenever a request arise, there will be only one FacesContext object. FacesContext object holds the following information with respect to request which is currently under processing :-

1. UIViewRoot (javax.faces.component.UIViewRoot)
2. Error Messages related to validations
3. Error Messages related to converstions
4. Response stream in terms of ByteStream
5. ExternalContext (public abstract class ExternalContext extends java.lang.Object)
6. RenderKit (public abstract class RenderKit extends java.lang.Object)

Saturday, January 30, 2010

JNI Tuter

JNI (Java Native Interface) is a standard programming interface for writing Java native methods and embedding the JVM into native application. By writing programs using the JNI, you ensure that your code is completely portable across all platforms.
The JNI allows Java code that runs within a Java Virtual Machine (VM) to operate with applications and libraries written in other languages, such as C, C++, and assembly. In addition, the Invocation API allows you to embed the Java Virtual Machine into your native applications.

Programmers use the JNI to write native methods to handle those situations when an application cannot be written entirely in the Java programming language. For example, you may need to use native methods and the JNI in the following situations:
• The standard Java class library may not support the platform-dependent features needed by your application.
• You may already have a library or application written in another programming language and you wish to make it accessible to Java applications.
• You may want to implement a small portion of time-critical code in a lower-level programming language, such as assembly, and then have your Java application call these functions.
The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them.
Native methods can also easily call Java methods. Often, you will already have developed a library of Java methods. Your native method does not need to "re-invent the wheel" to perform functionality already incorporated in existing Java methods. The native method, using the JNI framework, can call the existing Java method, pass it the required parameters, and get the results back when the method completes.
The JNI enables you to use the advantages of the Java programming language from your native method. In particular, you can catch and throw exceptions from the native method and have these exceptions handled in the Java application. Native methods can also get information about Java classes. By calling special JNI functions, native methods can load Java classes and obtain class information. Finally, native methods can use the JNI to perform runtime type checking.

We better start with one example where we can learn how to write program using JNI technology. So, here our mission is to prepare a demo where java program calls method written in C language.


Step1: Java Side
The first step in using the JNI is to create a Java file that will call our native C code.

Create a Java file called Hello.java with the following contents:

//File: Hello.java
class Hello {
public native void sayHello();
static {
System.loadLibrary("hello");
}
public static void main(String[] args) {
Hello h = new Hello();
h.sayHello ();
}
}

There are two items that distinguish this from regular Java code. The first is the
declaration of a native method using the keyword native.

public native void sayHello();

This tells the compiler that sayHello() will be accessed from an external library, and that
it should not look for it in the Java source code. Accordingly, notice that there is no
implementation of this method present in the Java code.

The second unusual looking section of code is the following:
static {
System.loadLibrary("hello");
}

This will load the external library “hello.” In Windows this file will be named
“hello.dll”. The exact name of the file is dependent on the operating system conventions
for naming of libraries.
Rest of the code is easy and regular java code which is understandable.

Step2: C Side
The remainder of the process is concerned with creating the library that will contain the
sayHello() method declared in our Java code.
To simplify the process of creating our library, the “javah” program will automatically
generate the header file for us. Simply execute the following at the command prompt in
the correct folder:
javah -jni Hello

This produces the file Hello.h. It contains the C declarations for the methods that were
declared native in Hello.java. If we open the Hello.h file we will see the following code:

/* DO NOT EDIT THIS FILE - it is machine generated */
#include
/* Header for class Hello */
#ifndef _Included_Hello
#define _Included_Hello
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: Hello
* Method: sayHello
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *, jobject);
#ifdef __cplusplus
}
#endif
#endif


The crucial component is the C declaration for our sayHello method.

JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *, jobject);

Here, we can see how method signature is generated by javah command.
Java_Hello_sayHello - Java_ClassName_methodName

Naturally, this is done to distinguish it from methods that belong to other classes and might have the same name. When we implement the C function, we need to ensure that we use the exact same method signature as is provided in the header file. It is not auto-generated for us, so we have to be careful in this regard.

Create a file called Hello.c. This will contain the implementation of our sayHello()
method. Enter the following code:

//File: Hello.c
#include
#include "Hello.h"
#include
JNIEXPORT void JNICALL Java_Hello_sayHello
(JNIEnv *env, jobject obj)
{
printf(“Welcome to JNI…!\n");
printf(“Congratulations for you first Step…”);
return;
}

Consider each line of this code in turn. First, we include the header, which is
required if we wish to use the JNI. The second line includes our auto-generated header
file. The third line includes the C standard I/O functions, so that we can use printf.

Next we see the method signature that we first saw in Hello.h. The only difference
between this line and the one in Hello.h is that the parameters to the method now have
names specified. Later we will learn how these two parameters allow us to communicate
data to and from our Java code. For now, we can simply ignore them. Using the C printf function, we display the message on the console, and then return from the function.


Step3: Generating Object file without Linking.
For generating object file, we require now gcc command which will be used to generate object file without creating exe file. This object file is further required to generate dll file.

We used MinGW-5.1.2.exe file so that gcc command may be installed in windows as well. Here you need to install this software. Then we will set path variable so that we can access it from any drive or any path. This completes initial set-up and now we are ready to execute gcc command.

gcc -c -I"C:\jdk1.4\include" -I"C:\jdk1.4\include\win32" -o hello.o Hello.c

The -c option tells the compiler not to link the program just yet, since we only want to produce an object file and not an executable.


The -I parameter adds two paths to your standard include paths, so the compiler can
access the necessary JNI header files. The paths are \include and \include\win32, where is replaced with the directory in which the Java SDK is installed on your machine. If the path name contains internal spaces, it has to be surrounded by double quotes for clarity (both for the reader and the compiler). If done correctly, this command will produce a file called hello.o.

Step4: Create Defination File.
In this step, we will create hello.def file which contains only function name which we are calling using JNI. This file format is given below:


hello.def file contains.
EXPORT
Java_Hello_sayHello

Since we have defined only one method, we are here calling only one. But if there are more native functions defined , then we need to include all of them one after another.

Step5: Creating DLL file.
To produce hello.dll, we use gcc one more time.
gcc -shared -o hello.dll hello.o hello.def
This command will generate hello.dll file with the following warning:

Warning: resolving _Java_Hello_sayHello by linking to
_Java_Hello_sayHello@8

This informs you that the compiler is automatically dealing with an issue involving the
calling conventions in Windows. Behind the scenes, gcc converts functionName to
functionName@xx, where xx is the number of bytes passed to the function on the stack.
What the compiler is warning us is that it is automatically associating functionName with
functionName@xx so that when a program looks for functionName in the library, it will
correctly be referred to functionName@xx. For a program as simple as ours, we can
essentially ignore this warning since this is the behaviour we expect.

To verify that the program is working correctly, we can run it as we would with any other Java program.
java Hello

Welcome To JNI…
Congratulations for you first Step…