docwiki 번역 [DocWiki 번역] BDE 애플리케이션을 마이그레이션 할 때 고려할 몇가지 추가 사항

[Kori]

Docwiki에 있는 "Additional Migration Hints (FireDAC)"를 번역한 글 (번역일: 2022년 3월 2일)

위로 가기: BDE 애플리케이션을 FireDAC으로 이전하는 방법

목차

힌트 1

힌트 2

힌트 3

힌트 4

힌트 5

힌트 6

힌트 7

힌트 8

힌트 9

힌트 10

힌트 11

---

힌트 1

아래의 프로퍼티를 완전히 제거해야 한다. FireDAC에 대응되지 않는 것들이다.

• SessionName을 완전히 제거해야 한다. 하지만 주의하라! 당신의 애플리케이션에서 같은 이름으로 된 연결을 여러 다른 세션에서 사용하고 있을 수도 있다.
•  PrivateDir을 완전히 제거해야 한다.

주의: 이 작업은 FireDAC_Migrate_BDE.txt 변환 규칙 파일에 이미 정의되어 있으므로, 마이그레이션 작업을 reFind 도구를 사용하여 자동 변환 할 때 이 파일을 사용하면 된다.

힌트 2

BDE의 TTable에 대응되는 것은 FireDAC의 TFDTable이다. 하지만, 마이그레이션을 할 때에는 TTable을 모두 TFDQuery로 바꿀 것을 권장한다. 

힌트 3

BDE 애플리케이션에서 영속 필드(Persistent Field)를 사용하고 있다면, 맞춰주는 작업을 추가로 해야 한다. BDE에서는 영속 필드에서 Origin 프로퍼티와 ProviderFlags 프로퍼티, 그리고 고유 식별 필드를 얻기 위해 DB 딕셔너리 조회를 제공하거나 사용하지 않는다. FireDAC에서는 영속 필드에서  Origin 프로퍼티와 ProviderFlags 프로퍼티를 사용할 수 있다. FireDAC_Migrate_BDE.txt 마이그레이션 스크립트에서는 .dfm 파일에 있는 TField.Origin 값을 모두 떼어낸다. FireDAC은 Origin이 비어있는 경우(DBE 애플리케이션에는 당연히 없다), 해당 필드의 Name을 사용한다. 하지만, ProviderFlags의 기본 값에는 pfInKey가 포함되지 않으며, FireDAC은 해당 DB에서 PK 필드를 쿼리하지 않는다. 따라서, 고유 식별 필드를 얻지 못한다. 개발자는 다음 조치 중 하나를 추가로 진행해야 한다.  

• Recreate persistent fields (영속 필드 재생성 하기).
• Manually adjust ProviderFlags (ProviderFlags를 수동으로 맞추기).
• Manually specify UpdateOptions.KeyFields (UpdateOptions.KeyFields를 수동으로 명시하기).

힌트 4

코드 조각, 참고용:

Screen.Cursor := crSQLWait;
try
  ......
finally
  Screen.Cursor := crDefault;
end;

아래와 같이 바꾼다.

uses
  FireDAC.Stan.Factory, FireDAC.UI.Intf;
  ......
var
  oWait: IFDGUIxWaitCursor;
  ......
  FDCreateInterface(IFDGUIxWaitCursor, oWait);
  oWait.StartWait;
  try
    ......
  finally
    oWait.StopWait;
  end;

 

힌트 5

BDE API과 직접 대응하는 FireDAC API가 없다. 따라서, BDE API를 직접 사용하는 코드가 있다면, 해당 코드에서 FireDAC API를 사용하는 코드로 다시 작성해야 한다. 다른 방법은 없다.

힌트 6

써드-파티 제품, 예를 들어 리포팅 제품이나 멀티(Multi)-티어용 라이브러리를 사용하려면 DAC 어댑터 유닛이 있어야 한다. 해당 써드-파티 제품 공급자에게 요청하여 해당 어댑터를 구하자.

힌트 7

EDBEngineError는 BDE에만 있는 고유한 예외(Exception) 클래스이다. 이에 대응하는 FireDAC의 클래스는 EFDDBEngineException이다. BDE에서는 예외를 다룰 때, 개발자가 ErrorCode 프로퍼티를 사용하여 에러 타입을 얻었다. FireDAC에는 해당 프로퍼티 타입이 이미 있고 열거형(enumerated) 값을 반환한다.

if E is EDBEngineError then
begin
  case EDBEngineError(E).Errors[0].ErrorCode of
    DBIERR_KEYVIOL: MetaBaseDBError(SMb_DataSetInvalidPKeyValue, E);
end;

아래와 같이 바꾼다.

if E is EFDDBEngineException then
begin
  case EFDDBEngineException(E).Kind of
    ekUKViolated: MetaBaseDBError(SMb_DataSetInvalidPKeyValue, E);
end;

 

힌트 8

(BDE의) TBatchMove와 (FireDAC의) TFDBatchMove 컴포넌트는 여러 면에서 크게 다르다. TBatchMove 컴포넌트를 사용했다면, 해당 코드를 새로 작성해야 한다.

 

힌트 9

(FireDAC의) TFDConnection.OnLogin 이벤트와 (BDE의) TDatabase.OnLogin는 파라미터 목록이 서로 다르다. 예를 들어, 아래와 같이 핸들러 코드를 바꿔야 한다.

procedure TMyDataModule.dbLogin(Connection: TFDConnection; LoginParams: TStrings);
begin
  LoginParams.Values['USER NAME'] := 'me';
  LoginParams.Values['PASSWORD'] := 'pwd';
end;

아래와 같이 바꿔야 한다.

procedure TMyDataModule.dbLogin (AConnection: TFDCustomConnection; const AConnectionDef: IFDStanConnectionDef);
begin
  AConnectionDef.UserName := 'me';
  AConnectionDef.Password := 'pwd';
end;

 

힌트 10

애플리케이션에서 BDE에서 이기종 쿼리를 사용한다면, FireDAC에서는 Local SQL을 사용해야 한다.

 

힌트 11

BDE 멀티-쓰레딩을 활성화하기 위해, 애플리케이션에서 TSession.AutoSessionName 프로퍼티를 True로 지정했을 것이다. FireDAC은 이름 기반 세션 방식을 지원하지 않는다. 따라서, 애플리케이션에서 TFDQuery.ConnectionName (이름을 사용하여 바인딩)을 사용하지 말고 TFDQuery.Connection (참조를 사용하여 바인딩) 사용 하도록 바꾸자. 더 자세한 설명:  multi-threading application development with FireDAC.