프로시저?


많이 쓰는 SQL 쿼리들을 미리 정의해서 컴파일 해 놓은 SQL 집합 혹은 그룹이다. 


성능, 보안, 유지관리가 용이하다는 장점이 있다. 


DB파일이 예전 백업본이라서 SP가 없다.. 우짜노........


디비를 확 내려서 백업받을 수도 없고... ㅠㅠㅠㅠㅠ


참고 :

http://msdn.microsoft.com/ko-kr/library/ms187926(v=SQL.100).aspx


http://gomdolinara.com/dokuwiki/doku.php/dev/dbms/mssql/procedure



------------------------------------------------------------------


VPN 접속해보니까 프로시저 파일이 있당 ㅎㅎㅎㅎ

근데 쿼리 날리니까 이미 존재하는 프로시저라는데.. 

MS SQL 안에 프로그래밍 기능 - 저장 프로시저 - 시스템 저장 프로시저 가니까 다 있넿ㅎㅎㅎ

삽질 왕 b


org.apache.ibatis.exceptions.PersistenceException:
### Error querying database.  Cause: com.microsoft.sqlserver.jdbc.SQLServerException: 호스트 192.168.0.78, 포트 1433에 대한 TCP/IP 연결에 실패했습니다. 오류: "Connection refused: connect. 연결 속성을 확인하고 SQL Server의 인스턴스가 호스트에서 실행되고 있고 포트에서 TCP/IP 연결을 허용하고 있는지 확인하십시오. 또한 포트에서 TCP 연결을 차단하고 있는 방화벽이 없는지 확인하십시오.".
### The error may exist in com/maeil/cvo/sqlMap/Login.xml
### The error may involve Login.getLogin
### The error occurred while executing a query
### Cause: com.microsoft.sqlserver.jdbc.SQLServerException: 호스트 192.168.0.78, 포트 1433에 대한 TCP/IP 연결에 실패했습니다. 오류: "Connection refused: connect. 연결 속성을 확인하고 SQL Server의 인스턴스가 호스트에서 실행되고 있고 포트에서 TCP/IP 연결을 허용하고 있는지 확인하십시오. 또한 포트에서 TCP 연결을 차단하고 있는 방화벽이 없는지 확인하십시오.".
예외 발생 : null====java.lang.NullPointerException
예외 발생 :
예외 발생 : /login.do

 

하............... 이거 고치려고 TCP/IP 포트 열고 서비스 실행 중인지 확인하고 MS SQL 설정 백번하고...

결론은

 sql server configuration Namager 의 TCP/IP 속성의 IP ALL 값의 TCP 포트값을 1433으로 변경하면 된다!!!!

함 니ㅡ란 ㅇ허 ㅠㅠㅠㅠ 똥멍청이 ㅠㅠㅠ

평소에 이렇게 바보는 아닌데.. 똑소리 난다는 얘기 많이 듣는데.. 아닌가 .. ㅋㅋㅋㅋ

아무튼 신입사원은 똥멍청이고 일년 지나야 멍청이 된다는 얘기를 몸소 체험중인 입사 삼주째 신입 ㅠㅠ 슬프다 ㅠㅠㅠ

MS SQL은 한번도 안해본건데.. 하니까 되긴되네 ㅠㅠㅠㅠㅠ

 

http://www.golinuxhub.com/2013/07/the-tcpip-connection-to-host-127001.html

'DATABASE > MS SQL' 카테고리의 다른 글

테이블 복사 쿼리  (0) 2013.09.25
저장 프로시저 만들었음.  (1) 2013.09.10
[펌] 프로시저 만들기  (0) 2013.08.29
일반 쿼리문과 저장 프로시저의 차이점  (0) 2013.08.21
Store Procedure (저장 프로시저)  (0) 2013.08.13
CRUD 의 중요도? DATABASE 2013. 8. 2. 16:44

데이터베이스의 CRUD 중 가장 중요한 것은 무엇일까?

중요도에 따른 상중하를 나눠보자. 



나는 처음에 

Select    下

Insert     

Update    

Delete    上


이라고 생각했다. 

PK 에 FK 엮이고 하면 아무래도 업데이트나 삭제가 복잡해지니까..?


근데 여기에는 함정이 있다. 


중요도에 따른 상중하를 나눠보자고 했지만, 그 기준을 제시하지 않았다. 

위의 상중하는 만들때 얼마나 쿼리가 귀찮은가를 기준으로 중요도를 결정한거같다.


데이터 정합성을 기준으로 CRUD의 중요도를 다시 매긴다면 어떨까?



Select    下/

Insert     

Update    中/

Delete    上


으로 매길 수 있다고 본다. 


select 의 경우 쿼리를 잘못 뽑는다고 해서 DB에 있는 값이 변하지 않기 때문에下,

中일때는 통계성 쿼리일 때이다. 이 통계가 맞는지 틀린지를 검증하기 위해서는 일정 시간이 소요되기 때문.


insert 나 delete 는 잘못 집어넣거나 지운 데이터가 있다면 select고 뭐고.. 일단 아 망했어요 라고 보면 된다 ^^!

잘못 된 데이터를 가지고 쿼리를 아무리 작성해봤자, 정확한 결과값이 나오지 않기 때문


업데이트의 경우에도 중~상의 중요도를 차지하는 이유는 역시 데이터 정합성때문 . 


쿼리는 어렵다 ㅠㅠㅠㅠㅠㅠ 열심히 하자