Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: '마이그레이션'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. 델파이 7에서 11.0으로 마이그레이션하고 있습니다. 델파이 7에서 문제없던 아래 코드가 11.0에서 오류가 납니다. shortdateformat := 'yy/mm/dd'; dateseparator := '/'; 오류메시지 [dcc32 Error] : E2003 Undeclared identifier: 'shortdateformat' 어떻게 해소할 수 있을까요?
  2. 이 문서의 목적: DocWiki에 있는 [DocWiki 번역] BDE 애플리케이션 마이그레이션 따라하기 (FireDAC) 문서가 실제로 따라하기에 다소 불편하게 되어 있어서, 내용과 틀을 유지하면서, 따라하기 쉽게 보강함 중요! 미리 알아둘 점: BDE 애플리케이션을 FireDAC으로 이전하는 방법에는 "BDE에서 FireDAC으로 이전" 관련 사항이 잘 정리되어 있다. 이 실습의 "1~8 단계"는 [DocWiki 번역] BDE 애플리케이션 마이그레이션 따라하기 (FireDAC) 의 1~ 8단계와 일치 비교해 보기 쉽다 이 실습의 "9단계" (윈도우 11 스타일 적용하기)는 이글에만 있다. (사용자는 좋은 화면을 훨씬 높게 평가하는 경향이 있다) 이 실습을 따라가는 도중에 에러 메시지를 만날 수 있다. 해당 설명에 설명되어 있지 않다면, "예상되는 오류와 처리"에 있는 설명을 통해 해소하자. (그래도 해소되지 않으면, 답글을 남겨서 다른 개발자의 도움을 받기 바란다) 이 글의 기대 효과: RAD 스튜디오 설치 시 함께 제공되는 reFind와 변환 규칙 파일(FireDAC_Migrate_BDE.txt)을 통한 자동 변환 방법 학습 아래의 마이그레이션 방법을 직접 경험 데이터 액세스 기술: BDE에서 FireDAC으로 데이터베이스: 파라독스에서 인터베이스(InterBase)로 사용자 화면(UI): 윈도우 95 에서 윈도우 11 화면 스타일로 델파이 버전: 구버전에서 최신 버전으로 목차 1단계. 실습에서 사용할 구버전 소스 파일을 복사하여 프로젝트 준비 2단계. 코드 자동 변환: reFind를 사용하여BDE 컴포넌트를 FireDAC으로 변환 3단계. FireDAC에서 사용할 데이터베이스 연결 정의 생성 4단계. FireDAC의 필수 컴포넌트 추가: DBMS에 맞는 드라이버와 Wait 커서 5단계. FireDAC.FDConnection에 연결 설정 6단계. 데이터베이스 타입 맵핑 변경 7단계. 불필요한 코드 제거: 파라독스 관련 코드 8단계. 인터베이스에 맞게 관련 코드 정비 9단계. 윈도우 11 스타일 적용 예상되는 오류와 처리 방법 [FireDAC][Comp][Clnt]-340. Driver ID is not defined. Set TFDConnection.DriverName or add DriverID to your connection definition The EditUpdateError method referenced by Parts.OnupdateError has an incompatible parameter list. Remove the reference? [dcc32 Fatal Error] EDOrders.pas(21): F2613 Unit 'DBLookup' not found. Project mastapp.exe raised exception class EIniFileException with message 'Unable to write to RPTSMITH.CON' [Break] Project mastapp.exe raised exception class EIBNativeException with message '[FireDAC][Phys][IB]Dynamic SQL ErrorSQL error code = -206Column unknownA.FULLNAME'. [FireDAC][Phys][IB] Unable to complete network request host "127.0.0.1/3050". Failed to establish a connection. 참고한 자료 1단계. 실습에서 사용할 구버전 소스 파일을 복사하여 프로젝트 준비 RAD 스튜디오를 설치하면, 이 실습에서 사용할 BDE를 사용하는 소스 전체가 아래 경로에 있는 Demo 폴더에 있다. C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\Object Pascal\Database\FireDAC\Tool\reFind\BDE2FDMigration 위 경로 중 \22.0\은 RAD 스튜디오 11.0 인 경우임. 이 숫자는 버전에 따라 달라짐. 그림. RAD 스튜디오에서 reFind 용으로 제공하는 Sample 파일의 기본 경로와 해당 파일 원본을 손상시키지 않고, 한 곳에 작업할 모든 내용을 모아두기 위해 다음과 같이 한다. [진행 절차] 원하는 곳에 원하는 이름 (예: "My_FireDAC_2_BDE")으로 새 폴더를 만든다. 앞으로 모든 작업 파일은 이 새 폴더에 두기로 한다. 위에서 안내한 Sample 폴더 안에 있는 Demo 폴더와 FireDAC_Migrate_BDE.txt 파일을 복사하여, 방금 새로 만든 "My_FireDAC_2_BDE" 폴더 안에 붙여넣는다. 복사해 넣은 폴더와 파일의 이름을 바꾼다. Demo (폴더) --> My_FireDAC_MastApp (FireDAC을 사용하는 MastApp 프로젝트의 폴더이며 여기의 코드가 변경된다) FireDAC_Migrate_BDE.txt (파일) --> My_FireDAC_Migrate_BDE.txt (이 파일도 조금 수정할 것이다) 2단계. 코드 자동 변환: reFind를 사용하여BDE 컴포넌트를 FireDAC으로 변환 1단계에서 복사한 FireDAC_Migrate_BDE.txt 파일에는 BDE를 FireDAC으로 변환하는 규칙이 정의되어 있다. 아래와 같이 변환 규칙 파일과 reFind(코드의 텍스트 자동 변환 도구)를 사용하면, 코드에 있는 BDE 컴포넌트(와 해당 프로퍼티)가 모두 해당 FireDAC 컴포넌트(와 해당 프로퍼티)로 변경된다. 명령창에서 직접 입력하는 방식으로 reFind를 실행하면 되지만, 타이핑할 내용을 .bat 파일로 만들어서 명령을 실행하는 것이 더 편하고 간단하므로 이 방식으로 설명한다. [진행 절차] "My_FireDAC_2_BDE" 폴더 안에서 마우스 오른쪽 클릭 > 새로 만들기 > 텍스트 문서를 선택한다. "새 텍스트 문서.txt"가 만들어지면 파일 명을 "Run_FireDAC_Migrate_BDE.bat"로 변경한다. (주의! 파일 확장자도 .txt가 아니라 .bat가 되어야 한다 메모장을 열고, 방금 만든 "Run_FireDAC_Migrate_BDE.bat" 파일을 메모장으로 드래그 드롭하여 파일 내용을 연다 (아직은 아무 내용도 없다) 이 파일에 아래 내용을 넣고 저장한다. (내용을 이해하고 싶으면 reFind 설명을 참고) refind My_FireDAC_MastApp\*.pas My_FireDAC_MastApp\*.dfm /X:My_FireDAC_Migrate_BDE.txt pause 방금 만든 "Run_FireDAC_Migrate_BDE.bat" 파일을 더블 클릭하여 이 배치파일을 실행한다. 실행한 결과가 아래 그림과 같으면, 아무 키나 눌러서 명령창을 닫는다. 그림. Run_FireDAC_Migrate_BDE.bat 이 실행된 결과 화면 3단계. FireDAC에서 사용할 데이터베이스 연결 정의 생성 FireDAC에서 사용할 연결 정의를 생성해야 한다. 이 예제에서는 'FireDAC Explorer'를 사용하기로 한다. [진행 절차] RAD 스튜디오에서 메인 메뉴 > Tools > FireDAC Explorer를 클릭한다. FireDAC Explorer 창에서 메인 메뉴 > File > New > Connection Definition Ctrl+C를 클릭한다. FireDAC Explorer 창의 왼쪽에 있는 Object Explorer 트리뷰에 "ConnectionDef1"이라는 새 연결 정의가 생기고, 타이핑하면 바로 이름을 바꿀 수 있도록 이름이 선택된 상태일 텐데, "MASTSQL"이라고 타이핑하여 이 연결 정의의 이름을 지정한다. FireDAC Explorer 창의 오른쪽 그리드에서는 방금 만든 "MASTSQL" 연결 정의의 프로퍼티를 설정할 수 있다. 연결 정의 파라미터를 아래와 같이 지정한다. DriverID=IB Protocol=TCPIP Server=127.0.0.1 DataBase=C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\Data\MASTSQL.GDB *(아래 "주의 " 참조) User_Name=sysdba SQLDialect=3 CharacterSet=UTF8 ExtendedMetadata=True FireDAC Explorer 창에서 메인 메뉴 > Edit > Apply를 클릭하여 저장한다. RAD 스튜디오를 종료하고 다시 시작한다. (그래야 새로 만든 연결 정의가 반영된다) 그림. FireDAC Explorer를 열고, 인터베이스 데이터 연결을 정의 *주의: 이 예제에서 사용된 소스는 데스트탑 데이터베이스인 파라독스(Paradox)를 사용하고 있었다. 위에 있는 "MASTSQL" 연결 정의의 파라미터 중 DataBase에 그 데이터 파일인 MASTSQL.GDB의 전체 경로를 지정하고 있는데, 이 파일은 해당 파라독스(Paradox)를 엠바카데로에서인터베이스로 이미 전환해 놓은 데이터 파일이다. RAD 스튜디오 11.0를 Sample 까지 모두 설치했다면 위의 전체 경로를 보면 MASTSQL.GDB 파일이 있을 것이다 (설치한 RAD 스튜디오 버전이 다르다면, 경로 중간의 /22.0/ 대신 다른 숫자로 되어 있을 것이다) 참고로, 파라독스의 데이터를 인터베이스로 옮길 때는 Clever Components InterBase DataPump를 사용할 수 있다. 4단계. FireDAC의 필수 컴포넌트 추가: DBMS에 맞는 드라이버와 Wait 커서 Docwiki 원문의 4단계에서는 변환한 소스가 있는 폴더에서 프로젝트 파일인 "mastapp.dproj" 를 두 번 클릭하여 프로젝트 파일을 열고 uses 에 FireDAC.Phys.IB, FireDAC.VCLUI.Wait 를 추가하라고 되어 있다. 원문의 안내 대로 진행해도 좋지만, 이 4단계를 생략해도 된다. RAD 스튜디오(델파이, C++빌더) 11.0 버전에서는 컴파일 할 때 프로젝트에서 사용하고 있는 데이터베이스 (이 예제에서는 인터베이스)를 감지하여 자동으로 uses에 FireDAC.Phys.IB 유닛과 FireDAC.VCLUI.Wait 유닛을 추가하고 해당 드라이버를 반영하기 때문이다. 게다가 이 유닛들은 프로젝트 소스가 아니어도, 메인 폼이나 데이터 모듈이어도 상관없다. 5단계. FireDAC.FDConnection에 연결 설정 Docwiki 원문의 5단계에서는 DataMod.dfm (데이터 모듈의 폼파일)을 열고, 폼 파일 코드에서 TFDConnection 컴포넌트를 찾아서 연결 정의를 타이핑하여 넣으라고 되어 있다. 원문의 안내 대로 진행해도 좋지만, 아래 방법이 보다 쉽고 정확하다. [진행 절차] RAD 스튜디오 오른쪽의 프로젝트 관리자에서 DataMod.pas를 더블 클릭하여 연다. (오류 처리 방법 보기) 코드 에디터가 열리고, 해당 소스 코드가 보이면, 화면을 폼 디자이너로 바꾼다 (코드 에디터에서 폼 디자이너로 화면을 바꾸는 방법: 코드 에디터 화면의 맨 아래 오른쪽에 있는 탭에 Code가 선택되어 있을 것이다. 그 옆에 있는 Design 탭을 선택 또는 단축키 F12 사용). 폼 디자이너에는 DataMod의 컴포넌트들이 보일 텐데, 2단계를 통해서 이미 FireDAC 컴포넌트로 변환된 것을 알 수 있다. 폼 디자이너에 있는 컴포넌트 중에 "Database" 컴포넌트 (이름이 Database인 FDConnection 컴포넌트)를 한번 클릭하여 선택한다. RAD 스튜디오 왼쪽의 오브젝트 인스펙터에서 ConnectionDefName 프로퍼티를 찾아서, 그 값에 앞의 3단계에서 만든 "MASTSQL" 연결 정의를 선택하여 지정한다. 폼 디자이너에서 "Database" 컴포넌트를 더블 클릭하여 FireDAC Connection Editor 창을 연다. FireDAC Connection Editor 창에서 Test 버튼을 클릭한다. 로그인 창이 나타나오 이미 3단계에서 지정해둔 연결 정보가 들어가 있을 것이다. OK를 클릭한다. ("Connection established successfully" 라는 메시지가 나오면 성공한 것이다. 만약 실패해서 에러 메시지가 표시된다면, password등이 잘못되었다는 오류가 나오면, 앞의 3단계로 돌아가서 연결 정의를 다시 정확히 만들어야 한다. 만약 연결이 거부 된다면, 인터베이스 서버가 동작하는 지를 확인해야 한다 (오류 처리 방법 보기) 6단계. 데이터베이스 타입 맵핑 변경 BDE와 FireDAC은 둘다 애플리케이션과 데이터베이스를 서로 연결해 주기 위해 그 사이에 위치하는 계층이다. 이 계층은 데이터베이스 테이블의 컬럼의 데이터 타입을 FireDAC BDE 또는 FireDAC 의 데이터베이스 클라이언트 드라이버에서 지정한 타입으로 가져오고 나서, 이것을 다시 애플리케이션에서 사용할 타입 전환한다. 이때 BDE와 FireDAC의 타입 맵핑이 조금 다르다. FireDAC의 타입 맵핑에 대한 도움말: [DocWiki 번역] 데이터 타입 맵핑 (FireDAC) 위 도움말에 의하면 오라클 데이터베이스의 NUMBER 타입을 FireDAC의 오라클 클라이언트 드라이버에서는 dtFmtBCD으로 취급한다는 것을 알 수 있다. 이와 달리 BDE에서는 오라클 데이터베이스의 NUMBER 타입을 dtInt32나 dtDouble로 취급한다. BDE에서는 DateTime 타입으로 취급하는 것을 FireDAC에서는 DateTimeStamp 타입으로 취급한다는 점도 다르다. 그런데, 이 예제의 기존 소스는 BDE를 사용했었기 때문에, 앞의 2단계에서 BDE 컴포넌트를 모두 FireDAC 컴포넌트로 변경하였다고 해도, 개발자가 작성한 코드는 BDE에서 다루는 데이터 타입에 맞춰져 있을 것이다. 예를 들어, 개발자가 영속 필드를 넣었다면, 이 필드들은 기존에 BDE에서 설정한 데이터 타입을 받도록 되어 있으므로, FireDAC과 BDE에서 서로 다르게 취급하는 데이터타입을 다룰 수 없다. 다행히 FireDAC에는 이런 문제를 유연하게 처리할 수 있도록 데이터 타입 맵핑 규칙을 개발자가 지정할 수 있도록 되어 있다. 우리는 이 단계에서, FireDAC의 유연한 데이터 맵핑을 이용하여, FireDAC의 인터베이스 클라이언트 드라이버에서 지정한 디펄트 데이터의 타입이 기존에 BDE에서 처리하던 타입으로 처리되도록 맵핑 규칙을 넣기로 한다. (참고! 이 맵핑 규칙을 넣지 않아도 된다. 하지만, 그 대신, 애플리케이션에서 기존의 BDE 데이터 타입을 다루게 되어 있는 것을 모두 찾아서 FireDAC 데이터 타입을 다루도록 바꿔야 한다. 예를 들면 모든 영속 필드를 찾아서 모두 지운 다음 다시 추가하여 FireDAC 타입을 다루는 필드가 되게 해야 한다. 따라서, 맵핑 규칙을 넣는 것이 훨씬 편하고 유연한 방법이다.) 이제 Docwiki 원문의 6단계에서 있는 절차를 진행할 텐데, 원문의 안내대로 코드 에디터를 열어서 변경해도 좋지만, 우리는 FireDAC Connection Editor를 사용하여 보다 쉽게 진행하겠다. [진행 절차] 폼 디자이너에서 "Database" 컴포넌트를 더블 클릭하여 FireDAC Connection Editor 창을 연다. FireDAC Connection Editor 창에서 Options 탭을 클릭한다. Options 탭 내용에서 Format Options 아래 Data Mapping Rules 아래에 있는 Ignore inherited rules를 체크한다. 그리드에서 아래 설정을 한다. SourceDataType = dtFmtBCD TargetDataType = dtInt32 PrecMin = 0 PrecMax = 10 ScaleMin = 0 ScaleMax=0 그리드 바로 아래에 있는 Add Rule을 클릭하고, 그리드에서 아래 설정을 한다. SourceDataType = dtFmtBCD TargetDataType = dtDouble 다시 한번 그리드 바로 아래에 있는 Add Rule을 클릭하고, 그리드에서 아래 설정을 한다. SourceDataType = dtDateTimeStamp TargetDataType = dtDateTime FireDAC Connection Editor 창이 아래 그림과 같이 잘 되었다면 OK를 클릭하여 저장한다. 그림, FireDAC의 데이터 타입 맵핑 설정 마지막으로, 폼 디자이너에서 "Database" 컴포넌트가 선택된 상태에서, RAD 스튜디오 왼쪽의 오브젝트 인스펙터에서 FormatOptions 프로퍼티를 확장하고 , 하위 프로퍼티인 StrTrim를 False로 지정한다. (이 프로퍼티의 값을 BDE의 기본값에 맞추기 위함) 7단계. 불필요한 코드 제거: 파라독스 관련 코드 FireDAC은 파라독스 또는 DBase 같은데스크탑 DB를 지원하지 않는다. 따라서 파라독스 데스크탑 DB 관련된 모든 코드를 애플리케이션에서 제거해야 한다. 이 애플리케이션에서 Local Data를 처리하는 코드를 모두 지우자 (또는 주석 처리 하자). (참고: 원하는 코드 블록을 선택하고 Ctrl+/ 단축키를 누르면 선택된 블록의 모든 줄이 주석처리 된다. 이미 주석인 상태였다면 다시 주석이 풀린다) [진행 절차] 프로젝트 관리자에서 DataMod.pas를 더블 클릭하고, 코드 에디터를 열어서 TMastData.UseLocalData 메서드 삭제 Interface 부분에서 선언 삭제 Implementation 부분에서 구현 삭제 프로젝트 관리자에서 Main.pas를 더블 클릭하고, 코드 에디터를 열어서 TMainForm.ViewLocalClick 핸들러 메서드 삭제 Interface 부분에서 선언 삭제 Implementation 부분에서 구현 삭제 단축키 F12를 눌러서, Main.pas를 연 코드 에디터를 폼 디자이너로 전환한 후 스트럭처 뷰에서 아래 그림과 같이 Mainform - MainMenu - View - Local Data를 선택한 후, 오른쪽 클릭 > Edit > Delete (또는 키보드 Delete 키)를 이용하여 메뉴에서 Local Data를 아예 제거한다. (주의! 경고도 없이 제거되고, 되돌리기 어려우므로, 스크럭처 뷰에서 삭제하려는 오브젝트가 정확히 선택되어 있는 지를 먼저 확인해야 한다) 8단계. 인터베이스에 맞게 관련 코드 정비 이제 데이터베이스를 코드에서도 연결할 때에도 새 인터베이스에 연결 할 수 있도록 코드를 변경한다. [진행 절차] 프로젝트 관리자에서 Main.pas를 더블 클릭하고, 코드 에디터를 열어서 TMainForm.ViewRemoteClick 메서드 변경 (Local Interbase)"라는 문자열을 찾아서 "(InterBase)"로 변경한다. 여전히 Main.pas가 코드 에디터를 열린 상태에서, TMainForm.ViewMenuClick 핸들러 메서드 삭제 Interface 부분에서 선언 삭제 Implementation 부분에서 구현 삭제 단축키 F12를 눌러서, Main.pas를 연 코드 에디터를 폼 디자이너로 전환한 후 스트럭처 뷰에서 아래 그림과 같이 Mainform - MainMenu - View를 선택한 후, 오브젝트 인스펙터에서 Events 탭을 선택하고 OnClick 이벤트에 연결된 "ViewMenuClick"을 지운다. (로컬 데이터와 원격 데이터를 구분하지 않으므로 더이상 필요없다) 프로젝트 관리자에서 DataMod.pas를 더블 클릭하고, 코드 에디터를 열어서 TMastData.DataDirectory 메서드 삭제 Interface 부분에서 선언 삭제 Implementation 부분에서 구현 삭제 여전히 DataMod.pas가 코드 에디터에 열린 상태에서, TMastData.UseRemoteData 메서드의 코드를 아래와 같이 변경한다. procedure TMastData.UseRemoteData; var Params: TStringList; begin { ConnectionDef가 있는지 촥인한다. 없으면, 추가한다 } if not FDManager.IsConnectionDef('MASTSQL') then begin Params := TStringList.create; try Params.Values['Protocol'] := 'TCPIP'; Params.Values['Server'] := '127.0.0.1'; Params.Values['DataBase'] := 'C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\Data\MASTSQL.GDB'; // 실제로 MastApp.GDB (인터베이스 데이터 파일)이 있는 전체 경로 Params.Values['User_Name'] := 'sysdba'; Params.Values['SQLDialect'] := '3'; Params.Values['CharacterSet'] := 'UTF8'; Params.Values['ExtendedMetadata'] := 'True'; FDManager.AddConnectionDef('MASTSQL', 'IB', Params); finally Params.Free; end; end; SetDatabaseAlias('MASTSQL'); //역자주: 원문에는 MastApp.SetDatabaseConnectionDef('MASTSQL');로 잘못 기재되어 있어서 정정함 end; DocWiki에서는 CustByLastInvQuery에 있는 SQL문에서 키워드인 DESCENDING을 DESC 로 변경하라고 되어 있지만, 지금은 DESCENDING 키워드도 작동하므로, 굳이 바꾸지 않아도 된다. DocWiki 원문에는 이 8단계까지만 설명되어 있다. 하지만, 실행하려고 하면 몇가지 오류가 생길 것이다. RAD 스튜디오에서 메인 메뉴 > Run > Run (또는 단축키 F9)를 사용하여 마이그레이션이 완료된 애플리케이션을 빌드하고 실행한다. 아마 컴파일이 실패하거나, 실행 중에 오류가 발생될 것이다. 이 실습 중에 이슈를 만나면 "예상되는 오류와 처리 방법"에 있는 설명을 참고하여 해소하자. 9단계. 윈도우 11 스타일 적용 사용자는 애플리케이션이 바깥으로 보이는 모습에 민감하게 반응하는 경향이 있다. 클릭 몇번으로 애플리케이션의 모습을 현대식 UI로 바꿀 수 있다면, 하지 않을 이유가 없다. 이제 최신 윈도우 11 다크 스타일을 적용하자. [진행 절차] RAD 스튜디오에서 메인 메뉴 > Project> Options를 클릭한다. Project Options 창에서 Application > Appearance를 선택하고 아래 그림과 같이 Custom Styles와 Default Style 모두 "Windows11 Modern Dark"를 선택한다. (만약 이 스타일이 없다면 겟잇 패키지 매니저를 이용하여 받고 나서 진행한다) RAD 스튜디오에서 메인 메뉴 > Run > Run (또는 단축키 F9)를 사용하여 마이그레이션이 완료된 애플리케이션을 빌드하고 실행한다. BDE와 파라독스를 사용하던 델파이 7으로 되어있든 애플리케이션이 이제 FireDAC과 인터베이스 그리고 델파이 11.0 알렉산드리아로 완전히 옮겨졌다. 예상되는 오류와 처리 방법 당연하지만, 프로젝트는 저마다 다르기 때문에 모두에게 적용되는 규칙 만으로 변환 할 수는 없다. 이 예제에서 발생되는 오류와 이것을 방지 또는 해소하는 방법을 적용하자. 마이그레이션 할 때 생기는 오류에 대응하는 경험을 할 수 있다. [FireDAC][Comp][Clnt]-340. Driver ID is not defined. Set TFDConnection.DriverName or add DriverID to your connection definition 의미: TFDConnection에 연결 정의가 지정되지 않았으니 지정하시오. 발생: 이 오류는 5단계의 가장 첫 진행을 하기위해 프로젝트 관리자에서 DataMod.pas 파일을 더블 클릭해서 열려고 할 때 생길 것이다. 이유/조치: 5단계가 바로 연결 설정이므로 5단계를 마치고 나면 해소된다. [진행 절차] 걱정하지 말자. 이 메시지 창이 더이상 나타나지 않을 때가지 X버튼이나 엔터 키를 여러번 눌러서 창을 닫는다. The EditUpdateError method referenced by Parts.OnupdateError has an incompatible parameter list. Remove the reference? The EditUpdateError method referenced by Cust.OnupdateError has an incompatible parameter list. Remove the reference? 처럼 Parts.OnupdateError 대신 Cust.OnupdateError에서도 같은 메시지가 표시될 것이다. 의미: EditUpdateError 메소드는 Parts.OnupdateError (또는 Cust.OnupdateError) 이벤트를 처리하는 핸들러 메소드로 참조되고 있는데, 이벤트에서 전달하는 파라미터 목록이 서로 달라서 작동하지 않으니, Parts.OnupdateError (또는 Cust.OnupdateError) 이벤트에서 EditUpdateError 메소드를 이벤트 핸들러로 참조하지 않도록 제거할까요? 발생: Run > Run (또는 단축키 F9)로 실행할 때 표시될 것이다. 이유/조치: 위 의미에서 설명한 바와 같다. BDE와 FireDAC에서 데이터 업데이트 오류 처리 이벤트는 "OnUpdateError"로 동일하지만, 이 이벤트에서 전달하는 파라미터는 서로 다르기 때문이다. 일단 No (참조를 제거하지 않음)를 선택하여 그대로 남겨둔다. 그리고 파라미터를 일치시키는 작업을 진행한다. 2단계에서 reFind와 변환 규칙 파일(FireDAC_Migrate_BDE.txt)를 통해 자동 변환하였지만, 아래와 같이 완벽하게 변환되지 않았다. 예제에서 BDE를 자동 변환한 결과(파라미터) FireDAC의 기본 파라미터 DataSet: TDataSet; E: EDatabaseError; UpdateKind: TFDUpdateRequest; var UpdateAction: TFDErrorAction ASender: TDataSet; AException: EFDException; ARow: TFDDatSRow; ARequest: TFDUpdateRequest; var AAction: TFDErrorAction 잘 보면, EDatabaseError 타입이 EFDException 타입으로 변환되지 않았다. ARow: TFDDatSRow; 파라미터는 아예 생성되지 않았다 (reFind는 찾아/바꾸기 도구이므로 이런 한계가 있다) 이제 코드에서 이 부분을 수작업으로 수정하자. [진행 절차] 코드 에디터에서 DataMod.pas 파일을 열고 EditUpdateError 이벤드 핸들러 메소드의 파라미터를 아래와 같이 변경한다. [변경 전] (DataSet: TDataSet; E: EDatabaseError; UpdateKind: TFDUpdateRequest; var UpdateAction: TFDErrorAction); [변경 후] (DataSet: TDataSet; E: EFDException; ARow: TFDDatSRow; UpdateKind: TFDUpdateRequest; var UpdateAction: TFDErrorAction); Interface 부분에서 EditUpdateError 선언의 파라미터 부분을 변경 Implementation 부분에서 TMastData.EditUpdateError 구현의 파라미터 부분을 변경 (원한다면, 다시 변환할 때 자동 처리되도록) 변환 규칙 파일을 보강한다. (ARow: TFDDatSRow; 파라미터를 넣는 것은 조금 부담되지만, 적어도 EDatabaseError를 EFDException로 바꾸는 규칙을 넣을 수는 있다) My_FireDAC_Migrate_BDE.txt(변환 규칙 파일)을 열면, 맨 아래에 #migrate 가 모여있다. 그곳에 아래와 같이 한줄 추가하고 저장한다. (찾아서 바꾸라는 규칙) #migrate EDatabaseError -> EFDException [dcc32 Fatal Error] EDOrders.pas(21): F2613 Unit 'DBLookup' not found. 의미: RAD 스튜디오에 'DBLookup' 유닛이 없다. 발생: Run > Run (또는 단축키 F9)로 실행할 때 컴파일이 실패하면서 메시지 창에 표시될 것이다. 이유/조치: FireDAC에서 이 유닛을 사용하지 않기 때문이다. 우리도 uses 절에서 DBLookup을 제거하자. [진행 절차] 오류 메시지 창에서 OK를 클릭하면, 해당 오류가 있는 코드가 열린다. uses 절에 DBLookup에 빨간색 밑줄이 있을 것이다. DBLookup을 지운다. 다시 단축키 F9를 눌러 실행(Run) 한다. 그러면 DBLookup가 uses에서 사용되는 다른 파일이 열리고 마찬가지고 빨간색 밑줄이 보인다. 이 DBLookup 역시 지운다. (원한다면, 다시 변환할 때 자동 처리되도록) 변환 규칙 파일을 보강한다. My_FireDAC_Migrate_BDE.txt(변환 규칙 파일)을 열면, 맨 위에 #unuse 가 모여있다. 그곳에 아래와 같이 한줄 추가하고 저장한다. (uses에서 DBLookup을 제거하라는 규칙) #migrate EDatabaseError -> EFDException Project mastapp.exe raised exception class EIniFileException with message 'Unable to write to RPTSMITH.CON' [Break] 의미: "RPTSMITH.CON"에 쓰기를 할 수 없어서 IniFileException이 발생했다. 발생: 리포팅 도구에서 사용하는 "RPTSMITH.CON" 파일이 쓰기가 금지된 폴더에 있기 때문이다. 이유/조치: "RPTSMITH.CON" 파일의 위치를 쓰기가 허용되는 폴더로 변경한다. [진행 절차] 메시지 창에서 Break 버튼을 클릭하면, 이슈가 발생하는 코드가 표시된다 (아래 코드이다). RSCon.WriteInteger(MASTSQLSection, TypeKey, SQLTypeVal); 이 코드를 잘 보면 TMainForm.UpdateRSConnect 메소드 안에 있을 텐데, 여기에는 "RPTSMITH.CON" 파일의 전체 경로가 상수(const)로 정의 되어 있다. 이 부분을 변경한다. [변경전] procedure TMainForm.UpdateRSConnect(const Dbpath: string); const TiniFilename = 'RPTSMITH.CON'; {ReportSmith connections file} ... [변경후] procedure TMainForm.UpdateRSConnect(const Dbpath: string); const TiniFilename = 'D:\RPTSMITH.CON'; {D 드라이브가 아니어도 쓰기 가능한 위치를 잡으면 된다: ReportSmith connections file} ... Project mastapp.exe raised exception class EIBNativeException with message '[FireDAC][Phys][IB]Dynamic SQL Error SQL error code = -206 Column unknown A.FULLNAME'. 의미: "[FireDAC][Phys][IB]" 드라이버에서 동적 SQL을 실행하는 도중 오류 발생. "A.FULLNAME"이라는 컬럼을 알 수 없음 발생: 리포팅 도구에서 사용하는 "RPTSMITH.CON" 파일이 쓰기가 금지된 폴더에 있기 때문이다. 이유/조치: DataMod.pas 내의 Orders (TFDTable) 컴퍼넌트에는 "SalesPerson"이라는 영속 필드가 있다. 이 필드는 계산되는 필드라서 실제로 필드가 없는데, BDE 방식으로 lookup 찾기를 하려고 해서 오류가 발생한다. 이 필드를 계산 필드로 지정하자. [진행 절차] 폼 디자이너에서 DataMod.pas를 열고, "Orders" 컴포넌트를 찾아서 (아마 가장 위 왼쪽에 있을 것이다) 더블 클릭한다. 필드 에디터에 목록이 표시되면, 맨 밑에 있는 "salesperson" 필드를 한번 클릭하여 선택한다. 오브젝트 인스펙터에서 Properties 탭을 선택하고, FieldKind 프로퍼티를 찾는다. fkLookup이 지정되어 있을 텐데, fkCalculated로 변경한다. [FireDAC][Phys][IB] Unable to complete network request host "127.0.0.1/3050". Failed to establish a connection. 의미: "[FireDAC][Phys][IB]" 드라이버가 대상 컴퓨터에서 연결하려고 했으나, 거부되어서 연결하지 못했다. 발생: 서버가 작동하지 않거나 원격 연결을 거부하면 발생한다. 이유/조치: 로컬 IP이고와 3050은 인터베이스 기본 PORT로 현재 모두 정확하므로, 인터베이스 서버가 동작하고 있는 지를 확인하자. [진행 절차] 윈도우 버튼 (모니터 가장 아래줄의 가장 왼쪽 아이콘) > 시작 > 프로그램 > Embarcadero InterBase [버전] > InterBase Server Manager를 실행한다. InterBase Server Manager 창에서 인터베이스 서버가 Stopped 상태로 표시된다면, Start 버튼을 클릭하여 서버를 시작한다. 참고한 자료 [DocWiki 번역] BDE 애플리케이션 마이그레이션 따라하기 (FireDAC) https://community.embarcadero.com/blogs/entry/delphi-c-builder-bde-japan BDE 애플리케이션을 FireDAC으로 이전하는 방법에는 "BDE에서 FireDAC으로 이전" 관련 사항이 잘 정리되어 있다.
  3. 이 문서의 목적 데브기어 마이그레이션 지원 사업(TODO 링크 넣기)을 통해 진행한 현대화 프로젝트 사례(TODO 링크 넣기)를 기록함으로써, 델파이/C++ 현대화 마이그레이션 (TODO 링크 넣기)을 고려하는 개발자가 참고할 수 있도록 한다. 목차 사용 기관 및 프로젝트 소개 현대화 마이그레이션을 계획하게된 동기 마이그레이션 프로젝트 개요 마이그레이션 프로젝트 진행 단계 주요 작업 (및 참고 자료) 코드 변환 BDE를 FireDAC으로 교체 (64비트 윈도우 지원, 배포 편이성 향상, 데이터 처리 성능 향상) 윈도우 10 스타일 적용 (일관성 있고 세련된 현대식 디자인) 사이드바 메뉴 구현 (사용성 향상) 퀵리포트(Quick Report) 업그레이드 (엑셀 내보내기 등 기능 향상) 학생 프로필 사진 DB화 (관리 편이성과 관련 기능 향상) 데이터베이스를 호출하는 모든 SQL 구문을 기록 (보안 감사 능력 향상) 사용 기관 및 프로젝트 소개 사용 기관: 감리교 신학대학교 1887년 설립된 국내최초의 신학교 대상 시스템: 학사 관리 시스템 학부, 대학원, 평생교육원, 행정 등 대학교 업무 전반을 지원하는 종합 전산 프로그램 델파이 3 버전으로 개발된 후 20년 간 유지해 온 시스템 현대화 마이그레이션을 계획하게된 동기 윈도우 10이 보편화 됨에 따라 이에 대한 원활한 지원이 필요 윈도우 10에서 기존 사용자 프로그램의 알수없는 오류 발생 (특히 BDE가 가장 문제임) 품질 향상이 필요 기존 서비스를 모두 제공할 수 있으면서도 디자인, 사용성, 기능, 성능을 향상하고자 함 투자 대비 효과 지속 유지 인력 및 비용 측면에서, 이 시스템은 지난 20년 간 충분히 투자 대비 효과를 실현해 왔으며, 현대화를 통해 장점을 유지 마이그레이션 프로젝트 개요 목표 (와 기대 효과) BDE를 완전히 제거하고 FireDAC으로 교체 (64비트 윈도우 지원, 배포 편이성 향상, 데이터 처리 성능 향상) 윈도우 10 스타일 적용 (일관성 있고 세련된 현대식 디자인) 사이드바 메뉴 구현 (사용성 향상) 퀵리포트(Quick Report) 업그레이드 (엑셀 내보내기 등 기능 향상) 학생 프로필 사진 DB화 (관리 편이성과 관련 기능 향상) 데이터베이스를 호출하는 모든 SQL 구문을 기록 (보안 감사 능력 향상) 개요 기간 : 총 3개월(2016년 5월 ~ 7월) 투입 인원 외부 : 1명(데브기어 컨설턴트 방문 컨설팅 / 상주) 내부 : 1명(담당자) 대상 프로젝트 델파이 프로젝트 : 27개 .pas 파일 : 3,000여개 .dfm 파일 : 3,000여개 델파이 버전 현대화 델파이 개발 환경을 3 버전에서 10.1 베를린 버전으로 이전 조언 또는 팁 현대화 마이그레이션의 프로젝트에서 소스 코드 변환 작업은 가장 기본적이고 가장 많은 부분을 차지한다. 하지만, 프로젝트 계획에 아래 사항을 반영하면, 프로젝트 완료 후 사용자의 만족도는 더 높아진다. 사용자들이 주로 사용하는 화면을 몇개 선정하여 디자인과 기능을 집중 강화한다. 사용자들이 가장 원했던 기능의 우선 순위를 정하고 가장 높은 몇개의 기능 강화에 집중한다. 마이그레이션 프로젝트 진행 단계 이 프로젝트는 데브기어 마이그레이션 프로젝트 절차 - 1.1 버전에 따라 진행되었다. 그 결과, 전체 프로젝트 기간 (3개월) 중 코드 변환 작업 기간은 15% (1~2주) 만으로 충분했다. 나머지 85% 기간 (2.5 개월)은 이슈 해소, 자동화 방안 수립, 테스트, 목표한 향상 작업을 진행했다. 주요 작업 (및 참고 자료) 코드 변환 자동 변환 도구(들) (TODO 자동 변환 도구 소개 링크) 마이그레이션 가이드 문서(TODO 마이그레이션 가이드 소개 링크) BDE를 FireDAC으로 교체 (64비트 윈도우 지원, 배포 편이성 향상, 데이터 처리 성능 향상) BDE (Borland Database Engine) 윈도우 3.1이 사용되던 1995년에 나온 기술 유니코드를 지원하지 않으며 윈도우 10 등 최신 64비트 윈도우에서 "알 수 없는 오류"를 일으킴 프로그램 배포 시 번거로움 (BDE Admin을 별도로 설치해야 함) "작업을 따로 하지 않고 FireDAC으로 교체" 만으로 얻은 효과 배포 간소화: FireDAC은 BDE보다 오라클 클라이언트 배포가 간편 프로그램 배포 시 Oracle thin client 관련 dll 몇개 만 포함하면 됨 [따라하기] FireDAC으로 오라클(Oracle) DB와 연결하기 데이터 처리 성능 향상 FireDAC 성능 비교: BDE, dbGO(ADO), dbExpress, FireDAC FireDAC 주요기능 10가지를 예제와 함께 살펴보기 reFind 도구를 사용하여 BDE에서 FireDAC으로 자동 변환하는 방법 델파이: reFind.exe: 마이그레이션 작업에서 수작업을 줄여주는 도구 C++빌더: (영문) "reFind" 도구를 사용하여 BDE를 FireDAC 으로 마이그레이션 하기 (델파이 10.1 환경에서 설명) 윈도우 10 스타일 적용 (일관성 있고 세련된 현대식 디자인) 델파이에서 프로젝트 옵션 설정 만으로 프로그램의 컨트롤, 테두리, 배경색 등등 모든 화면 요소에 일관성있고 현대적인 디자인을 적용 VCL 스타일을 적용해 1분만에 윈도우 10 최신 룩앤필 적용하기 사이드바 메뉴 구현 (사용성 향상) 델파이에 들어있는 VCL 윈도우 10 컨트롤 중 슬라이드 메뉴를 제공하는 TSplitView를 이용해 업무별 바로가기 기능을 구현 윈도우 10 용 새 VCL UI 컨트롤로 윈도우 10 UI를 손쉽게 적용하기 퀵리포트(Quick Report) 업그레이드 (엑셀 내보내기 등 기능 향상) "작업을 따로 하지 않고 퀵리포트 업그레이드" 만으로 얻은 효과 보고서 내보내기 (저장) 기능 추가 기능 추가 작업: 퀵리포트 보고서를 엑셀로 내보내기 보고서 화면에 엑셀 저장 필터 컴포넌트(TQRXLSXFilt)를 추가 해당 보고서 화면이 많았으므로, 텍스트 에디터의 여러파일 찾기 기능과 치환 기능을 이용해 폼파일(*.dfm)과 소스파일(*.pas)에 컴포넌트를 추가하는 코드 삽입 작업을 자동화 학생 프로필 사진 DB화 (관리 편이성과 관련 기능 향상) 오라클 DB에 사진 테이블 생성하고 BLOB 컬럼을 추가하여 학생 프로필 사진을 관리하도록 하여, 프로그램에서 사진을 표시하기 위해 수행되던 성가신 수작업을 해소함 BLOB 컬럼에 (이미지 등의)데이터 읽고 쓰기 퀵레포트(Quick Report)에 사진 출력하기 데이터베이스를 호출하는 모든 SQL 구문을 기록 (보안 감사 능력 향상) 요구 사항: "DB에 호출하는 모든 SQL 문을 로그로 남긴다." TFDQuery 컴포넌트 (DB에 전달되는 SQL을 담당하는 컴포넌트)를 상속받고, 메소드 덮어쓰기 (Override)를 이용하여 로그 기록 기능을 삽입 그 결과, 이렇게 커스터마이징 된 컴포넌트를 사용하는 모든 SQL은 자동으로 로그를 남기게 됨 (참고자료는 작성 중)
  4. 이 문서의 목적: 마이그레이션을 할 때 수작업을 없애는 도구 중 RAD 스튜디오에 들어있는 reFind.exe를 알고 싶은 사람들이 가장 먼저 찾는 글 애플리케이션 현대화에 대한 관심은 매우 높다. 특히 델파이와 C++빌더의 코드를 현대화 마이그레이션할 때는 코드 대부분을 자동 변환 할 수 있다. 자동화 도구도 여러가지인데, 엠바카데로 MVP인 Oren Aviram이 소개한 델파이 파서 (Delphi Parser) 처럼 수준높은 유료 도구도 있고, 지금 소개하는 reFind.exe처럼 강력하고 간단한 명령줄 유틸리티도 있다. reFind 사용법 [DocWiki 번역] reFind.exe, Perl 정규 표현식을 사용하는 찾기 바꾸기 유틸리티 reFind 요약 reFind는 RAD 스튜디오를 설치하면 사용할 수 있다. 설치하면, RAD 스튜디오 설치 경로의 bin 폴더에는 RAD 스튜디오 실행 파일 뿐만 아니라 reFind.exe도 들어있다. 이 경로는 PATH 환경 변수에 자동 등록되므로, 명령줄에서 따로 경로를 지정하지 않고 reFind 라고만 입력하면 실행된다. reFind는 지정된 "변경 대상"에 지정된 텍스트 "변환 규칙"을 적용한다. (예: reFind *.pas *.dfm /X:FireDAC_Migrate_BDE.txt ) 변환 규칙은 명령줄에서 일일이 규칙을 지정해도 되지만, 위 예의 FireDAC_Migrate_BDE.txt처럼 규칙을 담은 별도의 텍스트 파일을 지정하는 것이여러모로 좋다. reFind는 몇가지 변환 규칙 파일이 함께 제공된다. [공용 문서]\Embarcadero\Studio\22.0*\Samples\Object Pascal\Database\FireDAC\Tool\reFind 아래에 마이그레이션 목적별 폴더에 있다. *이때 22.0은 RAD 스튜디오 11.0 알렉산드리아 기준이며, 버전에 따라 숫자가 달라진다 AnyDAC, BDE, DbExpress을 FireDAC으로 변환하는 규칙 파일과 FireDAC을 (XE7에서 XE8으로) 버전업하는 규칙 파일이 들어 있다. 여기를 클릭하면 깃허브에 있는 FireDAC_Migrate_BDE.txt을 열어 볼 수 있다. 변환 규칙 파일을 열어보면 규칙을 쉽게 이해할 수 있다 (복사 후 필요한 부분을 변경하여 재사용하기도 좋다) 활용 예시 reFind.exe를 이용해 BDE 프로젝트를 FireDAC으로 마이그레이션 따라하기 참고 이미지 그림1. reFind용 변환 규칙 파일과 데모 프로젝트 Sample이 있는 기본 경로(그림 맨위의 경로)와 각 목적별 폴더 (선택된 폴더는 BDE 마이그레이션 Sample 폴더) 그림2. FireDAC_Migrate_BDE.txt 파일에 담긴 변환 규칙 (이 파일은 위 그림1에서 선택된 폴더 안에 있다.
  5. Top 10 How-To’s: Modernization (원문 작성: Hagop Panosian | 2022년 2월 13일)을 번역한 글 (번역일: 2022년 2월 18일) Application modernization, also known as legacy modernization, involves updating existing software and its features to benefit from technological advances and maintain performance. Modernization can involve making apps cloud-native to lower cost and increase scalability and agility, and to enable remote teams to maintain and update it. Besides improving performance, modernization extends the lifespan of any application as performance requirements dictate change. 애플리케이션 현대화(또는 레거시 현대화)는 사용 중인 소프트웨어와 그 기능을 업데이트함으로써 발전된 기술의 장점을 취함과 동시에 성능 유지하는 작업이다. 앱을 클라우드-네이티브하도록 만들어서 비용을 절감하고, 확장성과 민첩성 높이고, 팀이 원격에서 유지하고 업데이트할 수 있도록 하는 것도 현대화라고 할 수 있다. 단순한 성능 향상 이외에도, 현대화는 성능 요구 사항에 의해 변화를 해야하는 상황에서도 애플리케이션의 수명을 연장한다. Here are 10 great How-To’s on modernization. 현대화를 어떻게 할 것인지를 알려주는 훌륭한 10 방법 10 가지를 여기에 모아두었다. 1. 윈도우 11 용으로 앱을 현대화하는 방법 5가지 (5 Ultimate Ways To Modernize Your Apps For Windows 11) Delphi offers a modern, robust & enterprise-grade UI developer environment with Visual Component Library (VCL) for Windows only and FireMonkey (FMX) for cross-platform development. Delphi VCL offers the latest features and modern UI controls for your Windows app development. 델파이는 현대적이고, 견고하고, 엔터프라이즈 수준의 UI 개발 환경을 제공하기 위해 윈도우 전용인 VCL(비주얼 컴포넌트 라이브러리)과 크로스-플랫폼 개발용인 FMX(파이어몽키)를 제공한다. 델파이 VCL을 활용하면 최신 기능과 현대적인 UI 컨트롤을 당신의 윈도우 앱 개발에 적용할 수 있다. 자세히 보기: https://welcome.devgear.co.kr/topic/155-윈도우-11-용으로-앱을-현대화하는-방법-5가지 2. RAD 서버를 활용하여 현대화할 때 알아야 할 모든 것 (Everything You Need To Modernize With RAD Server) In the modern age, isn’t it true to say we are completely surrounded and immersed in the technology of diverse forms? Much of it now is entirely cloud-based, but there’s still a substantial proportion that employs a mix of both cloud and more physical hardware computing resources. However, the common thread among all of these technologies, even the most recent ones, is the certainty of them becoming obsolete. After all, even though all technologies evolve rapidly, they are eventually replaced by something which is either an evolutionary step thanks to advances in technological offerings or because new and more potent ways of providing a service or solving a problem emerge. 현대 사회에서 우리는 기술에 둘러싸여서 파묻혀있고 그 기술의 형태도 다양하다. 전적으로 클라우드에 기반을 둔 기술이 대부분이긴 하지만 여전히 상당 부분은 클라우드와 물리적인 하드웨어 컴퓨팅 장비가 함께 섞여 있기도 하다. 하지만 지금 아무리 최신 기술이어도 결국에는 반드시 더 최신 기술에 의해 밀려나고 시대에 뒤쳐지게 되는 때가 온다는 사실 하나는 분명하다. 모든 기술이 각각 급격하게 발전하지만, 결국 발전된 기술 덕분에 더 발전한 단계에 의해서 교체되거나 또는 문제 해결이나 서비스 제공 방식 자체를 바꾸는 새롭고 강력한 그 무언가가 나온다. 자세히 보기: https://welcome.devgear.co.kr/topic/163-rad-서버를-활용하여-현대화할-때-알아야-할-모든-것 3. 레거시 닷넷 프레임워크를 델파이로 마이그레이션하기 (A Guide To Migrating From Legacy .NET Framework To Delphi) The application migration process can be easy or tedious, depending on the technology you are migrating. Moreover, migrating legacy projects to a new development environment might take a vast amount of time because of new software-from-scratch – re-engineering. 애플리케이션 마이그레이션 과정은 쉬울 수도 있고 지루할 수도 있다. 이것은 마이그레이션 대상 기술이 무엇인가에 달려있다. 게다가, 레거시 프로젝트를 새 개발 환경으로 마이그레이션하려면 엄청난 시간이 소요된다. 그 이유는 소프트웨어를 처음부터 새로 만드는 리엔지니어링 작업이기 때문이다. Application migration is a broad term in the technological realm. Application migration can involve moving the app to a different cloud service provider. It can also be a migration from one technology to another, such as.NET to Delphi FireMonkey. It is possible to migrate from legacy to a completely new up-to-date technology from the ground up. Furthermore, this can be database migration and platform migration, but with the use of IDE software, it will be simple and fast to migrate. 애플리케이션 마이그레이션이라는 용어는 기술 분야에서 넓은 의미로 사용된다. 다른 클라우드 서비스로 앱을 옮기는 것을 의미하기도 하고, 다른 기술로 이전하기(예를 들어, 닷넷에서 델파이 파이어몽키로 이전 등)를 의미하기도 한다. 레거시 애플리케이션을 버리고, 전혀 새로운 기술을 도입하여 바닥부터 아예 새로 만들거나, 심지어 데이터베이스를 다른 플랫폼으로 옮길 때에도 마이그레이션이라는 용어를 사용한다. 하지만, IDE 소프트웨어를 사용하면 마이그레이션이 간단하고 빠르게 진행될 수 있다. 자세히 보기: https://devgear.co.kr/archives/5201 4. 플루언트 디자인 시스템으로 애플리케이션 현대화하기 (Modernize Your Applications With The Fluent Design System) Just recently there have been some great webinars and posts on how to modernize your applications. We’ve gathered together a collection of the most recent ones which focus on Microsoft’s gorgeous Fluent Design System. 얼마 전에 애플리케이션 현대화 방법을 다루는 다양한 기술 기고와 웨비나가 있었다. 여기에는 그 중에서도 매력적인 마이크로소프트 플루언트 디자인 시스템(Fluent Design System)에 중점을 둔 최신 기술 자료들을 모아서 정리했다. Visitors to the Desktop First Conference were able to hear directly from Microsoft Engineer Matteo Pagani. In this video Matteo describes Fluent UI in particular from Microsoft’s perspective and how it can help add that superb look and really modernize your applications. 데스크탑 퍼스트 컨퍼런스(Desktop First Conference) 참석자는 마이크로소프트 엔지니어인 마테오 파가니(Matteo Pagani)가 플루언트 UI를 직접 설명하는 세션을 들을 수 있었다. 아래 비디오에서는 마테오가 플루언트 UI를 마이크로소프트의 관점에서 설명하고, 플루언트 UI를 사용하여 어떻게 애플리케이션을 멋지게 현대화하고 월등한 모습을 추가하는 지를 알려준다. 자세히 보기: https://devgear.co.kr/archives/4534 5. 멀티-디바이스 파이어몽키 앱을 현대화하기 - 사용하기 쉬운 카드 뷰 마법사 템플릿 (Modernize Your Multi-Device Fire Monkey App Easy To Use Card View Wizard Layout Template) User experience is the key thing to be considered while building a modern Multi-Device application. Lots of layout templates were available in GetIt Package Manager to design responsive, ultra-modern, cross-platform FireMonkey applications. This post helps to understand one of the FireMonkey Layout templates, the Card View Wizard. 사용자 경험 (UX, User Experience)은 현대적인 멀티-디바이스 애플리케이션을 구축할 때 중요하게 고려해야 한다. 겟잇 패키지 매니저 (GetIt Package Manager) 안에는 레이아웃 템플릿들이 많이 들어 있어서 무척 현대적이고, 반응형인 디자인을 크로스 플랫폼 파이어몽키 애플리케이션에 적용할 수 있다. 이 글은 파이어몽키 레이아웃 템플릿 중에서 카드 뷰 마법사 (Card View Wizard)를 설명한다. Card View Layout Template is a Fire Monkey template that incorporates a number of card view pages that can be navigated forward and backward, though one would use this as an in-app tutorial. 카드 뷰 레이아웃 템플릿은 파이어몽키 템플릿 중 하나이다. 이것은 카드 뷰 페이지를 여러개 넣고 각 페이지 간에 앞뒤로 이동할 수 있도록 하는 화면 템플릿이다. 이 템플릿은 튜토리얼 화면을 구현할 때 활용되기도 있다. 자세히 보기: https://welcome.devgear.co.kr/topic/319-멀티-디바이스-파이어몽키-앱을-현대화하기-사용하기-쉬운-카드-뷰-마법사-템플릿/ 6. FastReport를 사용하는 델파이/C++ 앱을 빠르게 윈도우의 High DPI 설정에 맞춰 마이그레이션하고 현대화하기 (Quickly Migrate and Modernize Your Delphi/C++ Apps Using FastReport With Windows High DPI Setup) Display panel manufacturers have packed an increasing number of pixels into each unit of physical space on their panels resulted in the dots per inch (DPI) of modern display panels. In the past, most displays had 96 pixels per linear inch of physical space (96 DPI); in 2017, displays with nearly 300 DPI or higher are readily available. Variety of monitors like SD, Full HD, 4K Ultra HD, 8K Ultra HD in the market. 디스플레이 패널의 물리적 공간 당 픽셀 수는 점점 더 많아지고 있어서 DPI (인치 당 도트수)가 높은 모니터가 많아졌다. 예전에는 디스플레이 대부분이 96 DPI 즉, 1 인치 당 96 픽셀이 들어있었지만, 2017년에는 300 DPI 또는 그 이상인 패널들도 꽤 사용되기 시작했다. 이제 시중에는 SD, Full HD, 4K 울트라 HD, 8K 울트라 HD 등 다양한 모니터가있다. We have laptops, desktops with small screens, and without display scale factor/DPI changes it’s very hard to use it and this can be even more complicated when talking about Full HD, 4K Ultra HD, 8K Ultra HD. Our application should be able to handle them. You cannot be sure what every user prefers. 우리가 사용하는 노트북 또는 화면이 작은 데스크탑에서 화면 배율 팩터/DPI를 변경할 수 없다면 사용하기가 매우 어렵다. 더 나아가 Full HD, 4K 울트라 HD, 8K 울트라 HD 모니터에서는 훨씬 더 복잡해진다. 우리가 제공하는 애플리케이션은 이 모든 것을 다룰 수 있어야 한다. 어떤 사용자가 어떤 사양의 모니터를 사용하고 싶어할 지를 모르기 때문이다. 자세히 보기: https://welcome.devgear.co.kr/topic/157-fastreport를-사용하는-델파이c-앱을-빠르게-윈도우의-high-dpi-설정에-맞춰-마이그레이션하고-현대화하기 7. WINAPI, COM, SHELLAPI, WINRT와 윈도우 VCL 애플리케이션의 통합 & 현대화 방법 (Learn How To Modernize And Integrate WinAPI, COM, ShellAPI, And WinRT Into Your Windows VCL Applications) In this webinar, learn how to access all the APIs on Windows 10 from RAD Studio, Delphi, and C++Builder. 이 웨비나를 통해, 윈도우 10의 모든 API들을 RAD스튜디오, 델파이, C++빌더에서 접근하는 방법을 배울 수 있다. 주제 (Overview) Traditional Core APIs Shell Integration WinRT and more 전통적인 Core API(들) Shell 통합 WinRT 기타 등등 자세히 보기: https://devgear.co.kr/archives/4607 8. 오래된 레거시 델파이, C++ 애플리케이션을 최신 스타일의 초고속 앱으로 마이그레이션하기 (A RoadMap To Migrate Your Legacy Delphi And C++ Applications To The Latest Blazing-Fast Version) Thinking to migrate your Legacy Delphi/C++Builder Applications to the Latest Delphi? Curious to know the things to do and tips to do effortless migrations ? This post will guide you through the considerations for successful migrations. 오래된 레거시 델파이/C++빌더 애플리케이션을 최신 버전으로 마이그레이션하려는 생각이 있는가? 무슨 작업을 해야하고 크게 힘들이지 않고 마이그레이션하는 팁이 궁금한가? 이 글에서는 성공적인 마이그레이션을 위해 고려할 사항들을 따라가면서 안내한다. Things to consider : 고려해야 할 것(들): Unicode Compatibility – Unicode support was added to RAD Studio, Delphi and C++Builder starting with the 2009 version. Many migration resources were developed at that time but are still useful today if upgrading from a pre-Unicode (2007 or earlier) version. Unicode Statistics Tool on your Delphi application and check if any Unicode changes are needed.This Unicode Statistics Tool will assist you in collecting useful statistics for the time and effort needed to migrate your Delphi applications to Unicode. More Resources for Unicode. 유니코드 호환성 - 델파이, C++빌더, RAD 스튜디오에서 유니코드를 지원하기 시작한 해는 2009년이다. 그 당시에 많은 마이그레이션 자료들이 만들어졌는데, 지금도 여전히 유니코드 이전인 2007 버전 또는 그 이전 버전에서 마이그레이션할 때 유용하게 활용된다. 유니코드 분석 도구(Unicode Statistics Tool)를 이용해 델파이 애플리케이션을 분석하면 유니코드 변경이 필요한 부분이 있는지를 점검할 수 있다. 이 유니코드 통계 도구는 델파이 애플리케이션을 유니코드로 마이그레이션할 때 시간과 노력이 얼마 필요한 지에 대한 유용한 통계를 수집할 수 있도록 도와준다. 유니코드용 리소스에 대한 더 많은 내용은... 자세히 보기: https://devgear.co.kr/archives/3630 9. 윈도우 앱을 적시에 예산 범위 안에서 현대화하는 방법 (This Is How To Modernize Your Apps On Time And Under Budget) We know that technology is progressing at a rapid pace. The software systems built five years ago using the then-modern technologies might not be relevant today due to outdated versions. Every software that aims to scale and provide effective services to its consumers must be open to modernization. Modernization of software systems enhances their longevity and keeps them relevant to the technological age in which they are operating. 우리는 기술이 빠르게 발전하고 있다는 것을 잘 안다. 5년 전에 구축한 소프트웨어 시스템은 당시에 통용되던 기술을 사용했음에도 불구하고 오늘날에는 버전이 오래되어 적합하지 않은 경우가 생긴다. 확장 가능하면서 효과적인 고객 서비스를 제공하기를 목표로 하는 소프트웨어라면 현대화에 개방적이어야 한다. 현대화는 소프트웨어 시스템의 수명을 강화하고 시대에 적합한 기술을 유지하도록 한다. 자세히 보기: https://welcome.devgear.co.kr/topic/325-윈도우-앱을-적시에-예산-범위-안에서-현대화하는-방법/ 10. 엠바카데로 DEV-C++: 성공적인 현대화 작업을 위한 윈도우 C++ IDE (Embarcadero Dev C++: Successfully Modernizing A Popular Windows C++ IDE) In October of 2020, Embarcadero sponsored and released a new fork version 6.0 of Dev C++ with improvements that included an updated GCC 9.2.0 compiler with support for Windows 10 and C++17/C++20, high DPI, UTF8 files and improved icons, and a dark theme option. An earlier update in July featured an upgrade of the Dev C++ code to Delphi 10.4. 2020년 10월, 엠바카데로는 Dev C++의 새 버전인 6.0 버전을 후원하고 출시했다. 여기에는 GCC 9.2.0 컴파일러 업데이트, 윈도우 10 지원, C++17/C++20, high DPI, UTF8 파일, 아이콘 개선, 다크 테마 선택 등이 포함되었다. 그 이전인 7월 업데이트에서는 Dev C++ 코드를 델파이 10.4로 업그레이드하는 작업을 먼저 마쳤었다. 자세히 보기: https://devgear.co.kr/archives/3885
  6. "This Is How To Modernize Your Apps On Time And Under Budget" (원문 작성자: Emad Bin Abid, 작성일: 2021년 9월 14일)을 번역한 글 We know that technology is progressing at a rapid pace. The software systems built five years ago using the then-modern technologies might not be relevant today due to outdated versions. Every software that aims to scale and provide effective services to its consumers must be open to modernization. Modernization of software systems enhances their longevity and keeps them relevant to the technological age in which they are operating. 우리는 기술이 빠르게 발전하고 있다는 것을 잘 안다. 5년 전에 구축한 소프트웨어 시스템은 당시에 통용되던 기술을 사용했음에도 불구하고 오늘날에는 버전이 오래되어 적합하지 않은 경우가 생긴다. 확장 가능하면서 효과적인 고객 서비스를 제공하기를 목표로 하는 소프트웨어라면 현대화에 개방적이어야 한다. 현대화는 소프트웨어 시스템의 수명을 강화하고 시대에 적합한 기술을 유지하도록 한다. This thought process is equally valuable to desktop apps. Application stakeholders have an imperative to recognize the need to modernize desktop software in a timely manner to efficiently continue providing services that remain competitive in the face of competition; embracing new technologies, advancements in techniques and user interface design and even fashions for UX paradigms which wax and wane. In this blog post, we’ll look at how you can use Windows application development to modernize your Windows apps on time and within your budget. 이점은 데스크탑 앱에서도 똑같이 중요하다. 애플리케이션 이해관계자에게는 데스크탑 소프트웨어를 현대화해야 할 필요성을 적시에 인식해야 할 사명이 있다. 그래야 서비스 제공을 효율적으로 지속할 수 있고 치열한 시장에서 경쟁력을 유지할 수 있다. 새 기술, 발전된 기술, UI (사용자 인터페이스) 디자인에서부터 유행하고 사라지는 UX (사용자 경험) 패러다임 유행까지 수용해야 한다. 이 글은 윈도우 애플리케이션 개발도구를 사용하여 당신의 윈도우 앱을 적시에 예산 범위 안에서 어떻게 현대화하는 지 그 방법을 살펴본다. 내 델파이 앱을 현대화하는 방법은? (How can I modernize my Delphi app?) Embarcadero Technologies published a whitepaper titled “Successfully Modernizing A Popular Windows C++ IDE” that discusses the aspects and strategies used to modernize DevC++ IDE. This migration and up-gradation activity is an extremely important and valuable learning resource for the teams that plan on app migration. 엠바카데로는 “인기있는 윈도우 C++ IDE를 성공적으로 현대화하기 (Successfully Modernizing A Popular Windows C++ IDE)”라는 제목의 기술백서에서 DevC++ IDE를 엠바카데로에서 현대화할 때 사용한 관점과 전략을 설명한다. 여기에서 다루는 마이그레이션 업그레이드 활동은 애플리케이션을 마이그레이션하려고 계획하는 팀에게 너무나도 중요하고 배울 것이 많은 귀중한 학습 자료이다. The upgrade of DevC++ IDE was done in two phases. The first phase aimed at making the least possible changes to make the application compile with the newer version of Delphi. After that, the second phase involved changes such as compiler upgrade, Unicode support, and full support for Windows 10 with Embarcadero DevC++ 6.0. DevC++ IDE는 두단계로 나누어 업그레이드 되었다. 첫번째 단계에서는 새 델파이 버전에서 컴파일이 되는 것을 목표로 하고 변경은 최소화 했다. 그리고 나서 두번째 단계에서는 컴파일러 업그레이드, 유니코드 지원, 윈도우 10 완전 지원을 DevC++ IDE에 반영했다. The case study mentions that there were some important third-party upgrades as well. The most important of all were SynEdit, FastMM4, AStyle, and TDM-GCC. The Embarcadero team identified the components to be upgraded and that is indeed one of the essential and crucial steps towards any third-party migration. DevC++ 사례 연구에서는 몇가지 중요한 써드-파티들에 대한 업그레이드도 언급한다. 가장 중요한 것으로는 SynEdit, FastMM4, AStyle, TDM-GCC가 있었다. 엠바카데로 마이그레이션 팀은 업그레이드가 필요한 컴포넌트를 찾아냈는데, 이 과정은 써드-파티를 마이그레이션하기 위해 실제로 꼭 필요하고 가장 중요한 단계이다. The upgrade, as a result, provided a new and modern interface along with a faster and smoother Windows development in C++. 업그레이드 결과, 새롭고 현대적인 인터페이스를 갖추고, 더 빠르고 원활하게 윈도우 개발을 할 수 있는 C++ IDE가 되었다. Just like the DevC++ IDE upgrade, you can also follow similar steps to migrate your Delphi application for a smoother and better developer and user experience. DevC++ IDE 업그레이드 사례와 비슷하게 단계를 진행하면, 당신의 델파이 앱이 더 원활하고 더 좋은 UX (사용자 경험)을 제공할 수 있도록 마이그레이션 할 수 있다. Read the Successfully Modernizing A Popular Windows C++ IDE whitepaper to explore more about the DevC++ IDE upgrade. “인기있는 윈도우 C++ IDE를 성공적으로 현대화하기" 기술 백서를 보면, DevC++ IDE 업그레이드에 대해 더 자세히 알 수 있다. 마이그레이션 및 업그레이드를 위해 꼭 필요한 요소는 무엇인가? (What are some of the essential elements for migration and up-gradation?) If you are considering modernizing your legacy Delphi desktop application, you might think of the following essential migration and modernization strategies, to begin with. 레거시 델파이 데스크탑 애플리케이션을 현대화하려는 생각이 있다면, 마이그레이션과 현대화를 위한 아래의 필수 전략(들)부터 시작하기 바란다. 유니코드가 왜 중요한가? (Why was Unicode important?) Prior to the mid 2000s, Unicode was not often considered a technology of enough importance to include in most systems available on the market. With a more widespread adoption and availability of internet connectivity support for character sets which were able to render a broad range of languages became a pressing issue. People wanted their programs to be displaying text in the language they spoke and read rather than English which had become the Internet’s Lingua Franca (an ironic phrase if you think about it). Unicode allowed, for example, Russians to read and use Cyrillic characters or Japanese users to choose to display screens using Kanji should they choose to do so. 유니코드는, 2000년대 중반 이전까지, 시장에 있는 시스템 대부분에 꼭 들어가야 할 만큼 중요한 기술 이라고 간주되지는 못하는 경향이 있었다. 인터넷 연결이 더 널리 채택되고 사용됨에 따라 언어를 폭넓게 표현할 수 있는 문자 세트 지원이 널리 퍼지게 되고, 유니코드는 시급한 문제가 되었다. 사람들은 프로그램에 있는 텍스트가 더이상 영어만이 아니라 자신들이 말하고 읽는 언어로 표현되기를 원했다 -인터넷 세상에서 영어가 공통 언어(Lingua Franca)가 된 현실을 생각하면 좀 아이러니이기도 하다. 유니코드는 예를 들어 러시아 사람들은 키릴 문자(Cyrillic)를 사용하여 읽고 사용하고, 일본 사용자들은 일본 한자(Kanji)로 표현되는 화면을 선택하는 것을 가능하게 한다. Unicode support was added to Delphi, C++ Builder, and RAD Studio in 2009. There are multiple resources that help with the migration and upgrading of legacy Delphi applications to a newer version which supports Unicode changes. 델파이, C++빌더, RAD 스튜디오에서 유니코드를 지원하기 시작한 해는 2009년이다. 레거시 델파이 애플리케이션을 유니코드를 지원하는 새 버전으로 마이그레이션 업그레이드할 때 도움을 받을 수 있는 자료는 많다. For more information about Unicode resources, you may visit the Unicode section of our Migration and Upgrade Center resource. 유니코드에 대한 자세한 내용은 엠바카데로의 마이그레이션 업그레이드 센터 리소스의 유니코드 섹션에 있다. 64비트 마이그레이션이 중요한가? (Is 64bit migration important?) When dealing with legacy applications built for 32-bit operating systems you might think that modernizing your applications for a 64-bit operating system will be a troublesome and labor-intensive task to do. In many cases, can be true; but not with Delphi and RAD Studio. 32비트 운영 체제용으로 구축된 레거시 애플리케이션을 다룰 때, 당신은 아마 64비트 운영 체제용으로 현대화하기는 번거롭고 많은 수고가 들어가는 작업이 될 것이라고 생각할 수 있다. 많은 경우에 이것은 사실이지만, 델파이와 RAD 스튜디오에서는 그렇지 않다. Beginning the emergence of Delphi XE2 and continuing to this day, it is now extremely simple to generate 64bit applications using the same codebase as that for 32bit applications. This migration process is significantly easier compared to other languages that require changes to variable and record/structure types to bridge the gap and resolve differences between the 32 and 64 bit platforms. Delphi XE2 출시 이후 지금까지, 델파이에서 32비트 애플리케이션을 만든 동일한 코드를 그대로 사용하여 64비트 애플리케이션을 만드는 것은 너무 간단하다. 다른 언어에서는 32비트와 64비트 플랫폼의 격차를 메우고 차이점을 해결하기 위해 변수, 레코드/구조체(structure) 등을 바꿔야 하지만, 이와 달리 델파이에서는 64비트 마이그레이션 작업이 현격하게 더 쉽다. For more information about 64bit migration, you may visit the 64bit migration section of our Migration and Upgrade Center resource. 64비트 마이그레이션에 대한 자세한 내용은 엠바카데로의 마이그레이션 업그레이드 센터 리소스의 64비트 마이그레이션 섹션에 있다. 데이터베이스와 미들웨어를 현대화에 적합하게 맞추는 방법은? (How does database and middleware fit into modernization?) Database migration is probably one of the most crucial elements for evolving software applications. The teams that look for database migration and optimization opportunities remain successful in the long run as they can more easily adapt to newer market requirements for the most critical part of application experience: data. 계속 진화하는 소프트웨어가 되기 위해 가장 중요한 요소 중 하나를 꼽자면 아마도 데이터베이스 마이그레이션일 것이다. 데이터베이스를 마이그레이션하고 최적화할 수 있는 기회를 찾는 팀은 장기적으로 성공을 지켜갈 수 있다. 그 이유는 애플리케이션 경험 중에 가장 중요한 부분인 데이터를 시장의 새로워진 요구 사항에 맞게 적응하는 것이 더 쉽기 때문이다. The older-style desktop databases, Borland Database Engine (BDE) and dbExpress have been removed from Delphi installation in favor of a new, feature-packed and vastly more powerful FireDAC. The migration is simple, easy, and straightforward. BDE (볼랜드 데이터베이스 엔진)과 dbExpress는 오래된-스타일인 데스크탑 데이터베이스이고, 이제는 델파이 설치에서도 빠져있다. 그 대신 기능이 풍부하고 훨씬 더 강력한 새 엔진인 FireDAC이 들어갔다. FireDAC으로 마이그레이션하기는 쉽고 간단하고 명료하다. For more information about database and middleware, you may visit the database and middleware section of our Migration and Upgrade Center resource. 데이터베이스 및 미들웨어에 대한 자세한 내용은 엠바카데로의 마이그레이션 업그레이드 센터 리소스의 데이터베이스 및 미들웨어 섹션에 있다. 앱을 현대화할 때 도움이 되는 써드-파티 컴포넌트는 무엇이 있는가? (What 3rd party components are available to help modernize our apps?) If your legacy Delphi application is using 3rd party components and libraries, they need to be rebuilt for the current Delphi version. If you already have the source code of third-party components, then this becomes easier as you will just need to rebuild your application. 당신의 레거시 델파이 애플리케이션이 써드-파티에서 제공한 컴포넌트와 라이브러리를 사용하고 있다면, 델파이 현재 버전에서 이것들을 다시 빌드해야 한다. 써드-파티 컴포넌트의 소스 코드를 가지고 있다면, 다시 빌드를 하기만 하면 되므로 더 쉽다. On the other hand, if your legacy application is using third-party resources without the availability of the original source code then you will have to use updated versions of those components that are compatible with newer Delphi. 반면에, 사용하고 있는 써드-파티의 원본 소스 코드를 가지고 있지 않다면, 새 델파이 버전과 호환될 수 있는 업데이트 버전을 찾아서 사용해야만 한다. For more information about 3rd party components, you may visit the 3rd party components section of our Migration and Upgrade Center resource. 써드-파티 컴포넌트에 대한 더 많은 정보는 엠바카데로의 마이그레이션 업그레이드 센터 리소스의 써드-파티 컴포넌트 섹션에 있다. Here is an interesting video that talks about modernizing your legacy Delphi projects in great detail. 아래 비디오에서는 레거시 델파이 프로젝트를 매우 상세하게 다루고 있다. Also, this recent webinar about automation, workflows, and modernization involving Embarcadero MVPs Glenn Dufke and Wagner Landgraf can also help you figure migration and modernization strategies for your legacy Delphi projects. 또한, 자동화, 워크 플로우, 현대화에 대해서 엠바카데로 MVP인 Glenn Dufke와 Wagner Landgraf가 진행한 최근 웨비나는 당신의 레거시 델파이를 대상으로 마이그레이션 현대화 전략을 그려보는 데 도움이 된다. 델파이 애플리케이션 현대화 아이디어 몇가지를 꼽아 본다면? (What are a few modernization ideas for a Delphi application?) In-app payments and ads – Delphi has components for this Data connection security with SSL Create and deploy icons for your app App activation and deactivation events – a standard Event mechanism in modern Delphi versions Business analytics Multithreading for better responsiveness – recent version of Delphi have really great libraries and classes which make threading a much easier task than in years past Read more about interesting and cool modernization ideas here. 인-앱 결제, 인-앱 광고 - 델파이에는 이를 위한 컴포넌트가 있다 SSL을 통한 데이터 연결 보안 앱 아이콘(들)을 만들어서 배포 앱 활성화 및 비활성화 이벤트 - 최신 델파이 버전에는 표준 이벤트 메커니즘이 있다 비즈니스 분석 멀티-쓰레드를 통해 반응 능력 향상 - 최신 델파이 버전은 쓰레드를 훨씬 더 쉽게 다룰 수 있는 멋진 라이브러리와 클래스가 있다 그 외에도 흥미롭고 멋진 현대화 아이디어(들)이 있다.
  7. 현대화 마이그레이션을 할 때 수작업을 줄여주는 도구 - reFind.exe를 사용합니다. 그런데, reFind는 텍스트 파일을 변환하는 도구이므로 폼파일(*.dfm) 역시 텍스트 형식이어야 적용할 수 있습니다. 하지만, 델파이 7 이전 버전에서 만든 오래된 폼 파일은 바이너리 형식이므로 텍스트 형식으로 변환하는 작업이 선행되어야 refind를 사용할 수 있습니다. 이때는 RAD 스튜디오에 들어있는 convert.exe 를 사용할 수 있습니다. 용도: 폼 파일 (.dfm)을 바이너리에서 텍스트로 또는 텍스트에서 바이너리로 변환 실행 파일 위치: RAD 스튜디오를 설치하고 나면 RAD 스튜디오 실행파일이 들어있는 폴더 안에 convert.exe 가 들어 있음 사용법: https://www.oreilly.com/library/view/delphi-in-a/1565926595/re475.html convert.exe가 한글 이슈가 있다는 의견도 있고, 아무 문제가 없다는 의견도 있습니다. 혹시 한글 이슈가 있으면, 이 게시판에 문제가 있는 바이너리 형식의 dfm 파일을 제공해주기 바랍니다. 면밀히 파악해보겠습니다. 또는 볼랜드포럼의 박지훈님이 공개한 도구인 Impdfmconvert.exe를 이용하기 바랍니다.
  8. 실제 브라질의 운송회사에서 20년된 델파이 프로그램을 현대식 마이크로서비스 아키텍처로 전환한 사례를 바탕으로 진행한 세미나 자료입니다. 당면과제 브라질에서 가장 큰 로컬 운송회사에서 델파이6로 구축한 시스템을 15년간 회사의 매우 중요한 파트에서 운용해 왔다. 그간 회사는 크게 성장했지만, 클라이언트/서버 구조인 이 시스템으로는 더 이상 회사의 성장에 맞추어 확장하기 어려운 상황에 이르렀다. 시행착오 2014년 이후 회사는 두 번에 걸쳐 델파이가 아닌 다른 기술로 완전히 교체하려는 시도를 했다. 한 번은 SAP로, 다른 한 번은 Java(자바)로 시도했으나, 두 프로젝트 모두 실패했다. 그 기간 동안 기존 시스템은 20살이 되었고, 세번째는 더 이상 실패하면 안 되는 다급한 상황이 되었다. 해결 방안 및 결과 2019년 새롭게 구축한 시스템은 유연하면서도 확장성있고, 견고하며, 비용까지 절감해주고 있다. 현대식 시스템이며, 마이크로서비스 아키텍처가 적용되었다. 도커(Docker), 쿠버네티스(Kubernetes), 데브옵스(DevOps) 원칙이 반영되었다. 그리고 무엇보다 이 새 시스템은 델파이(Delphi)로 구축되었다. 이 영상을 통해 알 수 있는 내용 왜, SAP와 Java 두 번의 재구축 프로젝트가 실패했을까? 어떻게, 델파이 개발자 단 8명으로 구성된 팀만으로 외부 훨씬 더 큰 규모의 개발팀보다 빠르고 획기적인 결과를 만들어 낼 수 있었을까? 왜, 전환 프로젝트 비용이 시트릭스(Citrix) 비용 절감만으로도 충당되었을까? (다른 시스템에서는 못했는데) 이 새로운 시스템은 유연하게 확장되고, 빠르게 개발될 수 있었다. 아키텍처는 어떻게 되어 있을까? 이 영상을 통해 기존 시스템의 가치를 인식하고, 기존 시스템에서 마이그레이션 하는 것이 완전히 새로 구축하는 것보다 어떻게 그리고 얼마나 더 빠르고 더 안전한지를 확인할 수 있다. 시스템 아키텍처 해당 세미나에서 소개한 아키텍처를 조금 구체적으로 그려보면 다음과 같다. 이해하기 쉽도록 계층을 구분하고, 각 계층의 역할과 서비스 구성, 서비스들의 역할을 설명했다. 해당 세미나의 아키텍처 중 시스템 아키텍처를 제외한 개발 도구와 배포 환경은 다음과 같다. 사용된 기술 Access Layer 클라이언트 요청을 분산하고, 요청에 대한 서비스로 연결하는 게이트웨이 역할 Reverse Proxy & Load Balancer : REST API의 경로에 따라 구현된 마이크로 서비스와 연결 및 요청 분산 HTTPS : 보안 프로토콜 지원 Traefik : HTTP 리버스 프록시 및 로드 밸런서. REST API 수신 시 설정에 따라 하위 마이크로 서비스와 연결 HAProxy : 소프트웨어 로드 밸런서, 네트워크 스위치에서 제공하는 L4, L7 기능 및 로드 밸런서 기능 제공 참고> Naver D2 - L4/L7 스위치의 대안, 오픈소스 로드 밸런서 HAProxy Certbot : HTTPS 지원 Let's Encrypt : HTTPS 지원 Business Layer 운용에 필요한 기능을 마이크로 서비스 기반으로 제공. 핵심적인 비지니스 로직이 포함되며 다른 서비스들과 연동해 운용 RAD 서버 : REST API 서비스를 손쉽게 개발할 수 있는 턴키방식 미들웨어 서버. 델파이, C++빌더로 개발 Persistance Layer 서비스 운용에 필요한 데이터를 제공하는 역할 RDBMS, NoSQL : 마이크로 서비스는 서비스 분리와 함께 데이터 분리가 가능하다. 서비스 필요에 따라 RDBMS와 NoSQL 사용가능 Data Grid(IMDG: In Memory Data Grid) : 일종의 메모리 클러스터. 여러 서버와 메모리를 연결 수십기가의 메모리 저장소를 만들고, 애플리케이션 서버에서 접근해 사용하는 방식 Message Queue : 비동기 요청 처리. 클라이언트 요청을 메시지 큐에 넣고 응답 후 다른 서비스에서 메시지 큐의 내용을 처리 Oracle - RDBMS PostgreSQL - RDBMS MongoDB - NoSQL / BigData Redis - 메모리 기반 데이터 그리드. 서비스간 공유할 데이터를 메모리 기반으로 빠르게 조회 및 저장 RabbitMQ - 오픈소스 메시지 브로커. 서비스간 메시지를 큐잉하고 변경 시 이벤트를 받아 처리 가능 Analystics Layer 서비스 운용 시 발생하는 로그를 수집 분석하고, 서비스를 모니터링 및 장애 감지 역할 Log gathering / Analysis : 서비스들로 부터 로그를 수집, 저장, 분석 해 시각적으로 제공. Elastic(ELK) Stack 사용됨 Monitoring : 네트워크 및 서버 모니터링 및 장애 감지 및 알림 Logstash - 실시간 파이프라인 기능을 가진 데이터 수집 엔진 ElasticSearch - 분산형 RESTful 검색 및 분석 엔진 Kibana - ElasticSearch에 저장된 데이터를 검색 및 분석, 시각화 플랫폼 Zabbix - 네트쿼크 서비스, 서버 등을 감시, 추적 및 장애 알림 Grafana - 데이터를 시각화하여 효과적으로 데이터기반 의사결정 및 모니터링 가능 Prometheus - 이벤트 모니터링 및 경고. HTTP 풀 모델 사용이 특징 참고> 오픈소스 모니터링 시스템 prometheus #1 DevOps/Dev tooling RAD Studio Ranorex docker Sonar Gitlab Jenkins Deployment environment Ansible Kubernetes Ubuntu Rancher docker 다시보기
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.