'분류 전체보기'에 해당되는 글 144건

1. 원본 데이터베이스 스키마 스크립트 생성

   스크립팅 옵션 설정에서 [고급]버튼을 눌러 기본키, 외래키, 인덱스등도 포함되도록 설정

2. 타겟 데이터베이스에서 같은 이름으로 데이터베이스 생성

   생성 옵션 중 데이터정렬을 원본 데이터베이스와 같게 맞춘다.

3. 스키마 스크립트를 불러와 실행

4. 원본 데이터베이스에서 데이터 내보내기 기능을 이용

   자동증가 ID가 있는 테이블은 해당 테이블 마다 [매핑편집]버튼을 클릭하여 [ID입력 가능]을 체크해준다. SET IDENTITY_INSERT TableName ON

http://stackoverflow.com/questions/20948819/error-0xc0202049-data-flow-task-1-failure-inserting-into-the-read-only-column

http://movie.naver.com/movie/bi/mi/basic.nhn?code=137978

아버지이기 전에 인간으로서 되돌릴 수 없는 실수를 저지른 것에 대한 가족간의 갈등을 잘 그렸다.

막내는 아버지의 오만과 고집 편견등을 이해하며 화해하는 듯했으나 죽은 친구를 대한 아버지의 행동은 끝내 용서하지 못한다.

막내가 아버지의 실수를 용서했다면 아버지가 자살까지 했을까하는 아쉬움이 남는다.

아버지가 자살하기 전 회상하며 중얼거리는 내용에서 얼마나 막내를 사랑했는지 알 수 있다.

내기준이지만..

LHX

스트리트파이터2

버추얼파이터

인디애나존스

페르시아의 왕자

듄2

둠2

에버퀘스트

XCOM

문명2

심시티

아래와 같은 방법으로 CURSOR의 기능을 대체할 수 있다.

--Declare the Table variable 
DECLARE @Elements TABLE
(
    Number INT IDENTITY(1,1), --Auto incrementing Identity column
    ProductName VARCHAR(300) --The string value
)

--Decalre a variable to remember the position of the current delimiter
DECLARE @N INT 

--Decalre a variable to remember the number of rows in the table
DECLARE @Count INT

--Populate the TABLE variable using some logic
INSERT INTO @Elements SELECT Name FROM dbo.Products

--Initialize the looper variable
SET @N = 1

--Determine the number of rows in the Table
SELECT @Count=max(Number) from @Elements

--A variable to hold the currently selected value from the table
DECLARE @CurrentValue varchar(300);

--Loop through until all row processing is done
WHILE @N <= @Count

BEGIN
    --Load current value from the Table
    SELECT @CurrentValue = ProductName FROM @Elements WHERE Number = @N
    --Process the current value
    print @CurrentValue
    --Increment loop counter
    SET @N = @N + 1;
END

http://www.codeproject.com/Articles/34142/Understanding-Set-based-and-Procedural-approaches

http://semver.org/

독립적인 응용 프로그램 보다는 라이브러리를 위한 것인데요. 간단히 요약하면

* 버전 번호는 기본적으로 x.y.z.r 형식이고 x, y, z, r 은 숫자.

* x는 주(major) 번호로, 라이브러리가 노출하는 공개 API에 '하위 호환성 없는 변화'가 생겼을 때 증가

* y는 부(minor) 번호로, 공개 API에 '하위 호환성 있는 변화'가 생겼을 때 증가

* z는 브랜치 구분

* r은 공개 API의 변화가 없는 버그 교정이나 내부 개선 시 증가.

이 제안의 요지는, 버전 번호 변경 방식(또는 버전 번호의 '의미론')에 대한 합의가 있으면 외부 라이브러리를 사용하는 프로그램의 갱신이나 유지 보수가 쉬워진다는 것입니다. 

예를 들어 Bar라는 라이브러리의 1.2.0.3 버전을 사용해서 Foo라는 프로그램을 만들었다고 할 때, 나중에 Bar가 1.2.0.4(버그 교정)나 1.3.0.0(하위 호환성 보장)으로 갱신된 경우 Foo의 개발자는 Foo를 변경할 필요가 없음을 바로 알 수 있습니다. 소프트웨어 설치/의존성 관리 프로그램들도 이를 기계적으로 알 수 있겠고요.

https://indidev.net/forum/viewtopic.php?f=2&t=115 류광님 답글에 의견을 덧붙임

1. 장기

 1) 주가곡선 그래프는 장기적으로 우상향

 2) 최소 3년

