2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Access2000+SQL Server難しい・・・(´д`;)

1 :1:01/10/03 17:04
今までACCESSのみでフォームやレポートを作成するときワーク
テーブルを作成しそれをレコードソースとして作成していました。
しかし、ADOではクライアントにワークテーブルを作成する事が
できないですよね。
皆さんはこの辺をどういう方法で処理していますか?
本によるとストアドプロシジャーを使って対応できるとか書いてあり
ますがいまいち方法はわかりません。

2 :ACCESS超初心者:01/10/03 20:57
私もこれ やりかた探してるんですが・・・
Transact-SQLのヘルプで CREATE TABLE ってあるんですが、ここに「一時テーブル」っていうのがあるんです。
クライアント側に作るんじゃないけれど 同じような使い方ができそうなんですけれど・・・
ストアドの中で作ってその間だけしか使えないと プログラム全体(フォームとか)をストアドの中で
呼ばないと使えないのかな?
とか・・・ よくわからないのです。
ヘルプの意味もよくわからない・・・ (/_;)

どなたか詳しい方いらしたら教えてください!!
わたしからも よろしくお願いします!! m(u_u)m

3 :名無しさん@そうだ選挙にいこう:01/10/03 22:48
クライアントにワークのmdb作るだけじゃないのか?
ado接続もできるんだし。

4 :ACCESS超初心者:01/10/04 02:09
あれ? 私は1の方の書いてる意味を 勘違いしてたみたいです。

ワークテーブルってテンポラリーのテーブル=一時テーブルのことだと思っちゃいました。

スミマセン 自分が一時テーブル使いたくて探してたもので「同じ質問の人がいる〜」って
思ってしまいました。
こちらも ご存知でしたら 教えてください、お願いします。

5 :名無しさん@そうだ選挙にいこう:01/10/04 02:33
>>1 フォームのレコードソースにするだけならビューを使えばいいのでは。
   またはSQL文を直接レコードソースにいれれば。

>テンポラリーのテーブル=一時テーブル
って何のために??フォームをストアドで呼ぶというのもよくわからん。
ストアドはデータベース側で動くもので、
クライアントはコマンドとパラメータを渡すだけだよ。

何がやりたいかを書けばレス付くのでは?

6 :名無しさん@そうだ選挙にいこう:01/10/04 05:52
>>2
一時テーブルはクライアントがDBを閉じるまで有効だったと思います。
ストアドの実行方法を理解されてることを前提に書きます。

SELECT ・・・ INTO ##テーブル FROM テーブル WHERE 1 = 2
とか
CREATE TABLE ##テーブル (・・・)

とかで、とにかく'##'の付いたテーブルを作ると一時テーブルができるわけで、
##テーブルをフォームのレコードソースにできます。
ストアドの中でデータ作って参照だけならそれだけでいいけど、
フォームでデータを編集する場合、主キーが必要だったように思います。

ALTER TABLE ##テーブル
ADD CONSTRAINT PK_テーブル
PRIMARY KEY (キー)

って感じで主キーを作ります。
フォーム閉じる時は一時テーブルを消さないといけませんね。

DROP TABLE ##テーブル

間違ってたらスマン

7 :1:01/10/04 10:02
早速たくさんの人たちに書きこんで頂いて喜んでおります。

>>2
多分、同じ悩みだと思いますので問題解決にご協力をお願いします。

>>3
現在の開発環境はAccess2000を.adpで作成し使用しています。.adpで使用すると
接続できるデーターベースはSQL Serverのみでクライアントにワークテーブルも
作れないし、他のmdbとも接続できないようなのです。
ここが間違いで何かの方法があれば教えて頂きたいのです。
今日から、Accessを.mdbで作成し、SQL Serverのデータをodbc接続してDAOで
開発しようかなーとも思っています。

>>5
例えば、フォームのレコードソースにビューやSQL文をいれて使用した時、同じ
フォームを別のパソコンでも開いたときに問題が生じるという事はないのでしょ
うか?まだ、実験まで至ってなく頭の中で考えて多分問題が起きるのではないか
と迷っています。
フォームをストアドで呼ぶという事の質問なのですが、ストアドのレコードセット
をフォームやレポートにいれて使用できる。みたいな事が書いてあるのですが、
この方法が理解できないし、他のパソコンでも同じストアドを使用されたときに
問題がおきるのではないかと思うのです。

>>6
この時、テーブルはクライアントに出来るのでしょうか?
もし、サーバー側に出来たとした場合、他のパソコンでも同じ処理をしたときに
同じテーブル名が作成され問題を生じるという事はないのでしょうか?

Accessでは実績があるのですが、SQL Serverは今回が初めてで困っています。
最初からACCESS2000を.adp(プロジェクト)+SQL Server2000と書くべきでした
納期が迫っているので今回は.mdb+SQL Server2000で行こうと思います。

ただ、この件は解決方法を見つけたいと思っていますので、チョットしたきっかけ
でもいいですので今後とも宜しくお願いします。

8 :6:01/10/04 12:54
>>1
一時テーブルはサーバー側に出来ます。
クライアント毎に作成され、他のクライアントからは見えません。
同じテーブル名の問題はありません。

>>6の方法は、私は明細型の伝票入力等で使っています。

 ・フォームオープン前にストアドで一時テーブル作成
 ・伝票修正・削除の場合はストアドで該当レコードを一時テーブルに転送
 ・連結型の帳票フォームオープン(サブフォームだったりします)
 ・明細編集後の決定ボタンのアクションで明細テーブル更新処理のストアドを実行
 ・フォームクローズ時に一時テーブル削除

といった感じです。

mdbは分散型アプリケーションで、adpはホスト集中型アプリケーションの
ような感じですかね。
adpで大量のレコードを処理する場合に、ローカルマシンでやるような
VBAだけでの処理なんてことをさせると、ネットワークに負担を掛けて
しまいますので、少々面倒ですが適切にストアドを使う必要があります。
adp+SQLはmdb+SQLに比べてテーブルのオープン等の処理が速いように
思います。

ついでに、
ストアドをフォームやレポートのレコードソースにする場合、

Alter Procedure ストアド
(
@パラメータ1 nvarchar(10),
@パラメータ2 nvarchar(10)
)
As
SET NOCOUNT ON

CREATE TABLE ##テーブル (・・・)

 <処理>

SET NOCOUNT OFF

SELECT ・・・ FROM ##テーブル ・・・ ORDER BY ・・・

DROP TABLE ##テーブル

といったストアドを書き、フォームやレポートの入力パラメータプロパティに、

@パラメータ1 nvarchar(10) = [Forms].[フォーム]![パラメータ1],
@パラメータ2 nvarchar(10) = [Forms].[フォーム]![パラメータ2]

のような設定をします。
他のパソコンで同じストアドを使用しても問題は起きません。

9 :名無しさん@そうだ選挙にいこう:01/10/04 13:49
ここなんてどう?
参考になると思う。
http://www2p.biglobe.ne.jp/~sakurait/cstrue/cl1999/cl1999c4.html

10 :1:01/10/04 14:58

6番さん、9番さん、ありがとうございます。

>>8
「mdbは分散型アプリケーション
 adpはホスト集中型アプリケーション」って素晴らしい表現ですね。
サーバー側で作成する一時テーブルは名前が同じでも他のクライアントには全く
関係無い。という事、これで納得し安心しました。
クライアントの台数が多くなるとサーバーに負担が掛かるのでサーバーの負担を
軽くする意味でクライアントにワークテーブルを作成した方がいいのではないかと
思っていましたが、この考えだと逆にネットワークに負担がかかり遅くなるんです
ね。なるほど良くわかりました。
サンプルで記述されたストアドもこれから時間をさいて実験してみます。
結果はまたご連絡致します。

>>9
ここも凄く役にたちました。探している時は中々見つける事が出来ないけど、
素晴らしい情報ってたくさんありますね。

2ちゃんねるって凄いですね。みなさんに感謝感激です。
これからも宜しくお願い致します。

11 :名無しさん@そうだ選挙にいこう:01/10/04 21:33
3がとても正しいと思う今日この頃なのでした

12 :1:01/10/05 11:02
>>11
11番さん、こんにちは、
adoとmdbを一緒に使えるのでしょうか?
お忙しいと思いますのでヒントでも結構です。宜しくお願い致します。

13 :名無しさん@そうだ選挙にいこう:01/10/05 12:30
>>8
サーバーでテーブルを作ったり削除したりして
サーバーの負荷は重くならないのでしょうか?
またSQLサーバーのばあい
データエリアがフラグメントしたりしないのでしょうか?

14 :8:01/10/05 20:48
>>13
自己流なので、間違ったことを書くかも知れませんが

>サーバーでテーブルを作ったり削除したりして
>サーバーの負荷は重くならないのでしょうか?

参考書を読んだことがないので何とも言えませんが、
一時テーブルはこのような使い方をするために
あるのだと思っています。
どうしても一時テーブルが必要な場合があります。
SELECTだけで出来ることであれば、なるべく避けた方が
いいのでしょう。
最近納品したアプリケーションは8台のクライアントで
使ってますが、遅いと感じたことはありません。

クライアントやネットワークのトラブルで処理が中断
した場合に、勝手にリカバリ(削除)してくれるので、
便利です。
ローカルのmdbにアクセス中、クライアントがダウンすると、
どの様なトラブルになるか、予想がつきません。

WINDOWSを使ってる限り、クライアントがいつダウンするか
分からない、突然ネットワークが切断される場合があるという
ことを考慮して、アプリケーションを作るべきだと思います。
でないと、頻繁ユーザーに呼ばれ、にトラブル対応することに
なりますからね。

>またSQLサーバーのばあい
>データエリアがフラグメントしたりしないのでしょうか?

ACCESSと違って、勝手に最適化してくれてるようです。

15 :名無しさん@そうだ選挙にいこう:01/10/05 22:31
sqlで作成した方がいいお勧めの本は
ナツメ社のaccess2000sqlハンドブック

16 :名無しさん@そうだ選挙にいこう:01/10/05 23:15
>ACCESSと違って、勝手に最適化してくれてるようです
それに、一時テーブルはtmpdbに作成されるから、直接ユーザのDBには影響しないしね。

17 :1:01/10/05 23:28
>>14
皆様のおかげでSQL Serverの良い所やプログラミングする時の注意点等が
少しづつ分かってきました。ありがとうございます。
実をいいますと、前回、教えて頂いたストアドプロシージャでのフォーム
の作成がまだ理解出来ていないのです。

CREATE TABLE #テーブル を使用するとテーブルの定義が面倒みたいなので
SELECT INTO #テーブルが簡単でいいかなと思いこの方法を実験しているの
ですがなかなか難しいですね。
・フォームを開くとき
 SELECT INTO #テーブルを使用して一時テーブルを作成する。
 作成されたテーブル名をフォームのレコードソースに代入する
・データの入力、編集などを行う。
・登録で#テーブルからサーバー側のデータを更新する
・フォームを閉じる
 一時テーブルを削除する
この様な考えなのですが、大丈夫でしょうか?もし、考えが間違っていたら
教えて下さい。宜しくお願い致します。

18 :6:01/10/06 01:07
>>1
ほぼ大丈夫だと思います。
私も行き当たりばったりでやってますので、なんとも言えません。

とりあえず、フォームでテンポラリを参照するところから
始めてはどうでしょう? (もうこの辺は理解されてるかもしれませんが・・・)

1.ストアドを2つ作る
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Alter Procedure TEST_テンポラリ作成
As
--とりあえずテーブルをデータ毎コピー
SELECT * INTO ##テンポラリテーブル FROM test1 --テストに使うテーブル名
return
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Alter Procedure TEST_テンポラリ削除
As
DROP TABLE ##テンポラリテーブル
return
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

2.新規フォームを作成する
 (作成を始める前に TEST_テンポラリ作成 を実行して一時テーブルを作っておいて下さい)

コントロールソースプロパティを ##テンポラリテーブル と設定する。

後はACCESSと同じ要領でテキストボックスをいくつか作って下さい。
(フォームを閉じた後は TEST_テンポラリ削除 を実行して一時テーブルを削除して下さい)

3.テスト

 TEST_テンポラリ作成 実行
 フォームを開く
 TEST_テンポラリ削除 実行

で、これらの動きが見えると思います。
レコードが編集できないことも確認出来るかと思います。

それから、データ編集する仕組みにも挑戦してみて下さい。

一時テーブル作成時に主キーを作ることをお忘れなく>>6

データ編集で私がよく忘れてしまうのは、フォームでの編集では、レコード移動時に
レコードがテーブルに書き込まれるため、最後に編集したレコードがテーブルに
反映されないままストアドを実行させてしまうことです。(ACCESSでも同じですね)
ストアド実行前にレコードを保存することをお忘れなく。

DoCmd.RunCommand acCmdSaveRecord

だったかな。

頑張って下さい。

19 :1:01/10/07 14:24
>>6
TESTテンポラリー作成について質問なのですが
1.RecordSource = "#TEST"
 RecordSource = "##TEST"
#TESTで実験した場合、テーブルが無いとメッセージが出ます。
 これはどうしてでしょか?
2.表形式のフォームに##TESTを張りつけたとき、データは正常に表示されるので
 すが、最終行に空白が空かないため追加データの入力が出来ません。
 TESTにはインデックスはセットしているのですが何が問題なのでしょうか?
 >>18で「レコードが編集できないことも確認出来るかと思います。」と説明し
 てある事がこの事でしょうか?
お忙しいのに申し訳ございませんが、教えて頂けないでしょうか?

20 :名無しさん@そうだ選挙にいこう:01/10/07 19:09
だれかSQLserver2000のCDキーを教えて下さい!!
明日までにわからないとぼくはもうダメなんです!!!

21 :名無しさん@そうだ選挙にいこう:01/10/07 20:51
WR-W50292-M1G9M52-UA107

22 :1:01/10/09 09:50
>>19
SELECT INTO ##TESTで一時テーブルを作成した場合の件ですが
元となるテーブルにインデックスがセットしてあれば##TESTにも自動的に
インデックスがセットされると思っていました。これが間違いだったのですね。

CREATE TABLE でインデックスも含めて##TESTで一時テーブルを作成し
その後、INSERT INTOでデータを代入して一時テーブルを作成したらうまく行きま
した。

SQL ServerはAccessに比べて機能が多いのでマニュアルがとても見にくいですね
シンプルなサンプルがたくさんあるといいと思います

みなさん、今後とも宜しくお願い致します。

23 :1:01/10/09 13:53
SQL ServerにTM_GYOといううマスタがあります。
ACCESS2000の表形式のフォームで、TM_GYOのデータを追加、修正、削除等が出来るようにしたいのです。
下記のような方法で、登録、修正、削除など行えるようになりました。
しかし、下記の問題が発生しました。
1.#TN_GYO では一時テーブルが作成できない。
2.同時にほかのパソコンで同じフォームを開くと##TN_GYOが既に存在します。になります。
3.マニュアルには
 『ローカル一時テーブルが、複数ユーザーが同時に実行できるストアドプロシージャ
  またはアプリケーションで作成される場合、SQL Server は、異なるユーザーが作成
  する個々のテーブルを区別できなければなりません。SQL Server は、各ローカル
  一時テーブル名の末尾に数値サフィックスを内部的に追加することによって、テーブル
  を区別します。』
 と書いてありますが、数値サフィックスは自動的に作成されるものではないのでしょうか?

ACCESSのフォームを開くのイベント内
Set COMD.ActiveConnection = CN01
With COMD
.CommandText = "ST_3010TMPSKS"
.CommandType = adCmdStoredProc
.Execute
End With
RecordSource = "##TN_GYO"

ストアドプロシージャー
Alter Procedure ST_3010TMPSKS
As
CREATE TABLE ##TN_GYO (GYO01 NCHAR(2) NOT NULL,GYO02 NCHAR(16),GYO03 NCHAR(2),GYO04 NCHAR(2),GYO99 INTEGER)
ALTER TABLE ##TN_GYO ADD CONSTRAINT TN_GYOK01 PRIMARY KEY(GYO01)
INSERT INTO ##TN_GYO (GYO01,GYO02,GYO03,GYO04,GYO99) SELECT TM_GYO.GYO01,TM_GYO.GYO02,TM_GYO.GYO03,TM_GYO.GYO04,0 FROM TM_GYO
return

宜しくお願い致します。

24 :6:01/10/09 20:17
>>23
>2.同時にほかのパソコンで同じフォームを開くと##TN_GYOが既に存在します。になります。

確かにそうですね。
何かで読んだのと、他のシステムの経験によって、一時テーブルについて間違った
思い込みをしてました。
申し訳有りません。
1さんのレスを読んで、ユーザーで実験し、脂汗をかいております。
クライアントの多くが遠隔地にあり、エラーが起きても知らせて来なかったのかもしれません。
明日は、この対応になりそうです。

一時テーブル名をユニークにするにはどうすればいいのかは、いくつか思いつきはしますが、
このような場合の「定石」を知りたいと思います。

私の作ったアプリケーションでは、一時テーブルはトランザクション内で作成・削除を行ってますが、
同時に同じトランザクションが実行された場合の「排他制御」の考え方についても知りたいと思います。

どなたかご指導、宜しくお願いします。

25 :名無しサン@ボの牛丼:01/10/10 02:07
テーブル名のおしりにHOST_NAME()、つまりコンピュータ名を入れればいい。
動的SQL(SQL文をSQLで作って実行)は少々面倒だけど。

26 :6:01/10/10 03:55
>>25
とても勉強になりました。
ホストネームがこんなに簡単に取得できるとは知りませんでした。
有り難うございます。

Alter Procedure TEST_テンポラリ作成
@file_name nvarchar(128) OUTPUT
As
SET @file_name = '##テンポラリテーブル_' + HOST_NAME()
EXEC ('SELECT * INTO ' + @file_name + ' FROM test1')
return

Alter Procedure TEST_テンポラリ削除
As
DECLARE @file_name nvarchar(128)
SET @file_name = '##テンポラリテーブル_' + HOST_NAME()
EXEC ('DROP TABLE ' + @file_name)
return

<開く時>
Private Sub Form_Open(Cancel As Integer)
Dim Cnn As ADODB.Connection
Dim Cmd As New ADODB.Command
Dim par As ADODB.Parameter
Set Cnn = CurrentProject.Connection
Cmd.ActiveConnection = Cnn
Cmd.CommandText = "TEST_テンポラリ作成"
Cmd.CommandType = adCmdStoredProc
Set par = Cmd.CreateParameter(, adVarWChar, adParamOutput, 128)
Cmd.Parameters.Append par
Cmd.Execute
Me.RecordSource = par.Value
End Sub

<閉じる時>
Private Sub Form_Close()
DoCmd.RunSQL ("TEST_テンポラリ削除")
End Sub

27 :1:01/10/10 09:33
>>25
マニュアルに「数値サフィックス」とは書いてありましたが、「HOST_NAME()」に
ついては見つける事ができませんでした。
どうもありがとうございます。

>>6
詳しくサンプルまで書いて頂いて助かります。
どうもありがとうございます。

皆さん、遅くまで頑張ってらっしゃるんですね。関心します。
体には充分注意して下さいね。

これから早速、実験してみます。今後とも宜しくお願い致します。

28 ::01/10/15 00:34
揚げ

29 :名無しさん@そうだ選挙にいこう:01/10/27 04:07
#2つだとグローバル一時テーブルになるから
#1つでやらないと駄目なんじゃなかった?

30 :名無しサン@ボの牛丼:01/10/27 10:03
#1つだと、ストアド終了時に消えてしまったと思う。
#2つだとグローバルだけど消えないから、あとはテーブル名を端末毎にユニークな名前を付けておけば区別できるという話。

31 :2:01/11/03 17:52
皆様すごくて ついていけていませんでした・・・

やっと 試してみまして、気が付いた事がひとつあったので ご報告します。

ホストネームに'-'を使用しているPCがあると
一時ファイル作成時に ファイル名のエラーになるようです。

32 :名無しサン@ボの牛丼:01/11/03 23:18
>>31
それならホスト名をQUOTENAME関数で変換した結果をテーブル名にすればいい。

33 :31:01/11/05 02:06
32>>
QUOTENAME関数・・・ですか?
調べて明日試してみます。
ありがとうございました!! m(u_u)m

34 :名無しさん@そうだ選挙にいこう:01/11/06 19:49
>>31
[ ]で囲むと良い

35 :31=2:01/11/11 04:36
>>32
別な問題が発生してしまって 試せていません。
せっかく教えていただいたのに申し訳ありません。
>>34
[]ですか… ##の後ろを囲んでも大丈夫なのかな?##も含めるのかな??
やってみます。 って言いながらまた時間かかりそう(泣


ところで、皆様 MSDEのバックアップってどうなさっていますか?
ACCESS2000との組み合わせだと ツール>データベースユーティリティー>バックアップ
ってありますが これだと別のサーバとかコンピュータに取っておけるのですが、
文字通り「元に戻す」しか出来なくて、1テーブルだけ戻すとか出来ないですよね?
MSDEのデータ変換サービスウィザードを使うと テーブル単位にバックアップ取れるけどMSDE自体が
同一のものだから(?) 別のサーバにバックアップを取る事が出来ません。
(MSDEのインストール時に作られる「Data」っていうフォルダに××.ldfと××.mdfっていう
2つのファイルが出来てしまい、結局同じMSDE内に出来てるって事かな?と解釈したのですが…違うでしょうか?)

いろいろ試したのですが、どれも 今ひとつでした。

@テーブル単位に戻すことが出来て、
A安全の為に別のサーバ(別のMSDE)に、
B元のadpファイルに戻すだけでなく 他の場所、他のadpファイルに、
Cできれば ビューやストアドも
といったことが出来るようなバックアップの取り方&戻し方ご存知の方いらっしゃいましたら
教えてください。

よろしくお願いします。m(u_u)m

36 :名無しさん@そうだ選挙にいこう:01/11/11 08:54
>>35
ボクもMSDEのバックアップについてちゃんと勉強したいと思っていますが、
今やってる方法を書きます。

ユーザーにツールバーのバックアップを操作させるのは危険なので、
バックアップ用のフォームからストアドを実行してもらっています。
ちなみにストアドは、

Alter Procedure バックアップ
@file_name nvarchar(200)
As
BACKUP DATABASE XXXX
TO DISK = @file_name
return

です。
バックアップ用のホルダーにバックアップファイルを作り、手動でバックアップ
メディアにコピーしてもらっています。
リストアは「元に戻す」でやっています。(ユーザーがリストアすることはありません)

「元に戻す」は、現在接続中のデーターベースに上書きするようです。
既存のデーターベースを残したまま、新たにテスト環境を作りたい場合は、
ウィザードの「プロジェクト(新しいデータベース)」で別のデータベースを作り、
出来上がったADP(運用中のADPでは接続先を変更して)から「元に戻す」で
リストアしています。
バックアップ先デバイスと違うフォーマットのデバイスへのリストアは出来ないので、
あらかじめCD-ROM等からハードディスクにコピーしてリストアしています。

ボクのユーザーのデータベースはそれほど大きくないので丸ごとコピーで
自宅に持って帰っていますが、大きい場合はテーブル持ち帰り用のデーターベースを
作った方がいいのでしょうね。

>@テーブル単位に戻すことが出来て、

データベース間のコピーペーストで
(キーの情報はコピーされない・・・中途半端ですね)

>A安全の為に別のサーバ(別のMSDE)に、
>B元のadpファイルに戻すだけでなく 他の場所、他のadpファイルに、

adpファイルを作ることによってデータベースが出来上がりますが、
adpファイルとMSDEのデータベースは独立したものです。
××.ldfと××.mdfがデータベースの実体ですが、そのファイルを
意識することはないでしょう。
前の方に書いた方法で出来ます。

>Cできれば ビューやストアドも

ビューはコピーペースト出来ないのでSQL文を表示させて手動コピー
(MSの手抜きですかね・・・)
ストアドはコピーペースト出来ないのでテキストを手動コピー
(これもMSの手抜きですかね・・・)


もっといい方法がありましたら、どなたかご指導お願いします。

37 :名無しさん@そうだ選挙にいこう:01/11/11 22:21
ADOレコードセットとテキストボックス等を連結してUPDATEメソッドで更新する方法無いですか?
フォームのレコードセットに指定すると元データも更新されてしまいます。
関数作って地道に更新するしかないですか?

38 :名無しさん@そうだ選挙にいこう:01/11/11 23:30
>>37
関数作って地道に更新するしかないでしょうね
やはり非連結フォームですよね
コピーしたいコントロール名を、

Link_商品コード
Link_商品名

の様な名前にして、Link_の付いたコントロールをADOレコードセットから
全てコピーする関数を書けば、少しは楽になるのかも 他でも使えるし
コントロールからADOレコードセットへも同じ方法で
念のため、

コントロールの数
Forms(フォーム).Count

コントロール名
Forms(フォーム).Controls(数値).ControlName

39 :名無しさん@そうだ選挙にいこう:01/12/18 12:35
データを登録しようとすると、『 エラー 3146: ODBC--呼び出しが失敗しました。』
というエラーメッセージが出るのですが、原因がわかりません。

どのような場合に、このようなエラーメッセージが表示されるのかを、
ご存知の方がいらっしゃいましたら、どうかヒントをよろしくお願いします。

40 :名無しさん@そうだ選挙にいこう:01/12/18 13:13
>1
mdbに慣れていて、クライアントがAccess限定ならローカル一時テーブルの作成は
クライアントマシンにワーク用のmdb作って
ADO(DAO)でRecordsetオブジェクトをグローバル変数に取得
Form_Loadの時にrecordsourceプロパティに取得したオブジェクトを設定でもいけます。

SQLのほうでテーブル名の問題が出るよりは楽だとおもうんだけどどうかな?

41 : :02/02/12 06:58
勉強になるな

42 :名無しさん@そうだ選挙にいこう:02/02/12 13:12
>>15
>sqlで作成した方がいいお勧めの本は
>ナツメ社のaccess2000sqlハンドブック
とはどれでなんだろう?
http://www.natsume.co.jp/Natsume/PC.html

43 : :02/02/26 07:12
あげ

44 :名無しさん@そうだ選挙にいこう:02/04/09 00:06
Access+SQLServer でいろいろ実験してるんだが・・・
なんかいい書籍とかないのかなぁ〜


45 :名無しさん@そうだ選挙にいこう:02/04/13 17:03
MSのサイトに落ちてますよ。
http://www.microsoft.com/JAPAN/sql/evaluation/exercises.asp
只だし。これでだめならこれよりやさしそうなものを立ち読みしてから買おう。


46 :44:02/04/13 19:19
>>45
ありがとう!
さっそく見てみます!

47 :名無しさん@そうだ選挙にいこう:02/05/21 00:12
良スレage

48 :名無しさん@そうだ選挙にいこう:02/06/20 00:40
保守

49 :名無しさん@そうだ選挙にいこう:02/06/20 22:47
ぼっきあげ

50 :名無しさん@そうだ選挙にいこう:02/06/25 19:59
>>30
>#1つだと、ストアド終了時に消えてしまったと思う。
ストアドを使っているのが間違い。
ExecuteでSQL文をサーバーに投入すれば良いのでは

51 :名無しさん@そうだ選挙にいこう:02/07/23 08:26
はじめてSQLServer2000とフロントエンドAccess97でシステムを構築します。
サーバーとクライアント間は64kbps専用線を使います。
しかしテストをしたところ、サブフォームつきのフォームで、レコードの読みこみに
時間がかかることがわかりました。
テストデータは親側30レコード、子側で平均各10レコード(合計300レコード)
フォームを開くのに5秒、更新・レコード移動に2秒ほどです。

1)Access2000 or 2002にするだけでもパフォーマンスが改善されますか?

2)ここは定石どおり、テンポラリテーブルを介して必要なレコードだけ抜き出して作業をする
 (移動ボタンを使ったレコード移動をあきらめる)のがよいのでしょうか?


52 :名無しさん@そうだ選挙にいこう:02/07/23 08:36
>>51
1) しない。低下するかも。
2) はい。

53 :51:02/07/23 10:49
>>52 ありがとうございます

54 :名無しさん@そうだ選挙にいこう:02/09/03 10:19
すみません。質問させてください。

現在Access2000+SQL-SERVER を使っていますが、
MDBで開発してた時には、あるクエリーを元にして
またクエリーを作成して、それにパラメーターを
与えてレポートから開けたんですが、ADPの場合
はどのようにするんでしょうか?。

簡単なストアドプロシージャにパラメーターを与えて、
レポートなどを実行する方法はわかったのですが、
そこで行き詰まっています。

あるストアドを元に、さらにストアドを作るようなことは
できるでしょうか?。

55 :名無しさん@そうだ選挙にいこう:02/09/03 12:54
>>54
>簡単なストアドプロシージャにパラメーターを与えて、
>レポートなどを実行する方法はわかったのですが、
>そこで行き詰まっています。

う〜〜ん、そこまで分かってるのなら完璧じゃないですか。
何に行き詰まってますか?

>あるストアドを元に、さらにストアドを作るようなことは
>できるでしょうか?。

ストアドはテキストですのでコピーして張り付けだと思いますが。

ストアドはクエリよりも色々なことが出来て便利だと思ってます。

56 :名無しさん@そうだ選挙にいこう:02/09/03 13:13
>>54
レポートでパラメータを使いたいのなら、

1.従来クエリで作ってた部分をストアドプロシージャとして作る。
2.クエリのパラメータはストアドの引数に置き換えて作る。
(例)fooというテーブルのCODEフィードで絞り込みする場合
Create Procedure test
(
@code int
)
As
SELECT * FROM foo WHERE CODE=@code
return

3.パラメータ入力用のフォームを作る。
(例)form1というフォームにtxtCodeという名前のテキストボックスを付ける

4.そのストアドプロシージャをレコードソースにしたレポートを作る。
 レポートの「入力パラメータ」プロパティを設定する。
(例)@code int=Forms!form1!txtCode

5.あとはそのフォームを開いてテキストボックスにコードが入っている
 状態で、4.のレポートを開くとコードで絞り込まれてレポートが開かれる。
 実際には3.のフォームにレポートを開くボタンを付けるとよい。

ストアドプロシージャをソースにしたストアドプロシージャは作れない
ので、SQL文を工夫してストアド一つにまとめるしかないと思われ

57 :54:02/09/03 16:31
>55さん、56さん

レスありがとうございました。ACCESSで7年ほど飯を食ってきましたが、
ここにきてまた新たに勉強しなおします。

MDBのように、Aクエリーを元にしてBクエリーを作成して、集計結果の
レコードセットを得る、というやり方に慣れてしまったので、
ストアドでも同じことをしたいと思って質問させていただきました。

現在、MDBのクエリビルダのSQLソースをストアドに貼り付けて
地道に作業していますが、繰り返すうちにやっと構文の基本くらいは
わかってきました・・・。

>ストアドプロシージャをソースにしたストアドプロシージャは作れない
>ので、SQL文を工夫してストアド一つにまとめるしかないと思われ

これが答えなんですね・・。とりあえず、SQLの結果を
テーブルにINSERTして、そのテーブルを元にまたSQLを書く、という
方法で回避することにします。モジュールの中で発行するので
直接SQL?とかいうやつになっちゃうんですが・・。

>ストアドはクエリよりも色々なことが出来て便利だと思ってます。

そう思えるようにがんばります。

ちなみにACCESS2002も手元にありますが、ためしにインストールしたら
早速落ちました。

58 :名無しさん@そうだ選挙にいこう:02/09/13 16:15
>57
AccessのクエリがレコードソースのクエリのようなものをSQLサーバーなんかで作る場合は

1. ストアドの中のSQLの中にインラインで書く
2. ストアドの中で一時テーブルに結果のレコードを入れて、
同じストアドの中でそれを元にしたSQLを作る
3. VIEWをレコードソースに使う

とかいろいろ手があります。
データ操作に関してはAccessでクエリ+(マクロ or VBA)でやっていたことのほとんどは
ストアドのみでやれると思っていいかと。

同時アクセスの場合の処理とかを考えるとストアドがおすすめ。

あとSQL Server 2000の場合はAccess2002を使ったほうが
ユーザー定義関数に対応している等でイイと思う。
(Access2002でDBを作成した場合、デフォルトのセキュリティが甘甘なのには注意)

59 :名無しさん@そうだ選挙にいこう:02/09/22 16:19
今までLANでAccess97使用しているんですが、電話接続環境でもAccess使用すること
になったらSQLserver等もっとしっかりしたデータベースソフト入れないといけませんか?
それとも、なんとかしてAccessだけでも電話接続環境でも使用できるんでしょうか?

初歩的な質問ですいませんが よろしくお願いします。

60 :名無しさん@そうだ選挙にいこう:02/12/10 00:01
10000レコードのテーブルから20件を抽出するクエリをリモートから実行した時、
レコードすべてをリモート側に引っ張ってきてから20件を抽出するのがAccess、
抽出結果の20件だけをリモート側で引っ張れるのがSQLserver。

どちらでも動くが効率はSQLの方が断然良い。

61 :山崎渉:03/01/15 16:53
(^^)

62 :名無しさん@そうだ選挙にいこう:03/01/24 00:46
http://www.isis.ne.jp/

http://www.maromaro.com/

http://www.tomita.net/

本を読もう


63 :名無しさん@そうだ選挙にいこう:03/01/27 15:34
試験

34 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)