PowerBuilder 10 으로 Migration 하기
발췌 : http://eas.penta.co.kr/pbnews/0503/PB10Migration.htm
기존에 쓰던 파워빌더에서, OS 의 지원 및 DataBase의 지원여부 또는 기존에 쓰는 것보다 상위버전의 파워빌더에서 지원하는 기술을 쓰고 싶은 이유에서 Migration 을 하게 된다.
대체적으로 마이그레이션시 중요한 틀로 보는 것은 파워빌더 7 이전의 버전과 파워빌더 8 이후의 버전으로 나눠서 생각하게 된다.
1. 마이그레이션 하기 전에 고려해야 할 사항들
1) 예약어 처리
파워빌더 8.0 부터 exception handling을 위해 새로운 예약어들이 PowerScript 에 추가 되었다. 만약 현재 어플리케이션에서 (TRY, CATCH, FINALLY, THROW, and THROWS)과 같은 예약어를 사용했다면 , 그들의 이름을 미리 바꾸어서, 충돌이 나지 않는 이름을 주어야 한다. New dialog box 에 Tool tab page에 있는 Migration Assistant 을 실행해서 새로운 예약어 들의 사용된 위치를 알 수 있다.
2) Transport object 의 폐지
Transport object 와 그것과 관련된 properties 와 method들은 파워빌더 8.0 에서 쇠퇴 되었고, 파워빌더 9.0 이후에서는 더 이상 사용되지 않는다. 원래 이 객체는 PowerBuilder application의 분산을 위해 사용되었는데, 파워빌더의 버전이 올라가면서 분산을 위해 새로운 properties 와 methods 들이 추가되면서 다른 함수들에 분산되어 편입되었다. 새로 추가된 함수 및 이벤트 들을 알아보면 다음과 같다.
* Application object 에 ConnectionBegin , ConnectionEnd events 이벤트 추가
* Connection Object 에 RemoteStopConnection, RemoteStopListening 및 GetServerInfo 함수 추가
* proxy objects 를 위한 SetConnect 함수 추가
* Connection object 에 properties 에 ConnectString , Trace 추가
* ConnectionInfo structure
3) SystemError 이벤트의 변화
파워빌더 7.0 이하의 버전에서, error 또는 ExternalException event에 의해서 잡히지 않은 error 가 발생하면, applicaton의 SystemError event은 즉시 트리거 된다. 만약 SystemError event 와 관련이 있는 코드가 없다면 그 application 은 종료되어진다. 그렇지 않으면, SystemError event 가 수행된 다음에, error 가 발생되어진 code 에 위치에 control들이 리턴된다
파워빌더 8.0 이후의 버전에서는, exception handling mechanism 이나 Error 나 ExternalException event 에 의해 잡히지 않는 error가 발생 한다면, script 는 종료되고, 호출되어진 stack 이 풀린다. 만약 error 가 script에서 Triggerevent call 이 일어나면, script terminate가 호출되어지고, 호출되어진 stack 이 풀린다. 대부분의 경우, SystemError event 는 stack 이 비어지기 전까지 트리거 되어 지지 않는다. 만약 response window의 event 가 Error나 trigger 되어진 SystemError event 의 원인이 된다면 response window event까지 곧 완성한다. 이와 같은 행동에 변화때문에, error에 원인이 되는 문장의 code 는 SystemError event가 제거된 후에 실행되어 지지않고, 그것은 전에 실행되어진다.
이와 같은 변화는 이전 버전에서의 script 에 error가 발생한 control 들에 application 에 큰 영향을 준다. 이와 같은 Code 는 파워빌더 8.0 이나 그 이후에 작성되어진 것에 의존 된다. 전체 code에서 execution error가 발생 할 때, trigger 됨으로써 SystemError event를 try-catch에서 발생되는 error의 원인이 되는 방지하는 것에 의하여 잠재적인 error 들을 조정할 수 있다. 이것은 어떠한 uncaught exception도 SystemError event를 통해서 조정할 수 있고, 코드에 받아들일 수 있다. SystemError event 가 수행되어진 후에 계속 어플리케이션이 실행 되도록 허용할 수 없다. SystemError event 는 어플리케이션을 멈추고 말끔하게 한다.
4) IsValid 함수의 변화
파워빌더 7.0 이하 버전에서는, invalid object 에 IsValid 를 넘겨 주어서 system error가 발생되었으나, 파워빌더 8.0 이상의 버전에서는, Any type의 argument가넘겨지면 Power Object로 바뀌질 수 없고 false 를 리턴 한다.
5) Nested reports 안의 DataWindow objects 들의 이름을 바꿔라.
PowerBuilder 7 이후 버전에서는, DataWindow object 에 모든 object 들은 반드시 이름을 가지고 있어야 하며, Migration 동안 이름을 가지고 있지 않은 object 들은 user-definable prefix settings 에 되어있는 것을 기준으로 이름이 지어지고, 보통 dw_1, dw_2 등등으로 되어 진다. 이러한 이름들은, DataWindow painter 에 있는 Design>Options 에 있는 Prefixes Tab 에 설정되어 있는 것으로 나타내어진다. 이름은 순차적으로 지어지고, 따라서 object 는 DataWindow object 에 다른 object 에 의해 이미 지어져 있는 것들이다. 하지만, 이것은 뜻하지 않는 행동의 이유가 된다. 예를 들어, Dw_2 와 같이 이미 다른 DataWindow object에 사용 되어지고 있는 것들은 Sharedata, GetChild, Retrieve 함수 등 에서, 다른 DataWindow object를 가르키게 된다. 이 문제를 해결하기위해서, 마이그레이션을 하기 전에 DataWindow painter 에 있는 Design>Options 를 선택하고, Prefixes tab에 있는 DataWindow object prefix 되어진 것을 임시적으로 다른 것으로 바꾸면 된다. DataWindow object 들은 migrate 수행 후에 prefix 를 다시 바꾸면 된다.
6) window의 Icons은 반드시 할당되어야 한다.
window 를 포함한 application 에서 할당한 icon은 더 이상 window 에 상속 받지 않는다. application icon 을 사용하려면, 반드시 새로운 AppIcon을 사용해서 migration 후에 window에서 그것을 명시 하면 된다.
7) ListView , TreeView controls events 의 변화
PowerBuilder 7 이후의 버전에서는 Microsoft의 ListView 와 TreeView control 들을 사용한다. 그로 인해, 몇 몇의 event들의 재배치가 필요로 하다. mouse actions을 수행할 때, 이 전 버전과는 다른 방식으로 명령을 해야 한다.
8) DBCS 관련 변화
DBCS 어플리케이션은 DBCS-compatible locale을 포함하는 운영체제에서는 성공적으로 바꿀 수 있다. 그러나 English locale이 작동하는 운영체제에서는 object의 폰트속성이 DBCS문자를 지원하지 않을 경우, DBCS문자들이 깨져서 나타나게 된다. 이 문제를 해결하기 위해서는 변환 후에 그 폰트를 Tahoma로 바꾸어 줘야한다.
9) Unicode 관련 변화
파워빌더 10은 유니코드를 사용할 수 있게 되었다. 파워빌더 10에서 PBL의 소스코드는 ‘UTF-16LE’로 인코딩 되어있다. UTF-16LE는 little-endian format 안의 바이트 순서처럼 UTF-16 code unit 순서가 나열된 Unicode encoding scheme 이다. 또한, multiple-byte numerical values는 the least significant byte first와 함께 저장되어져 있다.
파워빌더 이전버전에서 마이그레이션된 PBL은 ANSI 나 DBCS의 소스코드를 포함하고 있다. 어플리케이션을 파워빌더 10버전으로 바꿀 때는 우선 이전버전으로 되어있는 각 PBL을 파워빌더10으로 마이그레이션 한 후, ANSI나 DBCS의 소스코드를 유니코드로 전환시키고, ‘full build’를 실행시킨다.
2. 파워빌더 7 버전 이하 버전으로부터 의 Migration
먼저, 파워빌더 7 버전 이하 에서 (pbl 단위로 시작되었던 의 프로그램) 파워빌더 8.0 이상으로 마이그레이션 할 경우의 주의 사항 및 방법에 대하여 알아보자.
이전 버전의 파워빌더를 사용하여 만들어진 PBL 들은, PowerBuilder 9.0으로 migrate 해야 한다. 항상 migrate 하기 전에 PBL 들을 항상 Back up 해야 한다. PowerBuilder 7 이하의 버전으로 만들어진 어플리케이션에서 workspace 로 Target을 추가하기 위해서는 Target page of the New dialog box의 Existing Application Target wizard를 사용한다.
마법사를 끝낸 후에, Migrate Application dialog box 가 열려지고, application 을 선택해서, PowerBuilder 9.0로 migrate 한다
개발의 시작점이 Workspace 로 올라갔으므로, Workspace 를 만들어야 한다.
의 시작점이 Workspace 로 올라갔으므로, Workspace 를 만들어야 한다.
migration 할 PBL 에 문법적으로 변화가 생기는 것이 어떠한 것인지 미리 알아보기 위해서 메뉴바 Files>New 에서 Tool 탭에 Migration Assistant를 실행시켜보도록 하자.
Migration Assistant 를 실행시키면 다음과 같은 화면을 볼 수 있을 것이다. 해당 PBL에 Obsolete Syntax 를 미리 조사하는 Obsolete Syntax 를 선택하거나, PowerScript 에서 새로 생겨난 것이나, 사라진 것이나, 추후의 파워빌더의 버전에서는 지원되지 않을 함수나 이벤트들에 대한 것을 조사하려면, PowerScript New, Obsolete or Removed Syntax, .text 파일로 되어진 결과를 조사하려면 Syntax in Custom File 을 선택하면 된다. 대부분 여기에서는 PowerScript New, Obsolete or Removed Syntax를 선택한다.
어떠한 버전에 대해서 체크 할 것인지 체크한다. 모든 버전을 체크하도록 하자.
체크할 PBL 을 선택한다. 선택하면, 오른쪽 부분에 선택한 pbl 이 표시된다.
PBL 을 선택한 후 Next 버튼을 눌러서 다음단계로 가고, Finish 를 누르면 파워빌더 자체적으로 조사를 하게 되고, 조사한 Report 결과를 다음과 같이 출력한다.
문법적으로 틀릴 것이 없다면 마이그레이션을 진행하도록 하고, 발견 된 경우에는 마이그레이션 하기 전의 파워빌더에서 해당 스크립트를 수정한 후, 마이그레이션을 진행하도록 하자. Workspace 는 기존에 생성했으니, PBL 을 붙이기 위해서는 Target 이 필요로 하다. 메뉴바 Files>New 에서 Target 탭에서 Existing Application 을 선택하자.
Workspace 에 붙이고자 하는 Pbl 에 Application Object 를 선택하자.
Library Search Path 를 설정 할 수 있다. 이번 예제는 pbl 이 하나이므로, Next 버튼을 누르자.
Workspace 에 PBL 을 붙이기 위해서는 Target 이 필요로 하다. Target 이 생성되는 위치 및 이름을 설정할 수 있다.
마이그레이션 할 Pbl 의 리스트 이다. 만약 하나의 Target 에 더 많은 pbl 을 마이그레이션 하고 싶다면, Browse 버튼을 선택해서, 원하는 pbl 들을 모두 선택하고 OK 버튼을 클릭한다.
마이그레이션이 성공적으로 마쳐졌으며, System Tree 창에 Workspace, Target 이 생성되었고, 그 밑에 pbl 이 붙게 되었다.
3. 파워빌더 8 이상의 버전으로부터 의 Migration
파워빌더 8 이상에서 (Workspace 와 Target 이 존재하는 경우) 파워빌더 10 로 마이그레이션 할 경우를 알아보자.
파워빌더 8 이상의 버전으로 작성된 Workspace 를 열면 다음과 같은 화면을 보게 된다.
기존의 Target 안에 있는 pbl 들은 자동으로 경로를 가지고 와서 연결이 되어있는데 , 이것 이외에, Target에 쓰이는 다른 library 가 있다면, Browse 버튼을 눌러서 그 library 가 존재하는 경로로 찾아가서 선택하면 된다.
하단부의 DBCS(Double-Byte Charter Set)를 Check 하는 옵션은 String 조작에 관련된 함수, 예를 들어, 파워빌더 9 이하의 버전에서는 Len, Mid, Pos 같은 String 에서의 Byte 형의 숫자를 Return 되고, Argument 로 Byte 형 숫자가 사용되어 졌는데, 파워빌더 10 부터는 Character 형의 숫자로 모두 바뀌게 되었다. 이 체크를 하게되면 자동으로 변환이 되어 지게 되는 것이다. 그러나, 파워빌더가 SBCS(Single-Byte Character Set) 환경에서 동작한다면, 이 체크를 하지 말아야 한다.
원하는 것을 선택하고 OK 버튼을 누르면 변환과정이 자동으로 진행되어지게 된다.
위의 그림과 같이 Output 창의 제일 하단부에는 ‘ Finished Migrate of target window_type’ 이라고 나타나고, Error 가 발생하지 않았다.
이것은 성공적으로 Migration 이 이루어 진 것이다.
4. Migration 시 발생되는 문제점
마이그레이션을 할 때, 여러분들이 당면할 수 있는 에러에 대하여 살펴보고, 그에 대한 해결책을 알아보자.
1) 마이그레이션시, 접하게 되는 문구
Error
-> 마이그레이션을 할 때, Error 가 발생된 경우이다. Error 가 발생되는 이유는 크게, 마이그레이션 도중에 내부적으로 소스가 깨져서 발생되는 문제와 이전 버전에서는 문제 없이 넘어 갔던, 문제 있던 구문들이 파워빌더 버전이 올라가면서Complier 가 강화되면서, 구문 에러를 내는 경우 이렇게 두 가지 경우이다.
Warning
-> 경고는 무시해도 좋으나, 가급적이면 고쳐주는 것이 좋다.
Information
-> 대부분 동일한 이름의 객체가 중복해서 존재할 때 발생한다.
Obsolete
-> 이 메시지는 추후의 파워빌더의 버전에서는 지원되지 않을 함수나 이벤트들에 대한 경고 메시지이다. 이번 버전까지는 그냥 넘어가도 상관없지만, 다음버전으로 마이그레이션을 하면, Error 로 뜨게 될 것이다. Obsolete 메시지 뒤에 어떠한 함수로 바꾸면 좋을 것이라는 말이 나오므로, 나온 대로 이행하는게 좋다.
2) 에러 메시지의 의미
마이그레이션 과정에서 에러메세지가 나타났을 때, 당황해 할 필요 없다. 이런 에러메세지의 의미를 몇 가지 알아보도록 하자.
[mig.pbl(w_frame).dw_con.11: Error C0031: Syntax error]
위의 에러 메시지를 분석하면 mig.pbl 파일의 w_frame 이라는 윈도우 오브젝트의 dw_con 의 선언부의 11번째 줄에 에러코드가 C0031인 Syntax error가 발생했다. 라는 뜻이다.
'C0031' 은 'Syntax error' 를 의미하는 에러코드 이며, 여기서 에러가 발생되는 w_frame 윈도우를 Edit Source 로 보면 'type dw_con from datawindow ...'
이런 형태의 dw_con 선언부가 있는데, 그 중 11번째 줄에서 오류가 발생한 것이다.
Warning : Instance variables of local structure type ('ws_customer') will be implicitly private in the next release
Instance로 선언 시 Default가 Public으로 선언이 된다. 해당 Structure는 해당 Object에서만 사용할 것 이니 Private로 선언해서 사용하라는 메시지 이다.
선언시에 Private를 붙여주면 문제가 해결 됨으로, 선언 부분을 찾아서 앞에 private를 선언 하면 된다.
3) 많이 발생되는 에러
가) Unknown function name , Undefine Variable name , Illegal data type
PBL 은 오브젝트의 소스코드와 컴파일된 바이너리 코드로 구성이 된다. 마이그레이션 시에 소스가 내부적으로 깨져서 2개의 파일 정보가 일치 하지 않아서 해당 함수 또는 변수, 데이터 타입을 인식하지 못하는 경우이다. 이러한 경우는 해당 앞이나 뒤에 space bar 한 칸(공란)을 주고 다시 저장하면 된다.
나) EditMask Contol
Unclosed quoted string 이란 메시지와 Syntax error 메시지가 출력 되게 된다.
일반적으로 파워빌더 7 버전 미만에서 파워빌더 8 이상으로 마이그레이션 할 때, 가장 많이 발생하는 문제는 EditMask Control 이 깨져서 발생된다.
윈도우에서 다음와 같은 에러 메시지가 발생하는 경우 아래에서 제시한 방법대로 고치면 문제가 해결된다.
에러문구에서 제시하는 오브젝트를 System Tree 상황에서 해당 객체에서 오른쪽 마우스를 하고, Edit Source 로 보면, 아래의 그림과 같이 EditMask의 속성 중DisplayData =”? (?)로 표시되는 부분이 있다.
? 를 특수문자로 인식하여 ?뒤의 소스가 다 사라짐. 이전 버전의 소스에서 해당 부분의 뒤에 붙이고, DisplayData=”” 형태로 수정한 후 저장을 하면, 해당 문제가 해결된다.
다) SetNull 관련 에러
The argument to SetNull cannot be an autoinstantiate or structure
위와 같은 메시지를 나타낸다.
파워빌더 6.0 이상부터 는 배열을 초기화 할 때 setnull()을 사용할 수 없다.
배열을 초기화 시키기 위해서는
string sNewArray[], sNullArray[]
sNewArray = sNullArray
위와 같이 아무런 값도 갖질 않는 변수를 대입해서 초기화하면 된다.
라) Any Type
파워빌더 9.0 부터는 파워오브젝트의 프로퍼티나 함수를 Any type변수에 사용할 수 없다. 따라서 기존에 만약 변수를 Any 로 할당 했다면, 해당 오브젝트로 변수를 주면 된다.
예)
any ga_btn 으로 선언 한 것을 button ga_btn 로 바꾸면 된다.
마) Size Change 문제
윈도우의 크기는 일관성있는 개발과 다른 디스플레이 설정을 가진 시스템을 지원하기 위해 계산되어 변하게 된다 특히, 파워빌더 5나 6 버전에서 파워빌더 9 이나 파워빌더 10으로 올라가게 될 때, 크기의 변화는 고려해야 할 사항 중 하나이다. 마이그레이션을 하면, 화면의 사이즈가 변화가 일어나는 경우가 있다. 폰트 크기 및 Window Control Object 의 크기, Window 의 크기 , Data Object 의 크기등이 변하는 경우가 있다. 이유는 파워빌더에서의 모든 객체들은 OS 에 의존적인 크기를 가지고 있는데, OS 자체의 환경의 주종을 이루는 XP 나 2000 으로 바꿔지면서 나타나게 된다. 그중 윈도우의 크기는 타이틀 바, 스크롤 바, 보더와 같은 다양한 플렛폼들의 구성요소들로 나타나게 된다. 예를 들면, 윈도우 XP 스타일로 보여주는 윈도우 XP 기반에서의 active 타이틀바와 inactive 타이틀바 크기는 25이지만, 윈도우 클래식 스타일의 XP 와 2000 기반에서의 타이틀 바 크기는 18이다. 사용자는 이 설정 값을 윈도우 컨트롤 패널에 있는 프러퍼티 다이얼로그 창의 탭 페이지에서 조정할 수 있다. 또한, Data Object 같은 경우는 아래의 그림 7 과 같이 마이그레이션을 하기 전에 Propeties 창에서 Units 를 Centimeter 로 해놓고 한다면, 마이그레이션 이후의 사이즈의 변화가 일어 나지 않을 것이다.
아) Duplicate variable
해당 변수를 여러 번 선언해서 발생되는 문제로, 파워빌더 8.0에서는 발생하지 않았지만, Compiler 의 강화로 Error 가 발생되며, Edit Source로 해당 오브젝트를 수정한 후 저장하면 된다.
4) 그 밖의 주의 사항
가) 복잡한 Stored Procedure
많은 양의 Query를 포함하는 Stored Procedure를 사용했을 경우 ‘ORA-00936: 식이 없습니다’ 또는 ‘SQL 명령어가 불완전 합니다’ 등의 에러가 발생된다.
파워빌더 10 버전이 PBDBMS를 이용한 SQL Query문을 최대 60라인 까지만 인식하는 문제로써, 해당 오류가 발생하는 SQL 문을 60라인 이내로 줄여서 해결해야 한다. 한 라인에 입력 가능한 컬럼은 250 까지이다.
나) Return expression in subroutine
subrutine으로 선언 하고 return value를 준 곳이 있다라는 것이다. 해당 오브젝트를 source edit 로 열고 해당 함수를 주석 처리한 후, 페인터로 들어가 고치시면 된다.
다) scanning object source entry: w_test
w_test 객체를 찾을 수 없다는 에러다. 만약 해당 오브젝트가 있다면 Regenerate 하고, 다시 저장하면 된다.
라) Internal overflow, script is too large
해당 메시지는 스크립트의 사이즈가 클 때 발생을 하는 메시지이다.
파워빌더 5.0 이하의 프로그램에서는 컴파일러 상에서 잡지 못하는 것인데, 파워빌더 6.0 이상으로 마이그레이션 할 때 너무 비대해져서 문제가 되는 것이다.
이러한 경우는 해당 스크립트를 따로 Function으로 빼시거나 상속을 받아 사용해야한다.
마) conversion failed. Probable library file I/O error
해당 PBL 파일을 Optimize 후 다시 Full Build 한 후, 해당 PBL 파일이 위치한 디스크 영역에 오류가 또는 해당 PBL이 읽기 전용 파일인지 확인하면 된다.
이전 소스를 Export 해서 워드패드에서 보면 특수문자가 들어가있는 것을 확인할수 있을 것이다. 특수문자뒤의 Source는 다 없어지는 현상이 나타난다. 이 외에도 특수문자 중 @ 만나도 같은 현상이 나타나기 때문에, 원본 Source를 수정 후 다시 마이그레이션 작업해야한다. 만약 그 후에도 문제가 계속 발생이 되면, 물리적인 HDD 디스크의 문제일 가능성이 높으므로, 윈도우 디스크검사를 수행해 문제가 없는지 확인하면 된다.
바) Unresolved resource 'c:\pic\bmp\exit.bmp' Referenced from object 'w_exit'
위의 위치경로에 해당 그림이 존재 하지 않는 경우로써, PBR(PowerBuilder Resource File)에는 이러한 경로를 주었을 때 발생됩니다. 해당 경로에 맞는 그림을 넣던가, PBR의 내용을 바꿔야 한다.
사) SQLSTATE = 37000
SQL 컬럼갯수가 많은 경우(약 40개 이상)에 프로그램 개발 및 실행시에 모두 에러가 발생한다. 이러한 경우는 Database 연결 시 DisableBind = 1 옵션을 추가하면된다.
아)select error: ora-00907: 누락된 우괄호 에러
주석이 문제를 발생 시키는 것이며, 주석 내에서도 ":" 이 문제이다.
예를 들어 주석이 다음과 같다고 할 때
aa : bbb
":" 뒤에 있는 "bbb"를 Retrieval Argument로 인식하는 것이 문제이다.
따라서 주석에서 ":" 을 다른 문자로 바꾸면 된다.