2. 적립식

 1) 조정을 심하게 받을수록, 주가곡선이 심하게 요동칠수록 적립식투자의 결과는 좋다.

 2) 적립식펀드에 가입하자마자 주가가 떨어지기 시작한다면 손뼉 치며 기뻐하자. 3년도 필요없다.

3. 분산

 1) 수익률의 변동성을 줄여 누적수익률을 높인다.

 2) 상관계수가 양수이면서 적당히 낮은 펀드들을 잘 조합?

투자에 실패하지 않고 오랜 기간 남아있다는 것은 곧 큰 수익을 얻을 기회가 많아지는 것을 뜻함

4. 환매타이밍

 1) 목표수익률을 정하고 달성되면 미련없이 환매

로컬 버전 관리 시스템

대부분의 사람들이 버전 관리를 위해 쓰는 방법은 파일을 다른 디렉토리에 복사하는 것이다(똑똑한 사람이라면 디렉토리 이름에 시간을 넣을 것이다). 이 방법은 간단하고 자주 사용되는 방법이지만 실수가 발생하기 쉽다. 어느 디렉토리에서 작업하고 있었는지 잊어버리고 엉뚱한 파일을 덮어쓰거나 의도하지 않았던 위치로 복사할 수도 있다.

이 문제를 해결하기 위해 오래전에 프로그래머들은 간단한 데이터베이스에 파일의 변경 사항을 기록하는 로컬 버전 관리 시스템을 만들었다(그림 1-1 참조).

그림 1-1. 로컬 버전 관리 다이어그램

유명했던 VCS 도구들 중 현재에도 널리 쓰이는 것으로 RCS라 불리는 시스템이 있다. 그 예로 Mac OS X 운영체제에서는 개발 도구를 설치하면 RCS가 딸려온다. RCS의 기본적인 동작 방식은 각 리비전들 간의 패치 세트(patch set)라고 하는 데이터의 차이점들을 특별한 형식의 파일에 저장, 특정 시점의 파일 내용을 보고 싶을 때 해당 시점까지의 패치들을 모두 더하여 파일을 만들어내는 것이다.

중앙집중식 버전 관리 시스템

또 다른 문제는 시스템 외부에 있는 개발자들과 함께 작업하는 것이다. 중앙집중식 버전 관리 시스템(Centralized Version Control System; CVCS)은 이 문제를 해결하기 위해 개발됐다. CVS, Subversion, Perforce와 같은 시스템들이 여기에 속한다. CVCS에서는 버전 관리되는 모든 파일을 저장하는 하나의 서버와, 이 중앙 서버에서 파일들을 가져오는(checkout) 다수의 클라이언트가 존재한다. 오랫동안 사용된 이 방식은 지금까지도 버전 관리의 대표적인 방식이다(그림 1-2 참조).

그림 1-2. 중앙집중식 버전 관리 다이어그램

CVCS는 로컬 VCS에 비해 장점이 많다. 누구나 다른 사람들이 무엇을 하고 있는지 알 수 있고, 관리자는 누가 무엇을 할 수 있는지 꼼꼼하게 관리할 수 있다. CVCS를 관리하는 것은 수많은 클라이언트의 로컬 데이터베이스를 관리하는 것보다 훨씬 쉽다.

그러나 CVCS는 심각한 단점이 있다. 중앙 서버가 잘못되면 모든 것이 잘못된다는 점이다. 서버가 다운될 경우 서버가 다시 복구될 때까지 다른 사람과의 협업도, 진행 중이던 작업을 버전 관리하는 것도 불가능해진다. 중앙 데이터베이스가 저장된 하드디스크에 오류가 발생하고 백업도 없다면, 사람들이 각자 자신의 컴퓨터에 가지고 있던 스냅샷 외에는 그동안 쌓인 프로젝트의 이력을 모두 잃게 된다. 로컬 VCS 시스템도 같은 문제가 있다. 프로젝트의 모든 이력이 한곳에만 있을 경우 이것은 피할 수 없는 문제다.

분산 버전 관리 시스템

분산 버전 관리 시스템(Distributed Version Control System; DVCS)은 앞서 말한 문제를 해결하기 위해 개발되었다. Git, Mecurial, Bazaar, Darcs 등 DVCS에서는 클라이언트가 파일들의 마지막 스냅샷을 가져오는 대신 저장소(repository)를 통째로 복제한다. 따라서 서버에 문제가 생겨도 어느 클라이언트든 복제된 저장소를 다시 서버로 복사하면 서버가 복구된다. 체크아웃(checkout)을 할 때마다 전체 백업이 일어나는 셈이다(그림 1-3 참조).

그림 1-3. 분산 버전 관리 시스템 다이어그램

