PL/SQL Vs PRO*C
In dealing a large volume of data, I'm using DBMS UTL_FILE package to write files on the OS. Replacing PL/SQL blocks with PRO*C shows better performance ?
null
Hi,
Sorry for delay.
It is there in this we site itself. Or O'reilly's PL/sql books contains some examples or Oracle press PL/sql book contains some examples.
Why can not you send mail directly?
Thanks,
Boby Jose Thekkanath.
Consultant,CWO.
NSW-AUS.
Similar Messages
-
Can any one tell me whether PL/SQL can totally replace Pro*C /
Cobol?
I remember there is a PL/SQL package called UTL_FILE, which
enable user to do File I/O. However, I wonder whether it really
excel the File I/O capability of the conventional Cobol or C
language.
I am going to create programs to output external data files and
sophisticated reports. Do you think it is possible, or suitable,
to apply PL/SQL in ALL cases?Can any one tell me whether PL/SQL can totally replace
Pro*C /
Cobol?
Well Pro*C/Cobol have much more advanced features
available outside of the Oracle interface, obviously. Also
UTL_FILE is not a very fast way of producing text files if you
need very high throughput.
It is not possible or suitable to apply PL/SQL to al cases, but
if you are just producing text files and reports, no matter how
complex the formatting, PL/SQL is going to do it for you.
However my own preference is to use the minimum number
of technologies reasonably possible when doing a job. By
using Pro*C or Cobol you increase the maintenance
workload, so I would stick to PL/SQL if you can. -
I have a stored procedure to query and will receive a result by it....
I used the dbms_sql package to give name of the table at run-time
then it runs in sql*plus well...
but If i called it in pro*c/c++, it would not return result...
This is my examples..
(1) stored procedure
CREATE OR REPLACE PACKAGE XDMS_STORE_PKG
IS
PROCEDURE isExistInstance(table_name IN VARCHAR2, url IN VARCHAR2, num OUT N
UMBER);
END XDMS_STORE_PKG;
CREATE OR REPLACE PACKAGE BODY XDMS_STORE_PKG IS
PROCEDURE isExistInstance (table_name IN VARCHAR2, url IN VARCHAR2, num OUT NUMBER)
IS
cursor1 integer;
rows_processed integer;
tmp NUMBER;
tmp_char VARCHAR2(10);
BEGIN
cursor1 := dbms_sql.open_cursor;
dbms_sql.parse (cursor1, 'SELECT count(*) FROM ' | | table_name | | ' WHERE DocURL = ' | | ':x', dbms_sql.v7);
dbms_sql.bind_variable(cursor1, 'x', url);
dbms_sql.define_column (cursor1, 1, tmp);
rows_processed := dbms_sql.execute (cursor1);
loop
if dbms_sql.fetch_rows (cursor1) > 0 then
dbms_sql.column_value (cursor1, 1, tmp);
num := tmp;
else
exit;
end if;
end loop;
dbms_sql.close_cursor (cursor1);
EXCEPTION
WHEN OTHERS THEN
dbms_output.put_line(sqlerrm);
if dbms_sql.is_open (cursor1) then
dbms_sql.close_cursor (cursor1);
end if;
END isExistInstance;
END XDMS_STORE_PKG;
(2) In the sqlplus
set serveroutput on;
DECLARE
cnt NUMBER;
dtdid VARCHAR2(10) := 'DT_AAAAC';
url VARCHAR2(200) := 'http://www.ce.cnu.ac.kr/~xdms/data/personnel.xml';
BEGIN
XDMS_STORE_PKG.isExistInstance(dtdid, url, cnt);
dbms_output.put_line(to_char(cnt));
END;
(3) In the pro*c/c++
bool StorageManager::isExistInstance(char *this_url)
EXEC SQL BEGIN DECLARE SECTION;
int count = 0;
char dtdid[6];
char url[200];
EXEC SQL END DECLARE SECTION;
if(isNewDtd) return false;
sprintf(dtdid, "DT_%s", this_dtdid);
strcpy(url, this_url);
EXEC SQL EXECUTE
BEGIN
XDMS_STORE_PKG.isExistInstance(:dtdid, :url, :count);
END;
END-EXEC;
if(count < 1) return false;
else return true;
thanks...
nullThis is tough it seems. However here are a few thoughts if they can help:
- Generate(build) a dynamic pl/sql block like :
Begin
Your Procedure Name
End;
keep building this piece of code for each one of your procedures in C or C++. And then execute it as any PL/sql code in the form of a 'constructed' string. Pro*C also has DEscribe Using BInd, but i do not know if that can help. -
Improving Performance of Dynamic SQL in Pro*C
I am using Dynamic sql format 3 in pro*C,
i.e prepare sqlstmt from :sql_stmt
declare cursor c1 for sqlstmt
But the query is slow .I am also using
order by with ltrim(rtrim(colname))
& sometimes group by .
can anyone tell how to improve performance
of cursors in dynamic sql,or how can
I use the same in Pl/sql with simultaneous
printing of the rows returned,on a file.
nullManoj,
Typically, the slow performance is due to the SQL statement itself rather than the dynamic SQL execution code in Pro*C.
Check your explain plan to see if the query performs well. I suspect that you will find your problem here. -
I'm modifying some C code in Linux and I encountered a warning when compiling; the warning is on a fetch from a cursor, the fetch using an indicator variable:
EXEC SQL
FETCH SALES_MODEL_CURSOR INTO :sales_model_sql :sales_model_ind;
The warning message is:
program.pc: In function `get_sales_model':
program.pc:1348: warning: cast to pointer from integer of different size
'sales_model_ind' is declared as 'short' and 'sales_model_sql' is 'varchar';That is the line of code in the .pc file, the line number pointing at the 'EXEC SQL' and the remainder of the statement (i.e., the FETCH) is on the next line. I'm not sure what pointer it's referring to; the indicator variable is declared as a 'short' as it should be.
-
Dynamic SQL and IN CLAUSE from Pro C code
Hi Guys,
Tyring to embed sql in Pro C. Here I don't know in hand how many items will be there in the IN Clause of my dynamic sql. Tried this with a loop and then adding actual values to the stement and then executing it. This worked but as this hard coding makes it literal sql and hence hampers performance. Can any one help me with how to put bind variables where we don't know how many of them will be there in a dynamic sql.
Thanks,Dynamic SQL supports user defined types, try passing a collection and using TABLE(CAST(collection)) in the SQL statement.
In the current approach (creating IN clause at runtime) keep in mind that in a IN clause you can put a maximum of 255 elements...
Max -
제품 : PRECOMPILERS
작성날짜 : 1997-12-14
pl/sql 을 call 하는 방법은 다음과 같습니다.
stored procedure call하는 방법
=================================
pl/sql program 이름이 demo_package 안의 procedure_name 라면
EXEC SQL EXECUTE
begin
demo_package.procedure_name (:empno, :deptno) ;
end;
END-EXEC ;
function call 하는 방법 :
======================
pro*c 에서 pl/sql block 을 call 하고 , 실행하는 방법은 다음과 같다 .
EXEC SQL EXECUTE
DECLARE
var1 NUMBER;
BEGIN
var1 := function_name(:param);
END;
END-EXEC
이때 precompile option SQLCHECK=semantics, USERID=scott/tiger 를
주어야 합니다.Echo Justin's comment that what you want to do is very unusual.. as pretty much everything you can do in Pro*C, can these days be done using PL/SQL inside Oracle.. so why then, from PL/SQL, call Pro*C?
Besides the options listed by Justin, there's also EXT PROC that allows the definition of external procedures. In this case the Pro*C code needs to be shared object/dynamic link library.
Examples posted in OTN threads Re: Problem with external procedure and Unix Command run successfully through PL/SQL but showing no impact in UNIX.. -
Hi all,
I used the following code to create a new Database (ScottChangDB) and a new Table (marvel) in my SQL Server 2012 Management Studio (SSMS2012) successfully:
-- ScottChangDB.sql saved in C://Documents/SQL Server XQuery_MacLochlainns Weblog_code
-- 14 April 2015 09:15 AM
USE master
IF EXISTS
(SELECT 1
FROM sys.databases
WHERE name = 'ScottChangDB')
DROP DATABASE ScottChangDB
GO
CREATE DATABASE ScottChangDB
GO
USE ScottChangDB
CREATE TABLE [dbo].[marvel] (
[avenger_name] [char] (30) NULL, [ID] INT NULL)
INSERT INTO marvel
(avenger_name,ID)
VALUES
('Hulk', 1),
('Iron Man', 2),
('Black Widow', 3),
('Thor', 4),
('Captain America', 5),
('Hawkeye', 6),
('Winter Soldier', 7),
('Iron Patriot', 8);
SELECT avenger_name FROM marvel ORDER BY ID For XML PATH('')
DECLARE @x XML
SELECT @x=(SELECT avenger_name FROM marvel ORDER BY ID FOR XML PATH('Marvel'))--,ROOT('root'))
SELECT
person.value('Marvel[4]', 'varchar(100)') AS NAME
FROM @x.nodes('.') AS Tbl(person)
ORDER BY NAME DESC
--Or if you want the completed element
SELECT @x.query('/Marvel[4]/avenger_name')
DROP TABLE [marvel]
Now I am trying to create my first XML Schema Collection to do the Validation on the Field Name (Column Title) of the "marvel" Table. I have studied Chapter 4 XML SCHEMA COLLECTIONS of the book "Pro SQL Server 2008 XML" written by
Michael Coles (published by Apress) and some beginning pages of XQuery Language Reference, SQL Server 2012 Books ONline (published by Microsoft). I mimicked Coles' Listing 04-05 and I wanted to execute the following first-drafted sql in
my SSMS2012:
-- Reference [Scott Chang modified Listing04-05.sql of Pro SQL Server 2008 XML by Michael Coles (Apress)]
-- [shcColes04-05.sql saved in C:\\Documents\XML_SQL_Server2008_code_Coles_Apress]
-- [executed: 2 April 2015 15:04 PM]
-- shcXMLschemaTableValidate1.sql in ScottChangDB of SQL Server 2012 Management Studio (SSMS2012)
-- saved in C:\Documents\XQuery-SQLServer2012
tried to run: 15 April 2015 ??? AM
USE ScottChangDB;
GO
CREATE XML SCHEMA COLLECTION dbo. ComplexTestSchemaCollection_all
AS
N'<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="marvel">
<xsd:complexType>
<xsd:all>
<xsd:element name="avenger_name" />
<xsd:element name="ID" />
</xsd:all>
</xsd:complexType>
</xsd:element>
</xsd:schema>';
GO
DECLARE @x XML (dbo. ComplexTestSchemaCollection_all);
SET @x = N'<?xml version="1.0"?>
<marvel>
<avenger_name>Thor</name>
<ID>4</ID>
</marvel>';
SELECT @x;
GO
DROP XML SCHEMA COLLECTION dbo.ComplexTestSchemaCollection_all;
GO
I feel that drafted sql is very shaky and it needs the SQL Server XML experts to modify to make it work for me. Please kindly help, exam the coding of my shcXMLTableValidate1.sql and modify it to work.
Thanks in advance,
Scott ChangHi Scott,
2) Yes, FOR XML PATH clause converts relational data to XML format with a specific structure for the "marvel" Table. Regarding validate all the avenger_names, please see below
sample.
DECLARE @x XML
SELECT @x=(SELECT ID ,avenger_name FROM marvel FOR XML PATH('Marvel'))
SELECT @x
SELECT
n.value('avenger_name[1]','VARCHAR(99)') avenger_name,
n.value('ID[1]','INT') ID
FROM @x.nodes('//Marvel') Tab(n)
WHERE n.value('ID[1]','INT') = 1 -- specify the ID here
--FOR XML PATH('Marvel') --uncommented this line if you want the result as element type
3)i.check the xml schema content
--find xml schema collection
SELECT ss.name,xsc.name collection_name FROM sys.xml_schema_collections xsc JOIN sys.schemas ss ON xsc.schema_id= ss.schema_id
select * from sys.schemas
--check the schema content,use the name,collection_name from the above query
SELECT xml_schema_namespace(N'name',N'collection_name')
3)ii. View can be viewed as virtual table. Use a view to list the XML schema content.
CREATE VIEW XSDContentView
AS
SELECT ss.name,xsc.name collection_name,cat.content
FROM sys.xml_schema_collections xsc JOIN sys.schemas ss ON xsc.schema_id= ss.schema_id
CROSS APPLY(
SELECT xml_schema_namespace(ss.name,xsc.name) AS content
) AS cat
WHERE xsc.name<>'sys'
GO
SELECT * FROM XSDContentView
By the way, it would be appreciated if you can spread your questions into posts. For any question, feel free to let me know.
Eric Zhang
TechNet Community Support -
Oracle 11g and PRO*C : pre-compile errors only with 11g !
Hi !
I didn't find a forum specific to pro*c, so here i am.
I've downloaded Oracle 11g and recompiled our applications using pro*c
We currently precompiling without any problem our sources against Oracle 7, 8, 9, 10.
With Oracle 11g, it doesn't work !
every EXEC SQL followed by a command works.
every EXEC SQL followed by a query generates the same error.
Example :
char *oracle_date_courante()
static char buf[SIZE_ORADATE+1];
EXEC SQL SELECT sysdate into :buf from DUAL;
if(ORA_SQLERROR())
oracle_error("sélection date courante");
buf[0]=0;
return buf;
PRO*C output :
Erreur Ó la ligne 105, colonne 2 dans le fichier src\oracle.pc
EXEC SQL
.1
PLS-S-00000, SQL Statement ignored
erreur sÚmantique Ó la ligne 105, colonne 2, fichier src\oracle.pc:
EXEC SQL
.1
PCC-S-02346, PL/SQL a trouvÚ des erreurs sÚmantiques
So, we investigated... And found that thoses errors come when we use the option sqlcheck=semantics.
If we use an inferiour check level, it works but because we use PL/SQL keywords, pro*c prints errors and wants us to provide the 'semantics' sqlcheck level !
So, it's a vicious circle !
Any ideas ?
Thanks...
VincentAdding the option common_parser=yes removes the errors !
But brings errors linked to the PL/SQL parser such like
CSF-S-00000, ORA-06544: PL/SQL : erreur interne, arguments : [55916], [], [], []
1>, [], [], [], []
1>ORA-06553: PLS-801: erreur interne [55916]
Really vicious..and still not precompiling !
By the way : Server is 10.2.0.1... and i guess thoses errors are normal since the common parser is not available in this version...
So bye bye option common_parser and i'm back to my orignals errors.
Message was edited by:
Vicenzo -
Hi !
I didn't find a forum specific to pro*c, so here i am because i was told this forum had a bit of pro*c activity....
I've downloaded Oracle 11g and recompiled our applications using pro*c
We currently precompiling without any problem our sources against Oracle 7, 8, 9, 10.
With Oracle 11g, it doesn't work !
every EXEC SQL followed by a command works.
every EXEC SQL followed by a query generates the same error.
Example :
char *oracle_date_courante()
static char buf[SIZE_ORADATE+1];
EXEC SQL SELECT sysdate into :buf from DUAL;
if(ORA_SQLERROR())
oracle_error("sélection date courante");
buf[0]=0;
return buf;
PRO*C output :
Erreur Ó la ligne 105, colonne 2 dans le fichier src\oracle.pc
EXEC SQL
.1
PLS-S-00000, SQL Statement ignored
erreur sÚmantique Ó la ligne 105, colonne 2, fichier src\oracle.pc:
EXEC SQL
.1
PCC-S-02346, PL/SQL a trouvÚ des erreurs sÚmantiques
So, we investigated... And found that thoses errors come when we use the option sqlcheck=semantics.
If we use an inferiour check level, it works but because we use PL/SQL keywords, pro*c prints errors and wants us to provide the 'semantics' sqlcheck level !
So, it's a vicious circle !
Any ideas ?
Thanks...
VincentAdding the option common_parser=yes removes the errors !
But brings errors linked to the PL/SQL parser such like
CSF-S-00000, ORA-06544: PL/SQL : erreur interne, arguments : [55916], [], [], []
1>, [], [], [], []
1>ORA-06553: PLS-801: erreur interne [55916]
Really vicious..and still not precompiling !
By the way : Server is 10.2.0.1... and i guess thoses errors are normal since the common parser is not available in this version...
So bye bye option common_parser and i'm back to my orignals errors.
Message was edited by:
Vicenzo -
Migration of Oracle 8i PL/SQL to Oracle 9i PL/SQL
Hi,
Can anybody help me giving information about mandatory requirements to migrate from 8i to 9i. Also please let me know if any documents related to that for PL/SQL and PRO * C migration from 8i to 9i.
Thanks with Regards,
GuruAre there any issues that you are facing?
If your software was well tuned and working fine under Oracle8i, you may just be able to port it right into Oracle9i without any issues.
Ofcourse, If may also depend upon how the Oracle9i instance and database has been setup by the DBA. -
Hi,
I have created a table as follows:
===========================================
CREATE TYPE pds_rec_type1_obj AS OBJECT (
service_mode char,
total_fuel_dollars NUMBER(7,2),
total_fuel_litres NUMBER(7)
CREATE TABLE pos_product_discount (
outlet_id NUMBER(5) NOT NULL,
terminal_id NUMBER(2) NOT NULL,
rt1 pds_rec_type1_obj,
===========================================
After insert one row in to the pos_product_discount table,
I can update it by using
===========================================
update pos_product_discount
set rt1 = pds_rec_type1_obj('2', 1, 1)
where outlet_id = 4736 and TERMINAL_ID = 1
===========================================
However, when I used the following SQL in Pro*C++
===========================================
EXEC SQL
UPDATE pos_product_discount
SET rt1 = pds_rec_type1_obj(:rt1ServiceMode,
:rt1TotFuelDollarsSold,
:rt1TotFuelLitresSold)
WHERE outlet_id = :pdsOutletId
AND terminal_id = :pdsTerminalId;
===========================================
I got the following error:
===========================================
ERROR: UPDATE pos_product_discount
ORA-00904: invalid column name
ERROR: Oracle SQL Error...
=============================================
Anyone can help? Thank you in advance.
Zhenjie ChenHi,
Please look at chapter-17 (Objects) of "Pro*C/C++ Precompiler Programmer's Guide".
You need to use "EXEC SQL OBJECT SET ... " before "EXEC SQL OBJECT UPDATE ... " statement.
- Shubho. -
How to convert Oracle database to Sql server Database
Hi All,
I have one database made in the Oracle 8i, i want to convert that database to Sql Server Database,
Can anyone please give me the step by step process to do this conversion.
Regards
Ramesh JhaTry using the DTS (data transformation services) services of SQL Server 2000
DTS is based on an OLE DB architecture that allows you to copy and transform data from a variety of data sources. For example: Oracle directly, using native OLE DB providers.
Alternatively, you could follow the following broad steps for data migration (assuming you are retaining the same table structures in SQL Server, and that you are talking about SQL Server 2000).
1. Get the CREATE scripts corresponding to each Oracle table / view / index. These can be reverse engineered from the database using a tool.
2. Map Oracle datatypes to SQL server datatypes e.g: date maps to datetime/smalldatetime, numeric maps to one of int, bigint, smallint, etc depending on the range of values in the CREATE scripts.
3. Indexes in SQL Server are of two types: Clustered / non-clustered. There can only be one clustered index on each table.
4. Converting procedures and triggers will have to be line by line, since SQL Server uses a proprietary T-SQL instead of ORacle's PL/SQL
I have yet to see a really good tool to do this migration, but it is possible to write a PL/SQL procedure / Pro*C program to automate the script creation for creating tables in the SQL Server database.
For the actual data import into SQL Server, export the Oracle data table by table into flat files, and then use the import wizard of SQL Server enterprise manager -
PRO*C VERSION MATRIX 및 VERSION 별 특성
제품 : PRECOMPILERS
작성날짜 : 1998-02-19
PRO*C version matrix 및 version 별 지원 내용
===========================================
[1] PRO*C 의 version 별 지원 내용
RDBMS 의 version 과 PRO*C 의 version 별 지원내용은 다음과 같다.
PRO* Last RDBMS Languages
Version Version Version
======================================================================
1.3 1.3.20 <6.0.35 PRO*C
1.4 1.4.15/6 6.x "
1.5 1.5.10 7.0.x "
1.6 1.6.7 7.1.x "
1.6 1.6.9 7.2.x "
2.0 2.0.6 7.1.x "
2.1 2.1.3 7.2.x "
2.2 2.2.? 7.3.x "
[2] 각 version 의 pro*c의 precompile option 추가 부분과 header file
위치는 다음과 같다.
(1) version 1.4
Location: $ORACLE_HOME/proc/demo
File: proc.mk
Build from "prog.pc": make -f proc.mk prog
Where to add options: edit PRO14FLAGS
Header files in: $ORACLE_HOME/proc/lib
(2) version 1.5
Location: $ORACLE_HOME/proc/demo
File: proc.mk
Build from "prog.pc": make -f proc.mk prog
Where to add options: edit PROFLAGS
Header files in: $ORACLE_HOME/proc/lib
(3) verion 1.6 , 1.7,1.8
Location: $ORACLE_HOME/proc16/demo
File: proc16.mk
Build from "prog.pc": make -f proc.mk prog
Where to add options: edit PCCFLAGS
Header files in: $ORACLE_HOME/sqllib/public
(4) version 2.0, 2.1
Location: $ORACLE_HOME/proc/demo
File: proc.mk
Build from "prog1.pc": make -f proc.mk EXE=prog OBJS="prog1.o prog2.o"
and "prog2.pc"
Where to add options: add PROFLAGS
Header files in: $ORACLE_HOME/sqllib/public
(5) version 2.2
Location: $ORACLE_HOME/precomp/demo/proc
File: proc.mk
Build from "prog1.pc": make -f proc.mk build EXE=prog OBJS="prog1.o
prog2.o"
and "prog2.pc"
Where to add options: add PROCFLAGS
Header files in: $ORACLE_HOME/precomp/public
[3]다음은 각 VERSION 별 지원 내용을 살펴 보기로 한다.
(1) VERSION 1.4
1. precompiler option 의 추가된 부분은 LINES=YES option지정시 outpute 에
#line directives 생성 지원되어debugging 에 도움울 줄수 있게
되었으며, dynamic method 사용시 HOLD_CURSOR=YES option을 사용하여
cursor의 재사용을 방지할 수 있게 되었다. AREASIZE,REBIND option 이
없어지고 MODE=ANSI14 option 을 지원 가능하게 되었다. 그러나 이 ANSI14
option 을 사용시는 4byte inter 인 SQLCODE 를 반드시 declare 해야 한다.
SQLCHECK=SEMANTICS/SYNTAX/NONE (Default는 SYNTAX) 가 사용되고, 더이상
log를 db에 기록하지 않게 되었다.
2 Datatype equivalencing 지원 한다.
EXEC SQL VAR host_variable IS datatype ;
EXEC SQL TYPE type is datatype REFERENCE ;
3. Indicator 변수를 사용가능 ( :host INDICATOR :indicator ) 하게
되었으며 또한 AT 절에 host 변수를 사용가능하게 되었다. 또host변수
선언시 auto, extern, static, const, volatile 사용 가능하다.
4. SQLCA 의 sqlerrd(5) 에 0 based parse offset을 저장하였으나, v2.x 의
현재 version 에서는 사용되어지지 않고있다..
5 procedure call 이 가능하게 되었다. (EXEC SQL WHENEVER ... DO
procedure) .
또한 EXEC SQL WHENEVER ... DO break; 문이 사용가능하다 .
6. Precompiler 실행모듈이 각 언어마다 구분되어 pro*c 의 경우function의
prototypes 생성
가능하다.
(2) Version 1.5
============
이 version 은 ORACLE RDBMS 7.x 를 지원하는 pro*c version 으로 완벽한
ANSI SQL을 지원한다. 또한 NLS 의 support 도 지원가능하다
1. precompile option 의 변경사항으로는 DBMS=NATIVE/V6/V7 option
지원하며 FIPS=YES로 설정시 ANSI extension 지원한다.
2. data type 변경사항으로는 fixed length datatypes 지원하는 CHARF,
CHARZ가 사용가능하며 LONG VARCHAR,LONG VARRAW datatypes 지원가능하다.
또한 MLSLABEL 데이타 타입사용 가능하게 되었는데 이는 variable_lengrh
의 binary OS label 을 저장할때 사용가능하다.
3. indicators 없는 host 변수가 null을 fetch하면, DBMS=V6으로
설정하지 않은 경우는
ORA-1405를 return 함. PL/SQL table을 파라미터로 하는 stored
procedures 호출 가능.
4. 이전 version 에서 space 만 가능했던 (bug) input character string
데이타 타입이
terminator를 포함하는 경우도 이를 데이타로 인식 가능
(3) version 1.6
==================
1.변경된 precompile option 으로 AUTO_CONNECT=YES option
지원하는데
이를 지정시는 처음 sql 문 수행시 OPS$<username>으로 자동 connect 된다.
또한 CONFIG=<file> option 지원으로 user 의 configuration 의 name 과
위치를 지정할수 있다. 또한 시스템 config file 사용 가능한데 이의 위치는
UNIX = $ORACLE_HOME/proc16/pccc.cfg, VMS=ora_pcc:pccc.cfg. 이다.
2. SQLSTATE 변수는 SQL문 실행 이후에 값이 설정된다. MODE=ANSI로 설정이
되어 있고, declare section안에 선언되어 있는 경우에만 이값이 설정된다.
만일 그렇지 않으면 이 값은 무시된다.만약 SQLCODE가 안에 선언되어 있다면,
이 두 변수 모두 값이 설정된다.
만약 SQLCODE가 밖에 선언되어 있다면 SQLSTATE만 설정된다. SQLSTATE는
coding scheme를 표준화하는데 사용된다. SQLCODE는 declare section
내부에 선언되거나, SQLSTATE, SQLCA가 사용되지 않는 경우에 사용하게 된다.
이 점은 1.5 버젼에서 SQLCA를 declare section 밖에 선언하여, SQLCA와
같이 사용되었던 것과는 차이가 있다.
3. SQLGLS 함수 지원하는데 이는 마지막 문장을 parse 한 후, 문장의 길이
및 타입을 return한다.
eg) int sqlgls(char *sqlstm ,size_t
*stmlen,size_t *sqlfc)
4. select 문에서 stored function 을 call 할수 있다.
5. 단 SQLCHECK=FULL/SEMANTICS 가 아닌 경우에 FROM 절에서 subquery 가
가능하다. 이는 PL/SQL 의 semantic check 인 경우는 v7.3 에서 가능하다 .
(4) Version 1.8
================
1. INDICATOR VARIABLE을 사용하지 않고도 NULL FETCH시 ORA-1405 에러가
발생하지 않도록 UNSAFE_NULL=YES 옵션이 추가됨. UNSAFE_NULL=YES로
설정하면 ORA-1405 를 방지하기 위해서 DBMS=V6 으로 세팅할 필요없이
DBMS=V7 으로 할 수 있음. 단, UNSAFE_NULL=YES를 사용하기 위해서는
MODE=ORACLE 로 설정해야 함.
2. PACKAGE ARGUMENT로 PL/SQL CURSOR(WEAKLY TYPED)를 사용할 수 있는데
예를 들면 TYPE GeneralCurTyp IS REF CURSOR;
3. FROM 절에서 SUBQUERY를 사용할 수 있고 SQLCHECK=SEMANTICS 또는
SQLCHECK=FULL 옵션을 사용할 수 있음.
4. PL/SQL 블럭에서 PL/SQL TABLE과 이와 관련된 다음 함수를 지원.
a_table(index).EXISTS, a_table.COUNT, a_table.FIRST, a_table.LAST,
a_table.PRIOR(index), a_table.NEXT(index),
a_table.DELETE(start_index,_index), a_table.DELETE.
5. WHERE CURRENT OF CURSOR를 이용해서 MULTI-TABLE VIEW를 통해
KEY-PRESERVED TABLE을 UPDATE 가능.
(5) version 2.0
==================
RDBMS version 7.3에서 부터 makefile 은
ins_precomp.mk,env_precomp.mk, proc.mk의 3 개로 나뉘었다.
Ins_precomp.mk 는 기존의 proc.mk 처럼 precompiler executables 를 build
하기 위한 routine 이고 env_precomp.mk 는 모든 environment 의 변수와
libraray 를 포함한다.
이 file 은 Ins_precomp.mk 와 proc.mk 에 포함되어 사용되어진다.
1. V1.6과 같이 AUTO_CONNECT, CONFIG 옵션 지원. SYSTEM CONFIGURATION
FILE은 UNIX에서는 $ORACLE_HOME/proc/pmscfg.h 이고 VMS에서는
ora_proc20:pmscfg.cfg
2. V1.6과 같이 SQLSTATE 변수와 SQLGLS 함수가 제공된다.
3. C PREPROCESSOR가 포함되어서 #define이 EMBEDDED SQL과 함께 이용될 수
있고 #include 로 PRO*C 헤더화일을 INCLUDE 가능.
4. 구조체를 HOST 변수로 사용 가능. 이것은 SELECT INTO, FETCH INTO
또는 INSERT시 VALUES 절에 사용될 수 있으나 PL/SQL PROCEDURE에 PL/SQL
RECORD ARGUMENT로 사용할 수는 없음. 구조체 내에 또다른 구조체를 포함할
수는 없지만 ARRAY는 포함할 수 있음.
5. HOST 변수를 BEGIN/END DECLARE SECTION 안에 넣을 필요가 없음.
6. V1.6에서 처럼 SELECT LIST에 STORED FUNCTION의 사용이 가능.
7. SQLCHECK=FULL/SEMANTOCS를 사용하지 않는 경우 FROM 절에 SUBQUERY를
쓸 수 있음.
8. CHARACTER 변수의 BIND TYPE은 MODE 옵션이 아니라 DBMS 옵션에 따라서
결정됨. DBMS=V6/V6_CHAR 인 경우, CHARACTER는 TYPE 1, DBMS=V7(또는
NATIVE이고 ORACLE7에 접속할 때) 에서는 TYPE 97.
9. DBMS=V6_CHAR 는 CHARACTER 변수가 가변 길이 문자열로 다루어질 수
있도록 함.
10. SQLVCP 함수는 VARCHAR ARR 변수를 지정한 길이로 만들어 주므로
VARCHAR를 동적으로 할당할 때 COMPILER가 BYTE ALIGNMENT를 가능하게 함.
11. PRO*C의 PARSE LEVEL을 설정하는 PARSE 옵션.
a) NONE - PRO*C V1과 같음(HOST 변수를 DECLARE SECTION에 넣어야 함.
#define 인식 안함 등)
b) PARTIAL - HOST 변수를 DECLARE SECTION에 넣어야 함
c) FULL - PRO*C V2의 기능 모두 지원
12. EXEC SQL WHENEVER ... DO 함수명(args,...); 와 같이 함수호출시UMENT를
주고 받을 수 있음.
13. #ifdef/#ifndef 와 EXEC ORACLE IFDEF/IFNDEF 에서 사용하기 위한
DEFINE 옵션 지원.
(6) version 2.1
================
1. PRO*C V1.7에서와 같이 char와 IMPLICIT VARCHAR (VARCHAR=YES 옵션과
함께 적절한 C 구조체로 선언된 변수) HOST 변수에서 MULTI-BYTE NLS
CHARACTER 데이타와 MULTI-BYTE 문자열을 지원.
NLS_CHAR=var1,var2,... 옵션으로 MULTI-BYTE HOST 변수를 지정함.
MULTI-BYTE 리터럴은 다음과 같이 사용된다.
EXEC SQL SELECT ... WHERE ENAME = N*이경구*;
단, 이것은 SQLLIB RUNTIME LIBRARY를 통해서 지원되기 때문에 MULTI-BYTE
NLS 문자열은 DYNAMIC SQL에서 사용될 수 없음. NCHAR 데이타타입은 DDL 과
함께 사용될 수 없음.
2. PRO*C V1.7과 같이 NLS_LOCAL 옵션 지원
3. DEF_SQLCODE=YES 로 설정하면 PRO*C는 다음 문장을 생성한다.
#define SQLCODE sqlca.sqlcode
SQLCA는 반드시 INCLUDE 되어야 하며 SQLCODE 변수는 선언되어서는 안됨.
4. PRO*C V1.7 과 같이 CURSOR VARIABLE 지원.
5. VARCHAR=YES 로 설정하면 특정한 구조체를 VARCHAR로 인식할 수 있다.
구조체의 형태를 보면
struct
short len;
char arr[n];
} host_var;
6. CODE=CPP 로 설정하면 SQLLIB 함수 원형(PROTOTYPE)은 다음과 같이
extern "C" 형식으로 생성됨.
extern "C" {
void sqlora( unsigned long *, void *);
그리고 "//" 와 같은 COMMENT 처리명령을 인식함. 단, CODE=CPP인 경우
PARSE 는 자동적으로 PARTIAL로 설정됨.
CPP_SUFFIX 옵션은 PRECOMPILE된 화일의 확장자를 지정.
SYS_INCLUDE=(dir1,dir2,...) 옵션은 C 헤더 화일과 다른 위치에 있는 C++
헤더 화일이 있는 디렉토리를 지정. 이 옵션은 PARSE 옵션이 NONE이 아닌
경우에만 필요하다. HEADER 화일을 찾는 위치는 SYS_INCLUDE, 현재 디렉토리,
표준 SYSTEM 디렉토리(UNIX에서 PRO*C 헤더 화일의 위치는
$ORACLE_HOME/sqllib/public), 그리고 INCLUDE 옵션에 지정된 디렉토리이다.제품 : PRECOMPILERS
작성날짜 : 1998-02-19
PRO*C version matrix 및 version 별 지원 내용
===========================================
[1] PRO*C 의 version 별 지원 내용
RDBMS 의 version 과 PRO*C 의 version 별 지원내용은 다음과 같다.
PRO* Last RDBMS Languages
Version Version Version
======================================================================
1.3 1.3.20 <6.0.35 PRO*C
1.4 1.4.15/6 6.x "
1.5 1.5.10 7.0.x "
1.6 1.6.7 7.1.x "
1.6 1.6.9 7.2.x "
2.0 2.0.6 7.1.x "
2.1 2.1.3 7.2.x "
2.2 2.2.? 7.3.x "
[2] 각 version 의 pro*c의 precompile option 추가 부분과 header file
위치는 다음과 같다.
(1) version 1.4
Location: $ORACLE_HOME/proc/demo
File: proc.mk
Build from "prog.pc": make -f proc.mk prog
Where to add options: edit PRO14FLAGS
Header files in: $ORACLE_HOME/proc/lib
(2) version 1.5
Location: $ORACLE_HOME/proc/demo
File: proc.mk
Build from "prog.pc": make -f proc.mk prog
Where to add options: edit PROFLAGS
Header files in: $ORACLE_HOME/proc/lib
(3) verion 1.6 , 1.7,1.8
Location: $ORACLE_HOME/proc16/demo
File: proc16.mk
Build from "prog.pc": make -f proc.mk prog
Where to add options: edit PCCFLAGS
Header files in: $ORACLE_HOME/sqllib/public
(4) version 2.0, 2.1
Location: $ORACLE_HOME/proc/demo
File: proc.mk
Build from "prog1.pc": make -f proc.mk EXE=prog OBJS="prog1.o prog2.o"
and "prog2.pc"
Where to add options: add PROFLAGS
Header files in: $ORACLE_HOME/sqllib/public
(5) version 2.2
Location: $ORACLE_HOME/precomp/demo/proc
File: proc.mk
Build from "prog1.pc": make -f proc.mk build EXE=prog OBJS="prog1.o
prog2.o"
and "prog2.pc"
Where to add options: add PROCFLAGS
Header files in: $ORACLE_HOME/precomp/public
[3]다음은 각 VERSION 별 지원 내용을 살펴 보기로 한다.
(1) VERSION 1.4
1. precompiler option 의 추가된 부분은 LINES=YES option지정시 outpute 에
#line directives 생성 지원되어debugging 에 도움울 줄수 있게
되었으며, dynamic method 사용시 HOLD_CURSOR=YES option을 사용하여
cursor의 재사용을 방지할 수 있게 되었다. AREASIZE,REBIND option 이
없어지고 MODE=ANSI14 option 을 지원 가능하게 되었다. 그러나 이 ANSI14
option 을 사용시는 4byte inter 인 SQLCODE 를 반드시 declare 해야 한다.
SQLCHECK=SEMANTICS/SYNTAX/NONE (Default는 SYNTAX) 가 사용되고, 더이상
log를 db에 기록하지 않게 되었다.
2 Datatype equivalencing 지원 한다.
EXEC SQL VAR host_variable IS datatype ;
EXEC SQL TYPE type is datatype REFERENCE ;
3. Indicator 변수를 사용가능 ( :host INDICATOR :indicator ) 하게
되었으며 또한 AT 절에 host 변수를 사용가능하게 되었다. 또host변수
선언시 auto, extern, static, const, volatile 사용 가능하다.
4. SQLCA 의 sqlerrd(5) 에 0 based parse offset을 저장하였으나, v2.x 의
현재 version 에서는 사용되어지지 않고있다..
5 procedure call 이 가능하게 되었다. (EXEC SQL WHENEVER ... DO
procedure) .
또한 EXEC SQL WHENEVER ... DO break; 문이 사용가능하다 .
6. Precompiler 실행모듈이 각 언어마다 구분되어 pro*c 의 경우function의
prototypes 생성
가능하다.
(2) Version 1.5
============
이 version 은 ORACLE RDBMS 7.x 를 지원하는 pro*c version 으로 완벽한
ANSI SQL을 지원한다. 또한 NLS 의 support 도 지원가능하다
1. precompile option 의 변경사항으로는 DBMS=NATIVE/V6/V7 option
지원하며 FIPS=YES로 설정시 ANSI extension 지원한다.
2. data type 변경사항으로는 fixed length datatypes 지원하는 CHARF,
CHARZ가 사용가능하며 LONG VARCHAR,LONG VARRAW datatypes 지원가능하다.
또한 MLSLABEL 데이타 타입사용 가능하게 되었는데 이는 variable_lengrh
의 binary OS label 을 저장할때 사용가능하다.
3. indicators 없는 host 변수가 null을 fetch하면, DBMS=V6으로
설정하지 않은 경우는
ORA-1405를 return 함. PL/SQL table을 파라미터로 하는 stored
procedures 호출 가능.
4. 이전 version 에서 space 만 가능했던 (bug) input character string
데이타 타입이
terminator를 포함하는 경우도 이를 데이타로 인식 가능
(3) version 1.6
==================
1.변경된 precompile option 으로 AUTO_CONNECT=YES option
지원하는데
이를 지정시는 처음 sql 문 수행시 OPS$<username>으로 자동 connect 된다.
또한 CONFIG=<file> option 지원으로 user 의 configuration 의 name 과
위치를 지정할수 있다. 또한 시스템 config file 사용 가능한데 이의 위치는
UNIX = $ORACLE_HOME/proc16/pccc.cfg, VMS=ora_pcc:pccc.cfg. 이다.
2. SQLSTATE 변수는 SQL문 실행 이후에 값이 설정된다. MODE=ANSI로 설정이
되어 있고, declare section안에 선언되어 있는 경우에만 이값이 설정된다.
만일 그렇지 않으면 이 값은 무시된다.만약 SQLCODE가 안에 선언되어 있다면,
이 두 변수 모두 값이 설정된다.
만약 SQLCODE가 밖에 선언되어 있다면 SQLSTATE만 설정된다. SQLSTATE는
coding scheme를 표준화하는데 사용된다. SQLCODE는 declare section
내부에 선언되거나, SQLSTATE, SQLCA가 사용되지 않는 경우에 사용하게 된다.
이 점은 1.5 버젼에서 SQLCA를 declare section 밖에 선언하여, SQLCA와
같이 사용되었던 것과는 차이가 있다.
3. SQLGLS 함수 지원하는데 이는 마지막 문장을 parse 한 후, 문장의 길이
및 타입을 return한다.
eg) int sqlgls(char *sqlstm ,size_t
*stmlen,size_t *sqlfc)
4. select 문에서 stored function 을 call 할수 있다.
5. 단 SQLCHECK=FULL/SEMANTICS 가 아닌 경우에 FROM 절에서 subquery 가
가능하다. 이는 PL/SQL 의 semantic check 인 경우는 v7.3 에서 가능하다 .
(4) Version 1.8
================
1. INDICATOR VARIABLE을 사용하지 않고도 NULL FETCH시 ORA-1405 에러가
발생하지 않도록 UNSAFE_NULL=YES 옵션이 추가됨. UNSAFE_NULL=YES로
설정하면 ORA-1405 를 방지하기 위해서 DBMS=V6 으로 세팅할 필요없이
DBMS=V7 으로 할 수 있음. 단, UNSAFE_NULL=YES를 사용하기 위해서는
MODE=ORACLE 로 설정해야 함.
2. PACKAGE ARGUMENT로 PL/SQL CURSOR(WEAKLY TYPED)를 사용할 수 있는데
예를 들면 TYPE GeneralCurTyp IS REF CURSOR;
3. FROM 절에서 SUBQUERY를 사용할 수 있고 SQLCHECK=SEMANTICS 또는
SQLCHECK=FULL 옵션을 사용할 수 있음.
4. PL/SQL 블럭에서 PL/SQL TABLE과 이와 관련된 다음 함수를 지원.
a_table(index).EXISTS, a_table.COUNT, a_table.FIRST, a_table.LAST,
a_table.PRIOR(index), a_table.NEXT(index),
a_table.DELETE(start_index,_index), a_table.DELETE.
5. WHERE CURRENT OF CURSOR를 이용해서 MULTI-TABLE VIEW를 통해
KEY-PRESERVED TABLE을 UPDATE 가능.
(5) version 2.0
==================
RDBMS version 7.3에서 부터 makefile 은
ins_precomp.mk,env_precomp.mk, proc.mk의 3 개로 나뉘었다.
Ins_precomp.mk 는 기존의 proc.mk 처럼 precompiler executables 를 build
하기 위한 routine 이고 env_precomp.mk 는 모든 environment 의 변수와
libraray 를 포함한다.
이 file 은 Ins_precomp.mk 와 proc.mk 에 포함되어 사용되어진다.
1. V1.6과 같이 AUTO_CONNECT, CONFIG 옵션 지원. SYSTEM CONFIGURATION
FILE은 UNIX에서는 $ORACLE_HOME/proc/pmscfg.h 이고 VMS에서는
ora_proc20:pmscfg.cfg
2. V1.6과 같이 SQLSTATE 변수와 SQLGLS 함수가 제공된다.
3. C PREPROCESSOR가 포함되어서 #define이 EMBEDDED SQL과 함께 이용될 수
있고 #include 로 PRO*C 헤더화일을 INCLUDE 가능.
4. 구조체를 HOST 변수로 사용 가능. 이것은 SELECT INTO, FETCH INTO
또는 INSERT시 VALUES 절에 사용될 수 있으나 PL/SQL PROCEDURE에 PL/SQL
RECORD ARGUMENT로 사용할 수는 없음. 구조체 내에 또다른 구조체를 포함할
수는 없지만 ARRAY는 포함할 수 있음.
5. HOST 변수를 BEGIN/END DECLARE SECTION 안에 넣을 필요가 없음.
6. V1.6에서 처럼 SELECT LIST에 STORED FUNCTION의 사용이 가능.
7. SQLCHECK=FULL/SEMANTOCS를 사용하지 않는 경우 FROM 절에 SUBQUERY를
쓸 수 있음.
8. CHARACTER 변수의 BIND TYPE은 MODE 옵션이 아니라 DBMS 옵션에 따라서
결정됨. DBMS=V6/V6_CHAR 인 경우, CHARACTER는 TYPE 1, DBMS=V7(또는
NATIVE이고 ORACLE7에 접속할 때) 에서는 TYPE 97.
9. DBMS=V6_CHAR 는 CHARACTER 변수가 가변 길이 문자열로 다루어질 수
있도록 함.
10. SQLVCP 함수는 VARCHAR ARR 변수를 지정한 길이로 만들어 주므로
VARCHAR를 동적으로 할당할 때 COMPILER가 BYTE ALIGNMENT를 가능하게 함.
11. PRO*C의 PARSE LEVEL을 설정하는 PARSE 옵션.
a) NONE - PRO*C V1과 같음(HOST 변수를 DECLARE SECTION에 넣어야 함.
#define 인식 안함 등)
b) PARTIAL - HOST 변수를 DECLARE SECTION에 넣어야 함
c) FULL - PRO*C V2의 기능 모두 지원
12. EXEC SQL WHENEVER ... DO 함수명(args,...); 와 같이 함수호출시UMENT를
주고 받을 수 있음.
13. #ifdef/#ifndef 와 EXEC ORACLE IFDEF/IFNDEF 에서 사용하기 위한
DEFINE 옵션 지원.
(6) version 2.1
================
1. PRO*C V1.7에서와 같이 char와 IMPLICIT VARCHAR (VARCHAR=YES 옵션과
함께 적절한 C 구조체로 선언된 변수) HOST 변수에서 MULTI-BYTE NLS
CHARACTER 데이타와 MULTI-BYTE 문자열을 지원.
NLS_CHAR=var1,var2,... 옵션으로 MULTI-BYTE HOST 변수를 지정함.
MULTI-BYTE 리터럴은 다음과 같이 사용된다.
EXEC SQL SELECT ... WHERE ENAME = N*이경구*;
단, 이것은 SQLLIB RUNTIME LIBRARY를 통해서 지원되기 때문에 MULTI-BYTE
NLS 문자열은 DYNAMIC SQL에서 사용될 수 없음. NCHAR 데이타타입은 DDL 과
함께 사용될 수 없음.
2. PRO*C V1.7과 같이 NLS_LOCAL 옵션 지원
3. DEF_SQLCODE=YES 로 설정하면 PRO*C는 다음 문장을 생성한다.
#define SQLCODE sqlca.sqlcode
SQLCA는 반드시 INCLUDE 되어야 하며 SQLCODE 변수는 선언되어서는 안됨.
4. PRO*C V1.7 과 같이 CURSOR VARIABLE 지원.
5. VARCHAR=YES 로 설정하면 특정한 구조체를 VARCHAR로 인식할 수 있다.
구조체의 형태를 보면
struct
short len;
char arr[n];
} host_var;
6. CODE=CPP 로 설정하면 SQLLIB 함수 원형(PROTOTYPE)은 다음과 같이
extern "C" 형식으로 생성됨.
extern "C" {
void sqlora( unsigned long *, void *);
그리고 "//" 와 같은 COMMENT 처리명령을 인식함. 단, CODE=CPP인 경우
PARSE 는 자동적으로 PARTIAL로 설정됨.
CPP_SUFFIX 옵션은 PRECOMPILE된 화일의 확장자를 지정.
SYS_INCLUDE=(dir1,dir2,...) 옵션은 C 헤더 화일과 다른 위치에 있는 C++
헤더 화일이 있는 디렉토리를 지정. 이 옵션은 PARSE 옵션이 NONE이 아닌
경우에만 필요하다. HEADER 화일을 찾는 위치는 SYS_INCLUDE, 현재 디렉토리,
표준 SYSTEM 디렉토리(UNIX에서 PRO*C 헤더 화일의 위치는
$ORACLE_HOME/sqllib/public), 그리고 INCLUDE 옵션에 지정된 디렉토리이다. -
PRO*C에서 에러 처리하기 (SQLSTATE, SQLCODE, SQLCA)
제품 : PRECOMPILERS
작성날짜 : 1997-02-06
디자인상의 문제, 코딩상의 문제, 하드웨어 문제, 비정상적인 값의 입력 등등....
프로그램을 수행하다 보면 다양한 에러들을 접하게 된다. 프로그램을 정상적으로
수행하기 위해서는 이들 에러에 대한 적절한 대책이 필요 한데, 특히 SQL문의
수행과 관련된 에러의 처리는 데이타의 무결성을 유지하고, 정확한 트랜젝션
수행의 기본이 된다. PRO*C에서는 SQL문과 관련된 에러를 처리하기 위한 다양한
방법을 제공하고 있는데, 크게 상태 변수(SQLSTATE, SQLCODE)를 사용하는 방법과 SQLCA를 활용하는 방법으로 나눠볼 수 있다.
1) MODE OPTION값에 따른 ERROR 처리
* MODE = ANSI 일때
SQLSTATE나 SQLCODE중에 하나는 반드시 사용해야 한다.
SQLCA는 선택적이다.
* MODE = ORACLE
SQLCA를 사용해야 한다.
SQLSTATE나 SQLCODE는 선언해도 사용되지 않는다.
2) SQLCODE
SQLCODE는 SQL문을 수행한 STATUS CODE 값을 가지고 있다.
이 변수는 LONG으로 선언해서 사용해야 한다.
< 예제 >
DECLARE SQL BEGIN DECLARE SECTION;
int emp_number, dept_number;
EXEC SQL END DECLARE SECTION;
long SQLCODE;
3) SQLSTATE 상태 변수 (status variable)
SQLCODE와 달리 SQLSTATE는 에러와 warning을 모두 저장하고 있고, character
5자리의 값을 가지고 있다. SQLSTATE를 사용하기 위해서는 반드시 CHAR SQLSTATE[6]; 으로 선언해야 한다.
SQLSTATE 상태 코드는 예외의 유형을 구분해주는 CLASS 두 자리와 구체적인
예외를 말해주는 3자리의 SUBCLASS로 구성된다. 이들 CODE값과 그 의미는 PROGRAMMER*S GIDE TO THE ORACLE PRO*C/C++ PRECOMPILER의 Handling
runtime error편에 자세히 나와 있다.
4) SQLCA(COMMUNICATION AREA)의 사용
SQLCA는 ORACLE COMMUNICATION을 다루는 C STRUCT를 말한다. 이는 상태 코드,
경고 FLAG, 처리된 ROW 수, PARSING ERROR, 기타 에러 메세지에 관한 정보를
담고 있다.
* SQLCA의 선언
EXEC SQL INCLUDE SQLCA; 또는 # include <sqlca.h>
* SQLCA STRUCTURE와 의미
- sqlcaid : identifier
- sqlcabc : SQLCA의 총size
- sqlcode : 최근에 실행된 SQL문의 상태코드
0 에러 없이 정상 수행
>0 SQL문이 수행되기는 했지만 exception이 발생
<0 SQL문 수행 안됨. sqlca.sqlerr[4]로 내용 확인 가능
- sqlerrm : 에러 메세지 길이(sqlerrml)와 메시지 내용(sqlerrmc)
메세지는 총 70자리 까지 밖에 저장되지 않음. 이 이상
의 메세지를 보려면 sqlglm()을 이용해야 한다.(sqlcpr.h
에 정의)
만약 sqlcode가 0일때 sqlerrmc의 내용을 보면 이전에
수행된 에러 메시지가 남아 있으므로 sqlcode < 0일때만
사용하는 것이 바람직하다.
- sqlerrd : SQL문 수행과 관련된 각종 INTEGER정보들
sqlerrd[0], sqlerrd[1], sqlerrd[3], sqlerrd[5]
: 현재 사용하고 있지 않음
sqlerrd[2] : 처리된 row수. cascade를 처리된 row수는 제외됨.
Array processing을 하는 중에 에러가 발생했다면, 이
변수에는 정상적으로 처리된 row의 수를 return하게
된다.
sqlerrd[4] : SQL문에서 parse error가 발생한 지점. ( 0부터 시작)
- sqlwarn : warning flag. 해당 warning 발생시 W를 set한다.
sqlwarn[0] : warning 발생 여부 set
sqlwarn[1] : character data의 경우truncated 여부 set
indicator변수를 사용하면 원래의 size 확인 가능.
sqlwarn[2] : NULL 값이 group함수에 사용되었는지를 set
sqlwarn[3] : select한 column과 bind한 column의 갯수가 다른
경우 set
sqlwarn[4] : where절이 없는update, delete문 수행 시 set.
where절이 없이 수행된다는 것은 비정상적인 상황
이기 때문에 warning을 한다.
sqlwarn[5]: EXEC SQL CREATE {PROCEDURE/FUNCTION |
PACKAGE|PACKAGE BODY]문 수행시 컴파일 에러
발생시 set
5) WHENEVER문 사용법
디폴트로 컴파일된 프로그램은 오라클 에러나, warning을 무시하고, 가능하다면
프로그램 수행을 계속한다. 비정상적인 동작에 적절한 조치를 취하기 위해 자동
으로 에러나 warning의 발생을 감지하려면 WHENEVER문을 사용하면 된다.
WHENEVER문의 scope rule은 위치에 의해 결정되는 것이지, logical하게
결정되는 것이 아니라는 점을 주의해야 한다. 그러므로 수행될 SQL 문 이전에 WHENEVER절을 위치하도록 해야 한다. 그리고, 다음 WHENEVER절이 나타나기
이전까지만 효과가 있다.
WHENEVER SQLWARING문을 사용하려면 반드시 SQLCA를 선언해야 한다.
* SYNTAX
EXEC SQL WHENEVER <condition> <action>;
* CONDITION유형
SQLWARNING / SQLERROR / NOT FOUND
* ACTION 유형
- CONTINUE :WHENEVER문을 사용하지 않은 것과 동일한 결과
- DO
- GOTO <label>
- STOP : COMMIT되지 않은 WORK은 모두 ROLLBACK 시킴.
condition과 action을 적절히 혼합하여 사용하면 되는데, 조심해야 할 사항은
WHENEVER SQLERROR GOTO <lable>을 사용할때 무한 loop에 걸리지 않도록 주의
해야 한다. (대신에 WHENEVER SQLERROR CONTINUE를 사용하는 것이 좋다.)
다음은 WHENEVER ...... DO 구문을 사용한 간단한 예제이다.
EXEC SQL WHENEVER SQLERROR DO handle_insert_error(*Insert Error*);
EXEC SQL INSERT INTO emp (empno, ename,deptno)
VALUES (:v_empno, :v_ename, :v_deptno);
EXEC SQL WHENEVER SQLERROR DO handle_delete_error(*delete Error*);
handle_insert_error(char *stmt)
switch(sqlca.sqlcode)
{ case -1 : /*duplicate l\key value */
break;
case -1401 : /*value too large*/
break;
default : /*do somthing here too*/
break;
handle_delete_error(char *stmt)
printf("%s\n\n", stmt);
if ( sqlca.sqlerrd[2] == 0 )
{ /* no rows deleted */
else
}Given the ECPGget_sqlca call, it looks like you're using code generated by Postgres' ECPG precompiler rather than code generated by Pro*C. Add oname=sessiondb.c to your proc command-line and make sure you're compiling the proper code.
Maybe you are looking for
-
HT2534 How do I change my us iTunes account to a Canadian account?
How do I change my US iTunes account to a Canadian account?
-
IPad mini: unable to determine location.
Just got an iPad mini wifi 16 gig. LOVE IT! But for some reason it's unable to determine my location in ANY location based app (including apple maps). I've made sure that I have location services turned on. Any one have an idea of what the deal is?
-
Differences between trigger and Integrity Constraints
waht are the differences between trigger and Integrity Constraints
-
User and product category responsible
Is there any way to findout which product category he is responsible. Any Function module? Input - Product category Out put- List of Users(ie responsible for product category). BR Raman
-
dear anyone, i have prepared a project of resource management system..which is standalone. now i want to make it client server based. can anyone tell me the code for this. can anyone please help me. the project uses java windowing frames thanking in