Microsoft SQL Server 総合スレ 11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Microsoft SQL Server (Transact-SQL) の総合スレッドです。
・Microsoft 公式サイト
http://www.microsoft.com/japan/sql/
過去スレとかめんどいから誰か適当に貼って >>569
結構前のVerだとインスコ時に明示的に追加してやらんとならんかったような
>>570
1ステートメントあたりの文字数制限はあった気がする
それ以内なら何千万行でも問題ない SSMSをインストールしたら誰でもDBにログインできるってなら
俺のPCは世の中の全てのSQL Serverにつながるのかね >>572
どういうバカの思考回路だとそんな結論になるのかちょっとだけ気になるよ 他人の夢の中にログインできるDC mini が欲しい >>573
>SSMSってインストールしたユーザーならWindows認証は必ず通れると思っていた >>575
ああそうか「ユーザー」をキミ自身のことだと考えたわけか
なかなか新鮮な文脈解釈だと思うよ LinuxでSSISをインストールしたいんだけど、エディッション選択で何を選んでも
”Could not write Licensing information”と出て先へ進めない。
SQL Server本体の時はDevelopper Editionを問題なくインストールできたのになんでよーー >>577
エラーメッセージを素直に解釈すれば、パーミッションの問題たろうに。 >>571
バージョン聞くの忘れたけど多分2008か2012なんだよね
調べてみます
ありがとう >>81
>>390
昨日現象が出て、今スレ開いたらそのものずばりの人がいてやったーと思ったらまだ解決してねえ! 全くの無知からSQLサーバーの担当になりました。
データベースからデータを引っ張ったりして資料作成する業務なんですが、いい勉強方法ありませんか?
引き継ぎも無しに任されたので混乱してます >>582
とっつきやすいのはMSの自習書あたりかね 作成したDBをSSMSで削除したいのですが、使用中で削除出来ない場合があります。
最悪、サーバーを再起動すれば削除出来るんですが、簡単に削除する方法はありますか? >>586
それあかんやつやろ
ハッキングされとんで SMS 17使っていて、更新があると出るのでクリックするとダウンロードサイトが開くが
通常のインストーラーしか見当たらない。Updateはどこにあるの? >>584
使用状況モニターから掴んでいるプログラムを強制終了 ライセンスの話で恐縮ですが
SQL Server2016のライセンスを解説します
http://sql-oracle.com/sqlserver/?p=363
で
1.SQL Server 2016 Standard 4コア 1,017,000円
2.SQL Server 2016 Standard 日本語版 サーバー ライセンス 111,000円
3.SQL Server 2016 クライアント アクセス ライセンス(1CAL) 27,000円
という参考価格が出てます。実際の価格は別にして、4コアのサーバーで運用するとき
(1017,000-111000)÷27000≒33.6
と求まり、つまり34ユーザー以上だったら、1. で買った方が得、ということで合ってますか?
実際のクライアント数は50台ちょっとです。 グループ会社が絡む複雑な話だったらマイクロに相談するけど
よくある中小企業のサーバー1台、クライアント50台ちょっと、という実に普通の話だもんで グループ会社が絡んでも別に複雑じゃないけどクロソにはとりあえず相談するだろ >>595
コアライセンスのがいいね
ただ今後SQLServer増やす予定があるならcalは他のサーバーでも
使えるのでサーバーcalライセンスのほうがいい その辺りのライセンス云々は富士通とかベンダ解説資料がぐぐると良く引っかかるよね
同じようなことしたけど、VL価格とか出てくると更に訳がわからなくなって辛かった記憶有るわ ALTER TABLE テーブル名
SET ( LOCK_ESCALATION = DISABLE )
やってもエスカレーションするぽいんだが
データベースエンジン再起動させないと反映されないの?
begin transaction
update テーブル set 項目=なんとか where 主キー=XX
select 項目 from テーブル where 主キーじゃない項目 = YY ← これが通らない
ちなみに
select 項目 from テーブル with (nolock) where 主キーじゃない項目 = YY
だと当然にして即座に通る ちなみに 主キーじゃない項目 = YY は 主キー=XX とは全く別レコード
2行目のupdateした直後にロックのかかり具合を見ると
type=PAGE、request_mode=IX と type=KEY、 request_mode=X
がそれぞれ、数個出現してる SELECTで行ロックしたいのかどうかがわからない。
あなたの説明だと行ロックしたいのか、ただロックエスカレーションをどうにかしたいのか、なんだかわからない。 >>74-79
この辺に、Accessファイルをリンクサーバで使う話が出てますけど、SQLServerが64bitでAccessが32bitの時の方法を知っている方いませんか
SQLServerも32bitならできることは確認しています
> ACE.OLEDBってのがあって、これは64ビット版もある
これも試してみましたが、うまく使えていません
動作確認のために純粋な64bit環境を用意してみようとも考えていますが、Officeはしばらく32bit版を使う必要があるので、純粋な64bit環境に移行は当分できません
アドバイスをお願いします >>604
ここみて32bitのAccessDatabaseEngine.exeをインストールすればよい
http://plus-sys.jugem.jp/?eid=446
officeの64bitが入ってたら一旦アンインストールすれば普通にインストールできる >> 602
ロックエスカレーションを止めたかどうかまずは確認しろ
https://www.projectgroup.info/tips/SQLServer/MSSQL_00000016.htmlhttps://www.projectgroup.info/tips/SQLServer/MSSQL_00000016.html >>605
ここのリンク先は参考にならないわ
sqlserverやosのbitは無視して使いたいaccessファイルのbit基準でAccessDatabaseEngine.exeを
msからダウンロードしてインストールすればよい >>605>>607
Officeが既に32bit版なので、32bit版のACE.OLEDBは入っていたので、32bit版のAccessDatabaseEngine.exeはインストールしたことはありませんでした
試してみます
レスありがとうございました 普通に32ビットのACCESS入れたら
32ビットのSQLServerクライアントも入ったと思ったがなぁ もしかして、SQLServerからACCESS(のデータベース)にリンク張りたいって話か?
だったらSQLServerと同じビット数のACE入れないとダメだぞ
SQLServer(64ビット)入れたサーバに、32ビットACCESSも入れたらなら
ACEの64ってサポートされてないはず
どうしてもやりたいなら>>605のリンク先 >>601
ALTER TABLEでLOCK_ESCALATION = DISABLE したとしても
ロックエスカレーションが完全に禁止されるわけじゃないぞ
そもそも、そのselectとupdateは同じトランザクションなのか?
分離レベルは何でやってるのとか色々考慮点はあるんだが >>602
インテントロックは行レベルで取得されない気がしたんだがなぁ
そもそも、ページにIXかかっても、そのページにIXロックかけれるんだぜ
(もちろん行単位のロックが競合しないとか条件はあるが) >>603 >>611
selectは行ロック不要です。
ただ問題としたいのは
最初のupdateにより、その1行はロックされるのは当然にして
全く別の行のSELECTができなくなる(ロックされて読めない)、っていう挙動が解せないという話です。
たった1行のupdateに対して、かなり広範囲にロックかかってる気がしてならないのです 一つ考えられるのは、
updateで1行を更新するとき、その項目はインデックス(非クラスタ)の一部になってます。
まさかインデックスに使われている項目を更新すると
さながらテーブルロックのような状態になるなんてことないですよね? >>614
インデックスの項目更新したらインデックスの再構成しないと遅くなりそう
インサートとデリートでインデックス項目変更したほうがいいんじゃね >>613
だからIXロックはIXロックをブロックしない
IXロックがブロックの直接の原因じゃない
たとえばファントムリード防止したかったら、範囲ロックせざるを得ないんだが
そのあたり理解してる? >>605>>607>>609>>610
自己解決できました
32bit環境で機能していたのは確認していましたが、32bit版のACE.OLEDBはなくJET4.0だったので、32bit環境でACE.OLEDBでためしたところうまき行きませんでした
結果は、64bit環境と同じエラーで、セキュリティの問題でした
JET4.0では使えるのにACE.OLEDBではダメと言う状況で、SQLServerの実行アカウントをネットワークサービスアカウントではなく、ローカルのユーザにして対応できました >>613
それぞれ別レコードで、かつUPDATE、SELECTの順に行う理由がわからない。
別のレコードであればSELECTしてから、UPDATEでもいいんじゃないのか?
またはUPDATEしたあとにコミットしてからSELECTすればいい。 >>614
nolockオプションつけてやってみれば?
ただし一瞬消えてしまうようですがリンク参照
http://bxdxmx.hatenablog.com/entry/20090828/1251444766
内部的にはdelete とinsertでやってるからロックされているかも 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
SEPQX7O4N7 テーブルの中のカラム名のうち、Identity属性を持っているものを取り出す方法
はありますか? sys.columnsでis_identity=1のもの検索すれば良いんじゃね 初めてインストールしたは良いけど、起動して新規のデータベースをつくるにはどうするのかが分からん(-_-;) >>625 さん、ありがとうございます。
SSMSというのをインストールして起動したら、なんか分かるような気がしてきました。
Accessとそんなに変わらんだろうって勝手に思ってたので焦ってます(笑) 焦らんでも中身はAccessとそんなに変わりなく使えるから落ち着いてどうぞ ACCESSはフロントエンドとDBMSと一体だからな
SQL ServerはDBMSだけだし
ACCESSからSQL Server使うでもいいんじゃない
まっさらな新規DB作るのだけ苦労するかもしれんが >>629
編集画面のこと言ってるなら無理だと思う やりすぎ防犯パトロール、特定人物を尾行監視 2009年3月19日19時7分配信 ツカサネット新聞
http://headlines.yahoo.co.jp/hl?a=20090319-00000026-tsuka-soci
この記事で問題になった通称やりすぎ防パトは、創価学会と警察署が引き起こしていたようです
掻い摘んで説明すると
・創価学会は、町内会や老人会、PTA、商店会等の住民組織に関し、学会員が役員になるよう積極的に働きかける運動を
90年代末から開始し、結果、多くの住民組織で役員が学会員という状況が生まれた
・防犯パトロールの担い手は地域の住民と住民組織で、防犯活動に関する会議や協議会には、住民組織の代表に役員が出席する為
防犯活動や防パトに、創価学会が間接的に影響力を行使可能となった
・防パトは住民が行う為、住民が不審者や要注意人物にでっち上げられるトラブルが起きていたが
創価学会はその緩さに目をつけ、住民組織を握っている状況を利用し、嫌がらせ対象者を不審者や要注意人物にでっち上げ
防パトに尾行や監視、付き纏いをさせるようになった
・防パトは地元警察署との緊密な連携により行われる為、創価学会は警察署幹部を懐柔して取り込んでしまい
不審者にでっち上げた住民への嫌がらせに署幹部を経由して警察署を加担させるようになった
・主に当該警察署勤務と考えられる創価学会員警察官を動かし、恐らく非番の日に、職権自体ないにもかかわらず
私服警官を偽装させて管轄内を歩いて回らせ、防犯協力をお願いしますと住民に協力を求めて回り
防犯とは名ばかりの、単なる嫌がらせを住民らに行わせた(防犯協力と称し依頼して回っていた警察官らの正体は恐らく所轄勤務の学会員警察官)
※これに加えて防犯要員が同様のお願いをして回る
・こうして防犯パトロールを悪用し、住民を欺いて嫌がらせをさせつつ、創価学会自体も会員らを動員し、組織的な嫌がらせを連動して行った
つまり警察署に勤務する学会員警察官、警察署幹部、創価学会が通称やりすぎ防犯パトロールの黒幕
詳細は下記スレをご覧下さい
やりすぎ防犯パトロールは創価学会と警察署の仕業だった
https://rio2016.5ch.net/test/read.cgi/bouhan/1516500769/ SELECT "User"."id" AS "User__id", "User"."company" AS "User__company",
"User"."name" AS "User__name", "User"."itaric" AS "User__itaric",
"User"."system" AS "User__system", "User"."year" AS "User__year"
FROM "public"."users" AS "User" WHERE 1 = 1 ORDER BY "User"."itaric" asc,
"User"."system" desc
複数ソートを実行したいのだけれども、実行できてる?? >>633
意味のないダブルクォーテーションと、意味のないWHERE句の条件と、複数ソートという謎の用語がわからない。 ダブルクォーテーションはOracleから持ってきたからなのかも
複数ソートは複数キーのことかも
Whereはよくわからん
って言うか何を言いたいのかよくわからん w メディアオプションを[追加]にしてジョブで毎日バックアップしていますが
これだとどんどんバックアップファイルのサイズが大きくなってしまうので
常に最新の10日分だけ残すというバックアップの方法を教えてください
よろしくお願いします >>634
意味のないレスすんな
答えられんのなら黙ってる事だな >>637
仮定の話をするのはIT技術者ではない。 Where 1 = 1 だけでSQLがまったくわかってないことがわかる。 「WHERE 1 = 1」は↓みたいに書いとくと任意の行をコメントにするだけで条件の入れ替えが簡単に出来るから開発時はたまにやるかもw
WHERE 1 = 1
AND フィールド1 = '○○○'
AND フィールド2 = '△△△'
AND フィールド3 = '□□□' >>646
ゼロはオーと打ち間違えやすいので避けたい
テンキーなら間違えないが
ノートパソコンだとゼロとオーは隣あっていて打ち間違えやすい >>647
見間違えるのはわかるけど打ち間違えってw
それおまえだけだからwwww where 1=1はsql文の慣例句みたいなものでgoogleで検索してもいっぱいでてくる。そんな事で悩む必要はない。
http://kinocolog.com/where11/ 100文字以内のデータしか入れない場合には
nvarchar(100)
で良いですよね?
質問1
全角文字で半角文字でも100文字入るんですよね?
質問2
nvarchar(max)
にすると無駄にメモリやハードディスクを使いますか? 回答1
Yes
回答2
No
varcharは可変長だから入ってる分だけの消費 >>653
ありがとうございました。
>varcharは可変長だから入ってる分だけの消費
では、カラムが10文字でも100文字でも
とりあえずnvarchar(max) を使っておけば良いのでしょうか?
どういう場合にnvarchar(100) などを使うのでしょうか? index張らないならMAXでもいい
張るなら900バイト以下でなければならない 教えてください。
テーブルA に製品の情報がたくさん登録されています。
この中から、不特定多数の特定の文字列で始まらない名称の製品を検索したいと思います。
条件が固定であれば次のような SQL を書けます。
SELECT *
FROM [テーブルA]
WHERE NOT ( [NAME] LIKE 'A%' OR [NAME] LIKE 'B%' OR [NAME] LIKE 'C%' )
条件(先頭の文字)を動的に変更するとしたら、
上のをストアドにしてパラメータで与えるとか、
条件をテーブルに保存しておくなどがあると思うのですが、SQL の書き方がわかりません。
どうするのが一般的か、教えてください。 テーブル型を引数にして
where not Left([NAME], 1) in (select [Word] from @引数)
みたいな風かな
ASCII しないといかんかもしれん >>657,658
ありがとう。
どっちのやり方も知らなかったです。
とりあえず 658 さんの方法を発展させてやってみようと思います。
657 さんの動的 SQL は便利すぎ。 一時テーブルに検索文字列セットして
left joinでlike 演算子で連結してnull のものだけ取ればいいように思える
https://teratail.com/questions/65949 >>659
動的SQLはできるだけ使わないように。条件の組み合わせが大量になければ、静的SQLで書く。動的SQLはSQLの組み立て方によっては、可読性、保守性がさがり、さらにコーディングミスをおこし、スペースを入れわすれた等おかしなSQLを簡単に仕込んでしまう。 >>656
それ単にパラメータによって、LIKE用の文字列を作り分けておけばいいだけ。 >>660
ありがとう。
left join で like って使えるんですね。
その結果が null のモノだけって発想がありませんでした。
こちらをまず試してみます。
>>661,662
ありがとう。
うん、そう思って動的 SQL は最後の手段にしとこうかと。 こうしてまたバカのバカによるバカのためのバカノウハウが広まるのであった スマートな解決策書けてりゃ格好いいんだけどなぁ...
>>664だとバカの遠吠えにしかなってない w 結局、RDBになるとSQLが魔法になってプログラムの見た目はシンプルでも、RDBMSの処理が複雑になるようなものを作るやつが多すぎる。
RDBの処理が汚なくなり、無意味に負荷がかかるようなプログラミムを書いても、RDBMSの処理がどう処理しているのか考えないから、珍妙なことを推奨する。 >>665
そのスマートな解決策()が動的SQLなんよ
バカには難しいらしいけんどねw データベース板はレベルが低い。リレーショナルデータベースに詳しくもないのにこうだ、これが正解だと言いはる人間ばかり。 せめてどこがどう「無意味に」負荷がかかってるのか書けないのかね >>670
検索結果が同じSQLでも、RDBMSではSQLの構文解析(ソフトパース、ハードパース)が行われ、実行プランも作り直しなることもあり、RDBMS側の処理が変化する。
プログラムだと結果は同じなのに、こうすると遅い、速いや、意味のないコードを書くと文句を言うくせにSQLになると、とたんにRDBMSもプログラムだということを忘れているか、理解していない。
SQLは魔法ではない。 ■ このスレッドは過去ログ倉庫に格納されています