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

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

SQLサーバー

1 :名無しさん:2000/01/14(金) 18:01
のお勉強をしなくてはならなくなりました…とほほ。
で、参考書を買おうと思ってるのですが、何がよろしいでしょうか。
恐らく2、3冊は買わないといけないんでしょうけれど。

 宜しくお願いいたします。

 ちなみに、時はすでに遅く「そんなもんやめてOracleにしろ」は無効です…嗚呼。

2 :名無しさん:2000/01/14(金) 21:37
SQLサーバーで何やるの?

3 ::2000/01/14(金) 22:31
販売・売上・在庫管理です。クライアントのAccessをインターフェース
にしてSQLサーバにアクセスしてます。一応、システム自体は組み上がっ
てるんですが、メンテしないといけないので仕組みを知らないといけない
のです。

 宜しくお願いいたします。

4 :名無しさん:2000/01/15(土) 03:55
参考書買うより、コースだしてもらいなよ。
高いけど。

5 :名無しさん:2000/01/15(土) 10:41
Access- MS-SQLサーバ、、、合掌
どうせ他のに乗りかえることになるだろうから、あんまり深入りしないようにね。

6 :はいどうぞ:2000/01/16(日) 03:52
AccessをC/SシステムのF/Eプロダクトとして
導入しようと思った時点でそれは重大なミスだと思う。。。


7 :MCP(MSSE):2000/01/16(日) 10:50
SQL-SERVERはMS版なの、それともsybase版ですか?
とりあえず講習会がよいと思う。

8 :アクセス命:2000/01/16(日) 13:14
>5@`6
確かにアクセスで作ったフォームは死ぬほど重いし、データロックの問題もあるが、
レポートに関しては生産性ピカイチだよ。

9 :はいどうぞ :2000/01/16(日) 21:41
>8
残念ながら、レポートの生産性もPowerbuilderにはかないませんよ。
クエリもグルーピングも反復特性もすべて画面提示様式と同様に作成できる。
最後にPrint関数を発行するだけ。

VisualFormadeなどの3rdパーティなレポートツールを
同時に習得する必要もないし。

ランタイムが必要なのはACCESSもPowerbuilderも同じだけどね。
ランライムが要らないDelphiは確かに小口ユーザに関して
手離れも良いメリットがあるけど、
グリッドの提示が柔軟に加工できないから、ユーザ要求仕様を叶えにくい点もある。

10 :アクセス命 :2000/01/16(日) 23:00
>9
うちもシステムによってはPowerbuilderいれているのですが、そんなに生産性が高いのですか?
アクセスみたいにテーブルやクエリーからオートマチックにレポートが作れますか?

11 :はいどうぞ:2000/01/17(月) 00:44
>オートマチックにレポートが作れますか?

ウィザード機能はPowerbuilder自体にはないです。
が、ウィザードで済む程度の提示様式であれば
さほど工数はかからないでしょうね。
作成方法は9に書いたとおり、画面作成と全く同じです。

>そんなに生産性が高いのですか?

高いです。そもそもACCESSやVisualBasicには
DelphiやPowerbuilderのような部品継承機能が無い時点で
オブジェクト指向からはずれちゃってます。

もちろん物件として需要が多いのはACCESSやVBなんで、
担当部署をゼロにしちゃう事はできないんですけね。

ユーザによっては、普段使いなれてるACCESSでRDBにアタッチしたいから、
同じACCESSやVBで開発してくれなんて言うところもありましたね。


12 :アクセス命:2000/01/17(月) 01:43
>ウィザードで済む程度の提示様式であれば さほど工数はかからないでしょうね。
???そんなはず無いと思うよ。
複雑なSQLがデータソースになることも多々あるし。
これじゃPowerbuilderがアクセスより生産性が高いことが証明できてないんじゃない?
失礼ですけどアクセスでまともな帳票つくったことありますか?


13 :はいどうぞ:2000/01/17(月) 06:07
>複雑なSQLがデータソースになることも多々あるし

・・・ちなみにクエリ構築のGUIはACCESSとほぼ同じです。ケケケ。
ま、データソースは定義を固定にするんでなく、
動的にSQL切り替える方がスマートだし構文自体もパススルーでなく
RDB側の構文にあわせて自動で解釈してくれるんで(ANSIでもOracle方言でも)
ほとんど最初から直接SQL構文を記述してデータソースを生成してますけどね私は。

・・・ですけど、ここで言ってるのはレポート提示様式の作成が
どれだけ容易に行えるかってことですよね?なので、

>???そんなはず無いと思うよ。
 ↓
この理由が、何故に
 ↓
>複雑なSQLがデータソースになることも多々あるし。
と、なるのかちょっとわかりません。

>これじゃPowerbuilderがアクセスより生産性が高いことが証明できてないんじゃない?

うーん、帳票に関してだけでなくて、ゴメン、そもそも、
PowerbulderとACCESSを比較するなんてできなかったのかもね。
RADツールとそうでないものは同列に語れないもんね。

>失礼ですけどアクセスでまともな帳票つくったことありますか?

・・・ACCESSとDelphi(QuickReport)とPowerbuilderとVisualFormadeで作ったことあります。
感想としては、やっぱりPowerbuilderが一番です。
VisualFormadeとACCESSは、2度とやりたくないって感じ。



14 :端でROMってたけど:2000/01/17(月) 11:42
>はいどうぞさん
丁度、同様の問題かかえてたんで色々参考になったよ。
ありがとね。
これでユーザーになんとか説明できるな

15 :はいどうぞ:2000/01/17(月) 12:35
>14

(#´_`#)

