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)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 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. 엠바카데로 블로그에 Atanas Popov 본부장이 쓴 "Modernize Your Apps"를 번역한 글 (원문 작성일: 2018년 2월 12일, 번역일: 2018년 2월 19일) 애플리케이션의 현대화는 델파이/C++빌더 개발자 대부분이 가장 중요하게 생각하는 주제 중 하나이며 꾸준하게 이야기 되고 있다. 지금까지 상당한 기간동안 델파이가개발자와 함께 있었고, 주위에는 델파이로 만들어진 훌륭한 "레거시" 앱들이 매우 많다. 오래 전인 델파이 7 시기에 만들어진 앱들도 여전히 사용 되고 있다. 이런 사실은 델파이가 개발 프레임워크로써 얼마나 품질 수준이 높은 지를 보여주는 증거이기도 하지만, 만들어 진지 10년이 넘은 앱 입장에서 보면, 글쎄... 너무 오래된 것이라는 점 역시 사실이다. 개발자들은 고객들에게 현대적이고 경쟁력 있는 앱을 제공하기 위해 델파이를 최신 버전으로 옮기고 있다. (역자 주: 델파이는 델파이로 만들기 때문에) 우리 역시 내부적으로 RAD 스튜디오 자체를 현대화하기 위해 같은 여정을 밟아 오고 있다. 현대화가 늘 쉽기만 한건 아니지만, 노력할 가치가 있다. 나는 엠바카데로가 이 과정에서 어느덧 상당한 진전을 이루었다고 생각한다. 그리고, 현대화의 여정을 계획하는 델파이 개발자들에게 도움이 될 수 있도록, 우리가 현대화 여정을 통해 직접 얻은 몇가지 교훈을 정리하여 공유해야겠다는 자신감이 생겼다. UI를 현대식으로 업데이트 하십시오 내 생각에 현대화 프로젝트에서 내가 가장 어려운 부분은 UI 현대화를 설득력있게 주장하는 것이다. 잘 작동한다면, 아이콘이 낡아 보이는 걸 신경쓸 사람이 누가 있냐고 말하는 사람들도 분명히 있다. 개발자 역시 종종 룩앤필(look and feel)을 신경쓰지 않는 경향이 있어서, UI 현대화에 열정을 쏟기 어렵다. 하지만, 현대화된 룩앤필(look and feel)의 영향은 너무나 크다. 우리는 지난 2년간 점진적으로 많은 현대화를 해왔으며 더 할 것들도 있다. 우리가 진행한 설문 조사에서 RAD 스튜디오의 룩앤필이 더 높은 우선 순위를 차지하는 경우는 거의 없다. "외형이 예뻐보인다"는 이유로 기업용 소프트웨어를 구입한다고 말하는 고객 역시 거의 없다. 하지만, UI 개선이 완성되면, 그것이 끼치는 영향은 놀랄만큼 크다. 특히 델파이로 만든 앱에서 그 영향이 더 큰데 그 이유는 "레거시"라는 편견이 함께 있기 때문이다. UI 현대화라는 싸움은 할 만한 가치가 있고 다행스럽게 VCL과 FMX 도구가 업데이트 되면서 UI 현대화를 구현하는 것이 더 쉬워졌다. 시간을 가지고 옳은 일을 하자. 전문 디자이너의 도움을 받는 것은 정말 가치있는 일이다 (다시 말하지만, 많은 개발자들이 잘 하지 못하는 분야이다). 멋진 고품질 아이콘의 영향을 간과하지 않도록 주의하자. 아래 그림은 우리가 10.2.2 버전을 만들 때 새로 업데이트한 아이콘(들) 중 일부이다. 델파이 바깥에도 값이 매우 싸면서도 좋은 것들이 정말 많다. 예를 들어, 나는 www.icons8.com 을 좋아한다. 모바일로 가십시오 델파이의 가장 큰 장점 중 하나는 바로 파이어몽키(FMX)이다. 스마트 폰 채택율이 증가함에 따라 (2018년까지 70% 수준까지 예상됨), FMX 또한 크게 증가할 것이다. VCL을 이미 알고 있다면, 비교적 자연스럽게 FMX를 사용하여 개발할 수 있다. 물론 FMX 만의 고유한 특징이나 스타일이 있으며, 솔직히 말해서 RAD스튜디오 작업 흐름은 좀더 더 개선될 여지가 있기도 하다. 하지만, RAD 스튜디오의 생산성은 놀라운 수준이다. RAD 스튜디오가 아닌 다른 기술인 경우에는 대부분 플랫폼 별로 팀을 따로 꾸리고 투자도 따로 하게 된다. 과거에는 모바일 앱을 하나의 패키지로 외부에 맡겼지만 지금은 달라지고 있다. FMX를 사용하면 해당 모바일 앱을 델파이 팀이 개발할 수 있다. 오래된 앱을 FMX로 다시 만들 필요는 없지만, 모바일로 갈 수 있도록 의미있게 확장하는 것은 필수다. 개발자는 엄청난 존경을 받게 될 것이고 델파이 기술은 현대적인 것이라고 당당하게 인식될 것이다. 개발팀이 꾸려질 수도 있다. FMX를 시작하는 데 도움이 되는 교육 자료들도 많다. 나는 개인적으로 델파이 스타일(Delphi Styles)를 좋아한다. 아주 매끈하게 맞춤형 룩앤필을 구현할 수 있기 때문이다 (아래 그림은 www.delphistyles.com 에서 골라 온 FMX 스타일 템플릿이다). "멀티-티어(Multi-Tier)"로 만드십시오 아키텍처(구조)는 간단한 문제가 아니다. 안타깝지만, 훌륭한 개발자 조차도 다른 분야에 대한 지식이 없을 수도 있다. 이건 그저 소프트웨어 개발 안에 워낙 방대한 분야가 있다는 단순한 이유 때문이다. 따라서 데스크탑 앱을 멀티-티어로 옮기기 등 아키텍처 변경을 해내는 것은 경험이 가장 많은 개발자에게 조차도 새로운 학습 경험이 될 수도 있다는 의미이다. 학습한다는 것 또는 도움이 되는 외부 지원을 받는 다는 것은 언제나 좋은 일이다. 엠바카데로는 쉽게 아키텍처를 전환할 수 있도록 하는 것을 목표로 한다. 예를 들어, RAD 서버는 멀티-티어 아키텍처를 지원하는 능력이 뛰어나다. 오래된 앱을 멀티-티어 관점에서 다시 생각하는 것이 (과거에 어떻게 구축되었는 지에 따라 다르기 때문에) 아무런 보장이 없긴 하지만 그다지 벅차거나 두려운 일은 아니다. 처음에는 겁이 많이 났지만, 일단 들어가 보니, 전환 작업이 예상보다 훨씬 적었다고 나에게 말한 개발자들이 많았다. 확실히, 이렇게 전환하면 자바 등 완전히 다른 언어로 플랫폼을 바꾸는 것에 비해 비용이 훨씬 적게 든다. 다시 말하지만, 한가지 간단한 접근 방식은 가능한 작게 시작하고 가능한 많이 모듈화하는 것이다. 또한 너무 서두르느라 VCL 고객을 잃지 않도록 하자. 애플리케이션이 제공하는 속도는 복제되지 않는다. 특히 몇초가 매우 중요한 민감한 환경이라면 더욱 주의해야 한다. VCL 앱을 자바로 재구축하고도, 사용자들이 받아들이지 않은 몇백억원 짜리 프로젝트는 내가 아는 것만 몇개나 된다... 엄청난 낭비이다. "웹화(Webify)" 하십시오 아마 무슨 의미인지 바로 이해했을 것이다. 델파이로도 할 수 있는 방법이 오늘날 많이 있다. 가장 이상적인 방법은 계층으로 나눠진 앱을 만들고 독립적인 웹 클라이언트를 구축하는 것이다. 물론 우리는 Ext JS를 추천한다. 우리 제품 중 하나이기 때문이다. 하지만, 다른 클라이언트 웹 기술도 좋은 것들이 많다. 또 다른 방식이 더 빠를 수도 있는데 UniGui와 같은 도구를 사용하는 것이다. UniGui는 VCL 방식으로 개발하면서도 웹 클라이언트를 빌드할 때 Ext JS를 활용한다. 모든 경우에 효과가 있지는 않지만 매우 빠르고 생산적이다. 개발자가 앱의 모듈을 빠르게 만들어서 웹에서도 델파이가 잘 그리고 빠르게 효과를 발휘한다는 것을 보여 줄 수 있다는 점은 확실하다. 오늘날 델파이 앱과 연결되는 웹 인터페이스들은 닷넷(.NET)으로 구축된 것이 많다. 둘 다 윈도우와 연관되어 발전했기 때문이다. 물론 이것도 효과는 있지만, 우리의 최근 경험과 새 JS 기술을 바탕으로 볼 때, JS를 통해 얻을 수 있는 속도와 유연성은 엄청나다. 통합하십시오(Integrate) RAD스튜디오에는 가장 뛰어난 통합 프레임워크(들)과 컴포넌트(들)이 들어있다. 다른 기술(들)이 가장 어려워하는 점들 중 대표적인 것이 바로 '통합'이다. 이점에서 우리는 정말 우월하고 빠르다. 최근 설문 조사에서 우리 고객 중 FireDAC을 채택한 고객의 비중이 엄청 높았다. 멋진 일이다. 개발한 현대식 앱이 더 많은 통합을 할 수 있도록 하는 새로운 방식을 찾아야 한다. ERP 시스템에서 재고를 가져와서 보여주거나 정보를 받아본다면 어떨까? 엔터프라이즈 커넥터스(Enterprise Connectors)는 FireDAC 프레임워크를 기반으로 한다. 그리고 이런 통합을 매우 잘 해낸다. 우리는 ExtJS로 포탈을 만드는 내부 프로젝트를 할 때 엔터프라이즈 커넥터스를 사용하여 우리의 SFDC(세일즈포스, Salesforce.com)에 연결했다. "와!" 하는 탄성이 나오는 개발 경험이었다. 혁신하십시오(Innovate) 델파이에는 푸쉬알림, 비콘, Woll2Woll 모바일 편집기(www.woll2woll.com/beam) 등 많은 기능이 새로 추가되었다. 윈도우 10의 새 기능을 사용하는 개발자가 거의 없다는 점은 매우 놀랍다. 잘 활용되지 못하고 기술 중에서 내가 가장 좋아하는 것은 비콘(Beacons)이다. 이것들은 지금 "무료로" RAD 스튜디오 엔터프라이즈 에디션 안에 들어있다. 비콘 모바일 편집기는 이 비콘 기술을 사용하는 모바일 앱을 개발하는 속도를 높인다. 위치 데이터 수집을 활용하는 기업용 델파이 앱들이 매우 많다는 점을 감안하면, 델파이 앱 안에 넣는 것이 당연할 만큼 쉽고 멋진 기능이다. 그리고 델파이에서 최고 장점은 이런 혁신을 실현하기 위해 수억원의 비용을 들일 필요가 없다는 점이다. 레거시라는 주장을 넘어서십시오 이점은 엠바카데로가 RAD스튜디오에 들이는 노력과는 관계가 없는 내용이겠지만, 어쨌든 델파이 고객들 각자가 극복해야 할 장애물이다. 델파이는 레거시라는 인식은 여전하다. 최근 이런 인식을 극복하려는 노력이 있긴 하지만 아직까지도 마찬가지이다. 최근, 나는 살짝 다르게 접근해보았는데 매우 성공적이었다. 이제 나는 델파이가 가진 많은 장점들을 변호하려고 깊이 들어가지 않고, 사실 몇가지만 말한다. 그리고 더는 변호하지 않는다. 효과가 있다! 오늘날 델파이는 가장 큰 상업용 개발 생태계 중 하나이다 - 경기가 악화되고 지원이 감소함에 따라 많은 오픈 소스들이 추진력을 잃었다. 델파이가 가장 빠르고, 가장 사용하기 쉽고, 가장 기능이 뛰어난 개발 도구라는 사실은 말할 필요가 없다 (약간 주관적이긴 하지만.. 사실이다!). 윈도우 개발용인 VCL 프레임워크는 MS 윈도우를 네이티브로 지원하는 기능을 가장 많이 유지해오고 있다. VCL을 이기는 건 없다. FMX는 잠마린(Xamarin) 보다 네이티브 크로스 플랫폼 지원 능력이 더 좋다. 그 인기는 특히 안드로이드 앱 개발 측면에서는 빠르게 증가하고 있다. 내 생각에 기술 위험을 관리하고자 하는 회사라면 델파이와 VCL을 선택하는 것이 시중에 있는 최신 기술과 최신 프레임워크를 선택하는 것보다 훨씬 더 안전하다.앵귤러(Angular)를 여러번 반복하거나 Java 마이그레이션에 엄청나게 쏟아 부어본 경험을 해 본 사람에게 물어보기만 하면 바로 알 수 있다. 매우 생산성이 높은 언어와 재사용할 수 있고 프론트-엔드와 백-엔드에 유연하게 작업할 수 있다는 점이 델파이에게 강력한 기술 경쟁력을 제공한다. 글쎄, 처음 의도보다 글이 다소 길어졌다. 하지만 현대화(Modernization)에서 넘어서기에 아마도 가장 어려운 점이 하나가 있는데, 다시 말하지만, 기술이라기 보다는 오히려 인식의 문제이다. 고객은 델파이 교육을 받은 쓸만한 개발자가 부족하다는 점을 계속 주장한다. 안타깝지만, 여전히 사실이다. 숙련된 델파이 개발자 수는 다른 인기있는 기술에 비해 더 적다. (역자주: SI 업체 등) 아웃소싱 회사는 델파이 같은 도구에 특히 부정적인데, 델파이의 생산성이 자신들의 사업 모델과 직접적으로 반대되는 경향이 있기 때문이다. 자바 개발자 50명을 팔 수 있는데 그 대신 델파이 개발자 5명을 팔 이유가 없다. 이것 역시 우리가 이기는 주장이다. 델파이 개발자는 그렇게 많이 필요하지 않다 - "그만큼" 좋다. 델파이 개발자가 자신의 기술을 닦아야 하거나 새 팀을 교육해야 하는 한, 우리는 엠바카데로 아카데미(Embarcadero Academy)를 계속해서 발전시키고 더 많은 컨텐츠와 과정을 붙여나갈 것이다. 우리 경험 상 고급 개발자라면 델파이를 정말 빠르게 익힌다. 현대적인 멋진 앱을 만들어서 기술 비관을 날려버리자.
  2. 엠바카데로 마이그레이션 센터 홈페이지에서 가장 강조하는 비디오인 Top 5 Considerations when Migrating Your Projects to RAD Studio 10.4 Sydney를 한글로 요약 번역한 글 (비디오 게시일: 2020년 7월 21일, 번역일: 2020년 9월 5일) Al Mannarino와 Mary Kelly는 고객사 수백곳에서 델파이 업그레이드 컨버전 작업을 도왔습니다. Al과 Kelly가 꼽은 "델파이 마이그레이션 프로젝트에서 당면한 Top 5 고려사항과 대응책"을 5등부터 1등까지 알아봅니다. 델파이 마이그레이션 프로젝트에서 당면한 Top 5 고려사항 Al Mannarino Mary Kelly 5. Runtime 오류 해소 4. 미들웨어 3. 데이터베이스 전환 2. 유니코드 1. 써드파티 라이브러리 5. UI 현대화 (윈도우10 포함) 4. 미들웨어 3. FireDAC 2. 유니코드 1. 써드파티 라이브러리 5위 (Al 선정) Runtime 오류 해소 마이그레이션 후, 경우에 따라 Runtime 오류가 발생할 수 있다. 런타임 오류가 발생하는 경우는 주로 폼의 프로퍼티가 이전 버전에는 있었지만 새 버전에서 없어졌거나, 윈도우에서 더이상 제공되지 않는 오래된 dll을 사용하는 경우이다. 이런 오류는 애플리케이션을 실행해보기 전에는 알 수 없다. 까다로운 경우의 예를 들면, 오래된 써드 파티 라이브러리를 사용했는데 이 오래된 컴포넌트가 폼 디자이너에서 (제작 당시에는 델파이 폼디자이너에 있던 속성인) 그리드의 ColumnCount 속성을 사용했다면 애플리케이션을 실행하면 “그리드에서 ColumnCount라는 프로퍼티를 찾을 수 없습니다”라는 오류가 발생한다. 소스 코드에서 ColumnCount라는 변수를 찾으려고 해도 소스 코드에서 찾을 수 없는데, 왜냐하면 ColumnCount는 소스 파일 (델파이라면 .pas)이 아니라, 폼 파일(델파이라면 .dfm)에 있기 때문이다. 따라서 dfm 파일을 열어서 ColumnCount를 찾아서 삭제 또는 수정해야 한다. (Mary 선정) UI 현대화 (윈도우10 포함) UX는 뜨거운 관심을 받고 있다. 사용자에게 최상의 UI나 UX를 제공하는 것은 이제 매우 중요해졌다. 오래된 애플리케이션은 윈도우 10에서 작동된다고 해도 화면이나 사용 방식이 윈도우 10과 이질적이다. 개발자는 마이크로소프트에서 새로 소개한 기능을 반영, VCL 스타일 적용, 모바일 환경에 맞게 변화 등을 원한다. 마이그레이션이 끝나고 사용자가 가장 먼저 만나는 것은 화면이다. 화면을 봤을 때 매력적이지 않다면, 아무리 많은 개선이 있었다고 해도 사용자에게 전달되지 않는다. 개발자는 사용자가 새 애플리케이션을 기쁘게 받아드리기를 바라기 때문에 시작적으로 매력적인 애플리케이션을 제공하고 싶어한다. 10.4에는 여러가지 VCL 스타일들이 들어 있다. 원하는 것을 선택하면 사용자에게 새로운 룩앤필을 적용할 수 있다. (Stephan Ball의 의견: 화면 변경은 사실 매우 큰 변경 작업이라서 5위보다 순위가 높을 것이라고 생각했다. 하지만, RAD 스튜디오에서는 스타일을 이용하여 반영하면 쉽게 해소되는 문제라서 5위인 것으로 생각된다) 4위 (Al 선정) 미들웨어 오래전 델파이에서 사용된 미들웨어는 COM기술을 기반으로 한 Midas였다. 하지만 지금은 데이터스냅(DataSnap)과 RAD서버가 사용된다. Midas를 사용하여 구축된 멀티티어 애플리케이션은 COM에 대한 종속성을 없애야 한다. 대응책으로 반제품인 데이터스냅 또는 완제품인 RAD서버로 마이그레이션을 들 수 있다. 전환 방법은 “Midas에서 데이터스냅으로 전환하기” 와 “데이터스냅에서 RAD서버로 전환하기” 기술 백서에 잘 설명되어 있으므로 잘 활용하기 바란다. (Mary 선정) 미들웨어 애플리케이션을 웹과 모바일로 확장하는 추세이다. RAD서버나 데이터스냅을 도입하게 되면 기존의 애플리케이션 기술 뿐만 아니라 사용자 기반까지도 웹과 모바일로 확장할 수 있기 때문에 미들웨어에 대한 요구가 많다고 생각한다. 3위 (Al 선정) 데이터베이스 전환 마이그레이션을 할 때, 항상 데이터베이스 마이그레이션이 수반된다. BDE를 사용하는 애플리케이션이 아직도 얼마나 많은지 알고 놀랐다. BDE는 델파이 3,4,5 시절의 엔진이고 당시의 파라독스나 dBAse를 연결할 때 사용되었다. BDE는 지원이 중단된지 15년이 넘었고, 그동안 계속해서 BDE에서 벗어날 것을 권장해왔는데도 불구하고 (각자 나름의 이유가 있었겠지만) 여전히 BDE가 많이 사용되고 있다. BDE는 사용하지 말아야 한다. 왜냐하면 15년 전에 중단되었을 뿐만 아니라, 유니코드와 64bit를 지원하지 못하기 때문이다. BDE는 훨씬 새로운 고성능 컴포넌트인 파이어닥(FireDAC)으로 전환해야 한다. reFind라는 유틸리티는 BDE 구문을 찾아서 FireDAC으로 전환하기 때문에, BDE를 FireDAC으로 매우 쉽게 거의 자동으로 전환할 수 있다. 시간 낭비할 필요없이 reFind를 사용하자. (Mary 선정) FireDAC으로 이전 나도 역시 여전히 BDE 사용자가 많아서 놀랐다. 마이그레이션 시에는 반드시 BDE를 제거해야 한다. 특히 윈도우10에서 BDE는 완전히 멸종된 기술이라서 항상 문제가 될 것이다. reFind를 사용하면 쉽게 FireDAC으로 전환할 수 있다. 게다가 파라독스 같은 오래된 DB에서 사용하던 방식 즉 테이블을 열어서 필터링을 하는 방식을 벗어나야 한다. SQL구문을 활용해 DB를 다루고, 데이터 액세스 방식과 내용 면에서 보다 효율적으로 데이터베이스를 사용하기 바란다. 요즘은 데이터 보안이 강조된다. 따라서, 파일과 데이터 액세스 암호화에 대한 관심이 매우 높다. FireDAC으로 전환하면 SQL서버, 인터베이스, 오라클 등 견고한 데이터베이스를 사용할 수 있고 이런 DB들이 제공하는 수준 높은 기능을 사용할 수 있게 된다. (tephan Ball의 의견: BDE 이외에도 DBExpress와 ADO도 여전히 사용되지만 역시 보안 등의 측면에서 FireDAC으로 전환할 것을 권장한다) 2위 (Al 선정) 유니코드 유니코드는 흥미로운 주제이다. 개발자들은 유니코드 반영이 매우 어려울 것이라고 생각하지만 실제로는 그렇게 어렵지는 않다. 가장 먼저 해야할 질문은 “유니코드가 꼭 필요한 애플리케이션인가 아니면 영어버전으로만 계속 사용해도 충분한가”이다. 만약 영어버전만 사용한다면 String 이나 Unicode String 대신, Ansi string 타입을 사용하면 된다. 하지만 유니코드로 가고 싶다면 Unicode Statistics라는 도구를 사용하라. 이 도구는 유니코드 전환 복잡도를 측정하고, 전환 시 변환되어야 하는 코드가 무엇인지를 알려준다. String을 많이 사용했다고 걱정하는데 오해이다. 전혀 손댈 필요가 없는 경우도 많다. 유니코드 변환은 string을 어떻게 사용했는가에 따라 달라지는 것이지 코드의 모든 string을 변환해야 한다는 의미는 아니다. 컴파일러는 똑똑해서 유니코드 변환이 필요한 곳을 알려준다. 경험 상 유니코드 전환은 생각보다 훨씬 쉽다. 일단 유니코드로 전환하고 나면 영어권 밖으로 진출할 수 있다. 컴파일을 하면 컴파일러가 ansi string과 string 타입이 서로 맞지 않는다는 오류를 표시하므로 쉽게 파악할 수 있다. 컴파일러는 타입 변환(캐스팅, casting)을 할 수 있다. 하지만, 컴파일러가 확신할 수 없기 때문에 에러를 표시하는 것이다. 따라서, 가장 쉬운 방법은 컴파일러가 알려주는 해당 타입으로 변환하는 것이다. (Mary 선정) 유니코드 유니코드 반영은 작업이 크고 가장 어렵다. 예를 들어 C++을 업그레이드 하려다보면 C++03 표준에서 C++17 표준으로 크게 넘어가는 경우가 많다. 이때 언어 표준에서 그동안 어떤 변화가 있었는지를 알아야하고,단순히 에러만 해소하도록 고쳐나가는 것이 좋을 지 아니면 코드 일부를 아예 다시 작성하여 유니코드 반영 뿐만 아니라 C++의 새 기술을 적용하여 향상할 수 있도록 하는 것이 좋은지를 고민하게 된다. (Mary의 의견: docwiki에는 유니코드 전환 시 제공되는 컴파일러의 에러 코드에 대한 설명과 해소법이 있다. 이것을 활용하면 좋다) 1위 (Al 선정) 써드파티 컴포넌트 마이그레이션을 준비할 때 가장 먼저 해야 할 질문은 “사용하고 있는 써드파티 컴포넌트가 무엇인가?” 이다. 써드파티 라이브러리와 플러그인 역시 모두 다시 컴파일되어야 하기 때문이다. 소스코드가 있다면 더 쉽다. 소스를 가져와서 다시 빌드하면 된다. 소스코드가 없는 것들은 현재 개발툴에서 작동하는 버전을 찾아서 그 버전을 사용해야한다. RAD스튜디오(델파이, C++빌더) 개발툴 안에 있는 겟잇 패키지 매니저에서는 써드파티 기술 250여가지가 제공된다. 여기에서 검색을 하면 해당 개발툴에서 작동이 보장되는 버전을 찾아을 수 있으며 겟잇에서 바로 설치할 수도 있다. 겟잇 패키지 매니저를 잘 활용하면, 각 써드파티 마다 새 버전을 찾기 위해 인터넷을 뒤지는 수고 뿐만 아니라 찾아낸 버전이 현재 개발툴에서 작동되는 지를 일일이 확인 하는 수고를 덜 수 있다. JEDI, 터보파워 등 오픈 소스 써드파티 뿐만 아니라 TMS, Woll2Woll 등등 상업용 유료 써드파티인 경우 평가판이 제공된다. (Mary 선정) 써드파티 컴포넌트 동감이다. 마이그레이션을 준비할 때 가장 먼저해야 할 작업은 사용하고 있는 써드파티 컴포넌트를 확인하는 것이다. 소스 코드가 있으면 다시 컴파일을 하면되지만, 소스 코드가 없는 것들은 업그레이드된 버전을 찾아야 한다. 만약 이 두 경우에 해당되지 않는다면 곤란할 수 있다. 이때는 고생해서 억지로 끼워맞추기 보다는 오히려 TMS, DevExpress, JEDI 등으로 옮기는 것이 더 쉽고, 마이그레이션 후 결과적으로 더 애플리케이션이 더 향상된다. 엠바카데로 마이그레이션 센터(영문) : https://www.embarcadero.com/rad-in-action/migration-upgrade-center 데브기어 마이그레이션 센터(한글): https://www.devgear.co.kr/rad-in-action/migration-upgrade-center * 데브기어 마이그레이션 센터(한글)는 엠바카데로(EN)의 정보를 번역한 곳이 아닙니다. 따라서 두 곳을 모두 참고하면 도움이 됩니다.
  3. 이 문서의 목적: DocWiki에 있는 [DocWiki 번역] BDE 애플리케이션 마이그레이션 따라하기 (FireDAC) 문서가 실제로 따라하기에 다소 불편하게 되어 있어서, 내용과 틀을 유지하면서, 따라하기 쉽게 보강함 중요! 미리 알아둘 점: Hub 페이지: BDE 애플리케이션을 FireDAC으로 이전하는 방법: 이 문서의 상위 문서로써 실습 뿐만 아니라 팁과 대응 요소 등이 잘 정리되어 있다. 이 문서와 비슷한 문서: [DocWiki 번역] BDE 애플리케이션 마이그레이션 따라하기 (FireDAC): 두 문서 모두 1~ 8단계와 동일하다. 이 실습의 "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에서 사용할 연결 정의를 생성해야 한다. 이 예제에서는 FDExplorer 유틸리티, 즉 '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으로 이전" 관련 사항이 잘 정리되어 있다.
  4. 델파이 설치시에 함께 제공되는 reFind 커맨드라인 프로그램을 사용하여 DBExpress 컴포넌트를 FireDAC 컴포넌트로 자동 변환 하는 방법입니다. 영상에 사용한 샘플은 MySQL 데이터베이스를 사용 하였고 DBGrid에 테이블 데이터를 조회하는 간단한 샘플입니다. 데모영상 사용되는 컴포넌트 비교 DBExpress 사용 프로젝트 (reFind로 변환하기 전) FireDac 사용 프로젝트 (reFind로 변환한 후) 참고로 FireDAC 에서는 DBGrid 사용시 TDatasetPorvider 와 TClientDataSet 없이도 TDataSource 에서 TSQLTable 이나 TSQLQuery로 바로 연결이 가능하므로 TDatasetPorvider 와 TClientDataSet 를 사용하지 않아도 됩니다. reFind 사용법 문서 [따라하기] reFind 도구를 이용해 BDE 프로젝트를 FireDAC으로 마이그레이션 따라하기를 참고하세요. 위 동영상을 이해하는 데도 도움이 됩니다. reFind 사용법은 동일하며, 반영할 "규칙 파일"(BDE용과 DBExpress용 모두 RAD 스튜디오 설치 시 함께 제공됨)만 다릅니다.
  5. 이 문서의 목적 데브기어 마이그레이션 지원 사업(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은 자동으로 로그를 남기게 됨 (참고자료는 작성 중)
  6. 델파이 7에서 11.0으로 마이그레이션하고 있습니다. 델파이 7에서 문제없던 아래 코드가 11.0에서 오류가 납니다. shortdateformat := 'yy/mm/dd'; dateseparator := '/'; 오류메시지 [dcc32 Error] : E2003 Undeclared identifier: 'shortdateformat' 어떻게 해소할 수 있을까요?
  7. 이 문서의 목적: 마이그레이션을 할 때 수작업을 없애는 도구 중 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에서 선택된 폴더 안에 있다.
  8. 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
  9. "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을 통한 데이터 연결 보안 앱 아이콘(들)을 만들어서 배포 앱 활성화 및 비활성화 이벤트 - 최신 델파이 버전에는 표준 이벤트 메커니즘이 있다 비즈니스 분석 멀티-쓰레드를 통해 반응 능력 향상 - 최신 델파이 버전은 쓰레드를 훨씬 더 쉽게 다룰 수 있는 멋진 라이브러리와 클래스가 있다 그 외에도 흥미롭고 멋진 현대화 아이디어(들)이 있다.
  10. 현대화 마이그레이션을 할 때 수작업을 줄여주는 도구 - 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를 이용하기 바랍니다.
  11. 실제 브라질의 운송회사에서 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...

중요한 정보

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