게다가 대부분의 DVCS에서는 다수의 원격 저장소(remote repository)를 갖는 것이 가능하기 때문에 동시에 여러 그룹과 여러 방법으로 함께 작업할 수 있다. 이로 인해 계층 모델(hierarchical model) 등 중앙집중 시스템에서는 할 수 없는 다양한 작업 방식(workflow)들을 사용해볼 수 있다.

http://git-scm.com/book/ko/v1

 Visual Studio 2010 을 사용중 /MP 스위치를 사용 할 수 있다는것을 깜박하고 있다가 진행 중인 프로젝트에 적용을 시켜 보았다.

프로젝트 옵션 -> C/C++ -> 일반 -> 다중 프로세서 컴파일에 예(/MP ) 옵션을 켜고 컴파일 시작.

Gm 스위치와 호환이 안되므로 MP 를 무시한다고 나옴..

프로젝트 옵션 -> C/C++ -> 코드 생성 -> 최소 다시 빌드 가능 항목의 /Gm 옵션을 아니오 (/Gm-) 로 바꿔준 다음

다시 컴파일을 진행...

error C2813: /MP를 지정하면 #import를 사용할 수 없습니다.

으엌.. ㅠㅠ

프로젝트에서 사용중인 ADO dll 을 import 해서 사용중인데 MP 스위치와 import 옵션을 동시에 사용 할 수 없다고 MSDN 에서도 명확하게 말하고 있음..

그래도 난 쓰고 싶은데.. 그래서 찾아 봄.

#import 구문을 통해 사용하는 dll 은 COM 으로 이루어진 dll 이기 때문에 tlh 같은 Type Library Header 가 분명 생성이 됨

다음과 같은 과정을 거치면 import 구문을 빼고 include 구문으로 변경해서 MP 스위치를 사용 할 수 있다.

1. tlh 파일 추출하기

#import "C:\Program Files\Common Files\System\ado\msado15.dll" no_namespace rename("EOF", "adoEOF") rename("BOF", "adoBOF")

구문을 그대로 두고 컴파일을 진행 한다.

컴파일이 성공하면 Object 파일들이 생성 되는 Debug 폴더 또는 Release 폴더로 가보자.

#import 처리기가 하는 역할이 dll 에서 tlh 를 추출하여 헤더 파일에 그대로 붙여 넣는 작업을 해주는 역할이기 때문에 Debug 폴더나 Release 폴더에 가보면 다음과 같은 파일이 보일것이다.

각각 용량은 167KB, 146KB 정도로 꽤 큰편이다.

위 두파일을 복사해서 #import 구문을 사용했던 소스와 동일한 경로에 붙여넣기 한다.

#import ".........

코드를 다음과 같이 변경한다.

#include "msado15.tlh"

이렇게 하면 #import 로 추출된 tlh 파일을 include 하는 구조이기 때문에 동일한 역할을 수행한다.

/MP 스위치를 켜고 빌드 -> 솔루션 다시 빌드 를 선택하여 컴파일을 진행해 보면 또 컴파일 실패가 된다.

msado15.tlh(5025): fatal error C1083: 포함 파일을 열 수 없습니다. "....\msado15.tli': No such file or directory"

하지만 컴파일 오류 내용을 잘 보면 포함 파일을 열 수 없습니다. 라고 나오는것을 알 수 있기 때문에 tlh 파일 안에서 msado15.tli 파일을 찾을 수 없다 라는 오류를 알 수 있다.

msado15.tlh 파일을 메모장등의 에디터로 열어보자.

편집 -> 찾기 메뉴를 이용하요 .tli 를 찾아 보면 거의 끝부분에서 다음 줄을 찾을 수 있다.

//
// Wrapper method implementations
//

#include ".......\debug\msado15.tli"

앞 경로는 개인정보 보호상 삭제..

Full Path 로 된 #include  문을 찾을 수 있는데 바로 이 부분의 경로가 Debug 폴더까지 들어가 있어서 파일을 찾을 수 없는것으로 나오는것이다.

경로를 #import 문이 있는 소스의 경로로 수정한 다음 다시 한번 컴파일 해보면

제대로 컴파일 되는것을 확인 할 수 있다.

진행중인 프로젝트의 소스는 약 9500 라인의 C++ 소스이며 /MP 적용을 하지 않고 컴파일 하면

1:21초 정도의 컴파일 진행시간이 소요 된다.

/MP 적용후에는 31초로 시간이 단축 되는것을 확인 할 수 있으며

즉, 다음과 같다.

다음과 같이 CPU 도 Full 로 사용하는것을 볼 수 있다.

다들 /MP 옵션을 이용해서 컴파일 시간을 줄여 보아요~~!

http://blog.acidpop.kr/96