16 :アクセス命 :2000/01/17(月) 13:33
>>???そんなはず無いと思うよ。
> この理由が、何故に
> ↓
>>複雑なSQLがデータソースになることも多々あるし。
>と、なるのかちょっとわかりません。

複雑なSQLていうよりアウトプット項目数が多い場合ですね。
だとしたら、
>ウィザードで済む程度の提示様式であれば
>さほど工数はかからないでしょうね。
てことにはならないでしょう、ということを言いたかったのです。

ウィザードっていっても馬鹿にしちゃいけませんよ。
サブレポートも組み合わせれば、かなりまともな帳票が作れます。

17 :五分刈少年:2000/01/17(月) 15:14
たしかにAccessのレポートは秀逸だと思うよ。

18 :名無しさん:2000/01/17(月) 15:24
Sybese-Delphi-Accessということで、手を打とう

19 :はいどうぞ:2000/01/17(月) 18:11
>18
>Sybese-Delphi-Access

SybaseSQL-ANYWHEREいいすね。Powerbuilderの現在のネイティヴですわ。
ほんで、画面Delphi帳票ACCESS? いいんでないですか。

ウチのド腐れ阿呆部署がやってる、
if network版 true then
OracleのSQL記述
else
AccessJETのSQL記述
end if

っていう、クソバカ構築技法に比べりゃ天国ですわ。
っていうか、だったらローカルRDBをPO8にしろよって、
フツーはかんがえるよねー もー信じられんわあのバカ部署ー


20 :Access楽か?:2000/01/18(火) 10:15
簡単つーから使ってみたけど、まどろっこしくてやってらんないからdelphiで作っちまったよ。
DelphiのQuickReportも時々怪しい動きをすることがあるので完璧とは言えないけど。

21 :seven:2000/01/18(火) 10:23
QR使うなら、ソース買って自分で直さないと、ハマるかもね。
地道にCanvasに書きましょう(笑)

22 :はいどうぞ:2000/01/18(火) 10:50
>20
そそ、で、Delphiだと+QRを扱う必要があるんだけど、
Powerbuilderならそれ一個でOKってところがええんですわ。
(ランタイムの呪縛からは逃れられず)


23 :名無しさん:2000/01/18(火) 12:31
SybaseだとinfoMakerの使い具合はどうですか?


24 :名無しさん:2000/01/18(火) 12:38
専用帳票への印刷は皆さんどうしておられるのでしょう?
プリンタドライバの制限から逃れないといけない場合も多々あるので、
それなりのツールを使うか、プリンタドライバを介さずに印刷するかに
なると思いますが。
どのようにされています?

25 :>24:2000/01/18(火) 15:56
DOSからWindowsに移行したばかりの頃はドライバも
機能不足で難儀したけど今は何とかできてます。
GetDeviceCapsでdot/inch求めて、あとはPrinter.Canvasにシコシコ書いてます。
プリンタフォントを指定すれば昔の帳票と同じように刷れますよ。


26 :名無しさん:2000/01/18(火) 16:39
プリンタドライバを介さずつうのは直接LPTに制御コード書込む
つうこと?


27 :>25:2000/01/18(火) 23:14
うはー、気が遠くなる。

28 :はいどうぞ:2000/01/19(水) 03:51
僕ならソフトに併せて専用帳票をリニューアルさせるよう、
ユーザに依頼する。実際そうしてる。
もちろんリプレースだけでなく付加価値は付ける。

ユーザだってソフト屋に払う金を有効に使って欲しいと
思ってるから、そのOUTPUTにさほど価値を見いだせないなら
ユーザ自身に印刷屋と調整付けてもらうよう依頼する方が良心的だと思う。


29 :>28:2000/01/19(水) 09:35
○○協会とかで決まっている市販の専用帳票なんかは直せないから困る。
ユーザー独自の帳票ならどうにでもなるけどね・・・。


30 :seven:2000/01/19(水) 10:28
プリンタの余白制限だって、用紙サイズをごまかせばなんとかなるし
Printer.Canvasに書けば、ほとんどのことが0.1mmの精度でできます。

31 :>30:2000/01/19(水) 11:27
連続帳票なら困るんでは?(単票なら良いけど)

32 :はいどうぞ:2000/01/19(水) 13:57
>29

うーん、そうそう、たとえば流通業のチェーンストア伝票なんかが
ツールのデフォで打てなかったらツライな〜
今んとこそういう壁にブチ当たったことはないけど。

一番キツかったのは、プリンタに給紙できない程の
小さい単票伝票の印字を自動化した事かな。

極薄のOHP用プラスティック板の4方に切り込みを入れて、
そこに単票をセットして給紙させる方法を考えたんだけど、
ジャムジャムになっちゃったので(笑)、
結局A4用紙の定位置にはがせる紙のりでくっつけて
一緒に手差し給紙してもらうようにした。
一日に3枚でるかでないかの伝票だったからよかったけど。

33 :seven:2000/01/19(水) 15:20
>32
う〜、みんな苦労してるのね(涙)

34 :>31:2000/01/19(水) 15:29
1行が1/6インチですから、プリンタドライバで1ページ分の
用紙長をインチ単位で設定してやるとOKです。
あとはPrinter.Canvasに1ページ分書いてEndDocで改ページ。


35 :あ、:2000/01/19(水) 15:32
Printer.NewPageでしたね。失敬。

36 :>32:2000/01/19(水) 15:49
若い子に「ジャムる」と言ったら通じなかった。
関係ない話だけど。。。

37 :>36:2000/01/19(水) 16:48
関係ない話を続けるけど、そういう人に8inchフロッピーを
見せると面白い反応するかも。いやうちの新人は面白かった!


38 :>36:2000/01/19(水) 16:54
今でもコピーやFAXが紙詰まりすると「JAM」って表示しない?


39 :1です:2000/01/20(木) 02:06
なんか話が明後日の方向に…いや別に構わないんですけど。
講習会ですかーうーんそんなお金出してくれるかなぁ。
とりあえずいうだけ言ってみます。ありがとうございます。

40 :五分刈少年:2000/01/20(木) 02:38
>32
ボクも似たような経験したよ。
伝票が単票でハガキの2/3くらいしかないんだ。
なんとかOKIのMICROLINE(ドットインパクト)を手差しで
乗り切ったよ。手前から入れるとまた手前にスーって戻ってくる
面白いプリンタだったな。

ちなみにエプソンのユーティリティで、紙詰まりを知らせる
音声メッセージのファイル名は"05jam.wav"デス。


41 :>1:2000/01/20(木) 09:47
おお! このスレッド「SQLサーバー」だったのですね。


42 :名無しさん:2000/01/20(木) 16:04
コードが「スパゲッティ状態」とかは使いますよね?

43 :名無しさん:2000/01/20(木) 20:05
文字化けをハナモゲラ語と言わないですか?

44 :はいどうぞ:2000/01/20(木) 23:09
>42
>コードが「スパゲッティ状態」とかは使いますよね?

RADツール+RDBシステムをCOBOL屋に設計させるとそうなる。
奴らはオブジェクト指向の概念が無いので、
E-R図でなく、あいかわらずフローチャートを書きたがる。
そしてRDBシステムには基本的に不要なワークテーブルを作り、
それのファイル転がしをしたがる。
FunctionとProcedureとInheritedも理解できないので、
結局COBOLの内部サブルーチン風のプログラミングしかできない。
ひどいやつになると、ローカル/インスタンス/グローバル変数の
区別もできない。

そういうやつがACCESSやVBで無理やりプログラミングするので、
結果、スパゲッティプログラムができあがる。

そんなもんは将来的にも保守し切れないので、
結局フリープログラマを集めて臨時PJを作り、
外注委託させちゃったりすることになる。

なので、ある意味ACCESSとVisualBasicをやっておくと、
フリーになってもツブシが利きやすいともいえる。


45 :元COBOL屋:2000/01/21(金) 00:55
引導渡してくれてアリガトウ、これで死ねるよ(T^T)

46 :はいどうぞ:2000/01/21(金) 03:26
>45

・・・ワシもCOBOL屋あがり(笑)。


47 :名無しさん:2000/01/21(金) 10:03
>ひどいやつになると、ローカル/インスタンス/グローバル変数の
>区別もできない。
グローバル変数のみ使ってプログラムを作成されました。(;_;)




48 :名無しさん:2000/01/21(金) 12:43
Power++を趣味で買いました。許せんSybase。


49 :はいどうぞ:2000/01/21(金) 22:27
>グローバル変数のみ使ってプログラムを作成されました。(;_;)

(TT)合掌。。。 

50 :名無しさん:2000/01/22(土) 10:44
MS DataEngineは使われてるんですか?
OPOはドコいったんですか?

51 :Accessプログラマ某:2000/01/25(火) 23:05
>1

http://www.infonet-dev.co.jp/openpower/cshanac/cshansire/index.html
思ったのですが、もしかしたらこういうソフトのメンテだったりしますか?(謎)
私はこれのAccess97バージョン持ってるけど、コード追ってくだけでも精一杯だった……
でも、ODBCDirectとか、非連結フォームでサブフォームを実現する裏技とか、これでちょっとわかったけど……

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

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

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)