【VB滅亡】M$ InfoPathの衝撃【SE失業】

このエントリーをはてなブックマークに追加
1仕様書無しさん
これ、やばいっす。
http://www.atmarkit.co.jp/fdotnet/special/infopath/infopath_01.html

VBやらWebアプリでしょぼい社内システムのフロントエンド
作ってる人はまじで失業かも。
仕事がなくなりはしないけど、開発規模を大幅に
縮小するインパクトをもってるように思います。
2仕様書無しさん:03/03/28 01:04
3仕様書無しさん:03/03/28 01:09
来たね。遂に来たね。読んで見たよ。
正に何にも知らない客が喜びそうな感じだね。安い単価の仕事なんかは正
にこれに食われそう。これが普及すれば確かに仕事が激減する人が多数出
現するだろうね。
4仕様書無しさん:03/03/28 01:11
結局凝った機能はVBScriptで作りこまなきゃいけない罠
5仕様書無しさん:03/03/28 01:21
>>4
わかってねーな。この記事が意味する所を。
例えば、客がフロントエンドを作って凝った所をPGらが作る訳だ。
ところが昔は「凝った所」だった場所が、次からは凝った場所では無くな
るって訳だ。つまり、本当にやっかいな部分のみを押し付けられるってこ
った。更にコロコロ仕様変更可能だな。これは。

目に浮かぶようだ。「ココこういう風に変更したからお願いね。」
さーて、俺は関係無いが、どうなるのかな?
6仕様書無しさん:03/03/28 01:22
7仕様書無しさん:03/03/28 01:30
>>6
まあ、普及するには時間かかるかも知れんけどな。
マ板ですら>>4のような認識のヤシもいるわけで。

でも、4,5年たって、既存システムのリプレース需要が終わったら・・・
(((((;゜Д゜)))))
8仕様書無しさん:03/03/28 01:49
VBもWEBもダメだなw

linuxもう意味ねえw
9仕様書無しさん:03/03/28 01:55
1. "Rich" client required. Never forget that InfoPath is from the Office
group. Their raison d'etre is to sell "rich" client software. By most
definitions of the term, they have been successful in this endeavor.
To the degree that they remain successful, InfoPath becomes part of the
desktop computing ether. Of course, this sword has two edges...

2. No security. Given that InfoPath produces editors on top of "raw"
XML files in the file system, I'm not sure what they could do that
couldn't be circumvented by notepad. That stated, for apps that
don't put the XML into the file system, one could either (a) produce
different forms for different security profiles or (b) write some
JScript. Neither one is especially elegant for the average IT user.

3. Where's the .NET? Yeah, where is the .NET? Yes, the web service
support is nice, but there's no managed code support. While I would be
surprised if COM interop wouldn't work to let me write the C# code,
I have no intention of writing MSXML code in C# (assuming it would
even work).

4. No controls. Without #3, this one is moot in my opinion.

5. No offline access. Hmmm.. I've been extremely happy using the file
system as my offline store. No magic required. Again, InfoPath is primarily
an editor construction kit, so it seems weird for my editor to do this
stuff for me.

6. No user base. See #1.
10仕様書無しさん:03/03/28 01:56
いいニュースじゃねーの?
XMLでいいなら、OLEだのCOMだのめんどくせー話がなくなるんだろ。
プログラマにとっては万々歳じゃん。
ついでにGUI考えなくていいから。

あ、GUIだけで食ってた人が困るわけか。
11仕様書無しさん:03/03/28 01:58
でもPro版にはついてこないんでしょ?
12仕様書無しさん:03/03/28 02:01
仕様変更内容はOneNoteで無造作に貼り付けられるわけだ。
13仕様書無しさん:03/03/28 02:02
>>12
で、Outlookでメールで送られてくる、と。
嫌な時代だ。(w
14仕様書無しさん:03/03/28 02:04
これってひょっとして「XMLで保存するFileMaker」のことか?
15仕様書無しさん:03/03/28 02:05
>>10
OLEやらCOMやらで企業は金を取れたと言う訳だ。所が、XMLとなると
話は激変する。基本的にGUIでは金は取れんよ。
16仕様書無しさん:03/03/28 02:13
まあこれでも見てもちつけ
http://www.microsoft.com/office/preview/infopath/demo.asp
17仕様書無しさん:03/03/28 07:59
>>15
>OLEやらCOMやらで企業は金を取れたと言う訳だ。所が、XMLとなると
>話は激変する。基本的にGUIでは金は取れんよ。

それはVBだのDelだの人には大打撃だろうが、
JavaのようなもともとGUIなし(笑)の
言語にはとてもいいニュースだと思うのだよ。
18仕様書無しさん:03/03/28 08:02
XMLでやらせてもらえるならそれでやりたかったのに、今まで
WORDだのEXCELだののファイルフォーマットが邪魔をしてくれていた。
それがなくなってくれると解釈できるのだが、違う?
19仕様書無しさん:03/03/28 08:28
このままデータベースのフロントエンドに出来るのならすごいよね。

ただ、勝手に項目追加されてもそりゃ対応出来ないだろうから、
今迄 VBやDelphiでフロントエンド作ってたのとそう手間は替らないでしょ
20仕様書無しさん:03/03/28 08:29
俺にはとっつきやすい Access に見える。
21仕様書無しさん:03/03/28 08:31
というか、それで作った画面を Web/VB/Delphiの入力フォームに自動変換してくれるツールが出るだろ

誰もが皆Officeが好きな訳じゃないんだし、
22仕様書無しさん:03/03/28 09:17
これはアレか? 郵便番号入れたら住所欄を自動的に埋めてくれたり

商品コードの一部入れたらドロップダウンでメニューが出たりまでやってくれるのか?
23仕様書無しさん:03/03/28 09:28
なんかな。つまりOfficeだけでなんでもできるって話?
そういうことなら、そりゃ無理でしょ。いくらなんでも。
今でも「そんなのExcelでできるじゃん」というような仕事を
するだけのどうしようもないカスアプリを、お客様は買ってくれてるもん。

それに、データベースに直接触れるようなお客さんはいない。
触ったら絶対壊す。

それより、データフォーマットでXMLを「標準採用」するっつーことが
逆にMSのクビを締めそう。
24仕様書無しさん:03/03/28 09:38
雑誌が取り上げたとしても、企業がすすんで導入するかは疑問。
VBスライムとか初級技術者は消えなさいってこった。
25仕様書無しさん:03/03/28 09:44
>>24
(^Д^)ノ~~~
26仕様書無しさん:03/03/28 09:54
やっとofficeが「テキストファイル」になったか
これでcvsもdiffもgrepも使いたい放題になったな。
27仕様書無しさん:03/03/28 10:08
>>26
どう保存されるんだろう? グラフィックデータがBase64だと UTF16じゃHDDをムダ食いしそうだし
UTF8かな
28仕様書無しさん:03/03/28 10:30
>>26
だな。
29仕様書無しさん:03/03/28 10:44
なんか論調が
「新しいWordにHTML作成機能がついた」
って時と同じだねぇ。

確かに敷居は低くなるんだろうけど、実際問題として営業や経理にそれを
作っている時間があるかどうかはちょっと疑問。
30仕様書無しさん:03/03/28 10:46
結局、OfficePro辺りにセットで入っていないと進んで買うかどうか
疑問だな。M$は大きな勘違いをしているようだ。これではお話になら
ないと思われるが皆さんはどう感じただろうか。
31仕様書無しさん:03/03/28 10:54
Officeそのものがすでにネタ切れなんでしょうがないような。
32(^ー')b ◆ShA/gJZOLE :03/03/28 11:01
俺の印象もWeb対応Accessとしか映らんなぁ。
フロントエンドを開発するのがめんどくさい時に
客に勧めることになりそうだけど今も似たようなもんだし、
劇的に仕事が減るわけでもなさそうな。
33仕様書無しさん:03/03/28 11:02
だいたい
<tns:交通費>
<tns:利用日付>2003-03-11</tns:利用日付>
<tns:目的>打ち合わせ</tns:目的>
<tns:その他目的></tns:その他目的>
<tns:金額>1200</tns:金額>
</tns:交通費>
なんてのを外国で開いたって、だれも再利用出来ないでしょうに

国際的な応用するなら、どっかに辞書サイトで交通費に相当するGUIDうような仕掛けが必要だろうな
34仕様書無しさん:03/03/28 11:11
便利なツールができました、ってだけで
結局なにも変わらない気がするのは俺だけですか?
っていうかそろそろ学習しろよ。
35:03/03/28 11:23
>>1に反するが、最近の数レスの反応にあるように、
これを「プログラマーいらずのツール」として見なすのは危険でしょう。

だからといって、InfoPath自体が無価値であるとみなすのは勿体ないよ。
むしろ業務系プログラマにとっては、
ファイルフォーマットやInfoPathベースの案件確保によって、
利益に繋がる可能性があると見なした方がいいんでないかね。

InfoPathが広まる

顧客が独自開発する

行き詰まるか機能拡張がしたくなる

開発会社に依頼キター

みたいなシナリオは、それこそAccessやWordのHTMLの時もあった訳で。

そこで独自システムへのリプレースを
提案する(だって相手はXMLなんだし)か、
あくまでOfficeで作り込むかの選択は、
従来通り開発者が提案する余地はあるのでは?
36仕様書無しさん:03/03/28 11:25
ツールがいくら進化しても、顧客が最終的な意味でのデータの
構造とかコンピュータの基本的な仕組みのようなことを理解
しない限り、どこまで行っても間に技術者を必要とするような
気がする。

気がする、だけ・・・。
37仕様書無しさん:03/03/28 11:37
簡単にフォームが作れてXMLでデータを
吐き出してくれるってのは分かった
多分、DBへの挿入も簡単なんだろ。

でも、吐き出されたデータをDBから取り出して
自動でWORDのテンプレートに挿入して印刷したり
EXCELでグラフに変換したり、って作業には当然スクリプトが必要に
なると思うんだけど、これって誰がするの?
誰でもできることなんかな、これも?
38仕様書無しさん:03/03/28 11:45
これがスラスラ使えるならVBくらいなら楽々使える客でしょう
39仕様書無しさん:03/03/28 11:49
だいたいDB設計もまともに出来ないクライアントが
XMLスキーマをまともに設計できるわけがない。
40仕様書無しさん:03/03/28 11:55
・・・・これってますます客の教育が必要だと思わないか?
ヴァカな客に触らせたらたちまちシステム破綻するような「改良」が加えられて・・・。
41仕様書無しさん:03/03/28 12:35
1. クライアント全員分のライセンスが必要な罠。

2. 全クライアントにインストールしなければならない罠。
SPが出たらこれまた大騒ぎ。

これは退化と言わないか?
42仕様書無しさん:03/03/28 12:44
あとはXMLを加工するツールが欲しいよなあ。
XSLT・XPath・XQueryあたりを馬鹿でも操作できるツール。
これがないとXMLに吐き出す価値があまりないのでは?
43仕様書無しさん:03/03/28 13:01
Officeツールの使用方法を教育するより
XMLを教育したほうが価値は高い。

Officeが廃れてもXMLは廃れないから
44仕様書無しさん:03/03/28 13:16
>>43
>Officeが廃れてもXMLは廃れないから

プ
素人はすっこんでろって(w
45仕様書無しさん:03/03/28 13:22
ペッ
玄人ぶるなら演説のひとつもぶち上げやがれ
46仕様書無しさん:03/03/28 13:24
OfficeもXMLも廃れないに一票
47仕様書無しさん:03/03/28 13:27
一太郎は廃れたに一票。
なんだかんだ言ってもPGの単価が下がる要因が発生したと思うに一票
48仕様書無しさん:03/03/28 13:34
まあなんだ。

こういう道具を目の前にして、
今までと同水準のものしか作らなかったら
安く見られてもしょうがないよな。
49仕様書無しさん:03/03/28 14:03
あれ。勘違いしてたんだけど。
>>3
>結局、OfficePro辺りにセットで入っていないと進んで買うかどうか
OfficeStandardに入ってないんじゃ、流行るわけないんじゃ?
50仕様書無しさん:03/03/28 14:04
× >>3
○ >>30
51仕様書無しさん:03/03/28 14:21
XSLベースかな、
それともMSAccessやC#のGUI作成支援部分を取り出したのかな。

なんにしても、GUIだけなら言語ツールはいらなくなりそうだね。
現在でもXML対応のDBMSとXSL使えばいらないけど、
前者だとするとそれの WYSIWYG 環境を作ったわけだ。
52仕様書無しさん:03/03/28 14:24
しかしまあ、VB.NET IDEにこういう機能があれば大ブレークしたと思うが。
VBAはもうやりたくないよ。
53仕様書無しさん:03/03/28 14:45
よし、俺もさっそくXFormsコンポーネントを作ろう! これで大金持ちか?
54仕様書無しさん:03/03/28 15:33
>>52
Avalonを待て。デスクトップもXMLで作る時代がもうすぐやってくる。
55仕様書無しさん:03/03/28 15:42
>>44
>>43が素人発言である理由を述べよ!
56仕様書無しさん:03/03/28 17:18
Wordがなくなってくれりゃバンバンジーなんだが。
57仕様書無しさん:03/03/28 17:30
M$が本当にXMLで作成できるようにする気があるなら
M$Officeが死滅してもその後のコンバータでの変換が用意になる。
58仕様書無しさん:03/03/29 01:26
どう見てもプログラマ向けじゃねえか。
これで組める奴は、今もう自分で組んでるよ。
59仕様書無しさん:03/04/01 16:46
PGが楽できるツールなら大歓迎だが、実際はバグだらけで苦しめられる罠。
60仕様書無しさん:03/04/02 01:31
>>59
バグだらけっていうほど難しい機能はなくない?
61仕様書無しさん:03/04/02 01:48
ねぇ、InfoPathから入力されたデータ片を集計したりフィルターかけたりして
「意味のあるデータを作り出す」作業も、InfoPath自身で出来るの?
62おしえてくれいー:03/04/02 02:52
うーんSQLやAccessでなんでもできるとおもって
実はなんもできない罠?
Accessでどんがらどんがら枝葉をつけまくって、ぼろぼろうごかんシステムいっぱいみたことあるもんな
63コボラー:03/04/02 10:50
だから電算室作って大型機入れろっての
64仕様書無しさん:03/04/02 11:05
JavaがあればM$製品は要らない
65仕様書無しさん:03/04/02 20:43
>>61
そういうのはサーバサイドで書くんだろう。
でもプログラム的には難しくも何ともなくて、
むしろどんなデータに意味があるか分かる人が
する仕事だな。SEでもできる。
やっぱプルグラマ(゚听)イラネ

66仕様書無しさん:03/04/02 20:51
>>62
あー。あの。初心者だからわかんないんだと思うけど、
度重なる拡張でシステムが壊れてくるのは
言語やDBに関係ないし当たり前のことなんだよ。
だからこそリファクタリングという技術が重要視されてるのだが。
少しでもプログラミングしてれば分かると思うが。
67仕様書無しさん:03/04/02 22:43
>>66
Accessでリファクタリングはしにくいと思うぞ。
68(^ー')b ◆ShA/gJZOLE :03/04/03 00:02
>>62
前半と後半は関係ないような気が。
6961:03/04/03 00:56
>>65
さすがに全部InfoPathで、というわけには逝かないのか…

OfficeDeveloperのコンポーネント、InfoPathも入ってるかな?
Eclipseとかのプラグ可能なIDE向けに、InfoPathをベースにした
XML編集プラグインなんかがあると便利かも、と妄想してみる。
70仕様書無しさん:03/04/03 16:28
>>60
難しくないのにバグがあるのがMS製品。
しかしXMLは魅力。こうやってズルズルと(ry
71仕様書無しさん:03/04/03 21:43
InfoPathはpro版には含まれないようだ。残念。
http://www.zdnet.co.jp/news/0304/03/ne00_office.html
72仕様書無しさん:03/04/04 00:42
>>71
残念だな。
とりあえず触ってみたいが、
うちの会社いつOffice2003買うのかな・・・
73仕様書無しさん:03/04/04 01:23
ユーザのスキル如何のように思う。
Officeシリーズ、特にAccessとExcelを扱える管理者が居たりすると、
定型帳票ではなく、CSVだけ吐いておいてくれればOKという要求仕様もあったりする時代だからなー。

いままでGUIロジック構築で喰われていたコストが低減できるのなら
導入の検討は十分になされるだろうね。

しかしそれとは別にVBプログラマの失業はもうとっくに始まってるような気がする。
PG行程だと人月45万前後が相場だよ(東海地方)。
メタフレーム方式で延命を試みても、それならJavaでWebやりたいっていう案件ばかりだ。

かといってSEの失業まではいかないと思うよ。
所詮はWindowsプラットフォーム、システムの規模が小さいんだから
コロコロとトレンドを換えていく4GL言語の世界がこの業界の全てと思っちゃいけないと思うよ。

74仕様書無しさん:03/04/04 02:10
>>73
そーゆー本気で”みっしょんくりてぃかる”な仕事は
売上は大きいんだろうけど、
SE全体に占める従事するSEの人数割合は小さくないですか?

75仕様書無しさん:03/04/04 02:38
>>73
こちらはVBプログラマの人月は35万前後だ。はは。笑えるぜ。なんちゅー
安値だ。近頃.netの案件が多くなってきた。でも、人月50万。

ははははははははははははははははははははは

ちゃんちゃら可笑しいぜ。
76仕様書無しさん:03/04/04 02:43
>>75
Javaよりいいな・・・。
77仕様書無しさん:03/04/04 03:03
.NETの方が給料良いのか。
俺も.NETプログラマーになろうかな。
7875:03/04/04 03:08
>>77
止めた方がいい。ロクな事がない。.netと言ってもASP.netだし。
C#の方がまだ金取れると思うよ。まだまだ案件は少ないけど。
と言うか、、、、未だに1件しかないYO。
7975:03/04/04 03:10
すまね。思いっきりスレタイから変わっちまった。ここで単価の話は
終了。
80仕様書無しさん:03/04/04 03:43
それでも高い方が良いよ。贅沢はいえない。
金を稼ぐためには.net & C#に決まりだな。
8175:03/04/04 03:49
>>80
待て待て。ちょっと待て。決めちゃいかん。ちゃんと自分でASP.netを
使ってWebサーバを立ててからにした方が・・・
ログインとかクッキーとかを重点的に調べてやってみた方がいいかも。
俺のやり方が悪いんだろうけど、クッキーに異常がよくあったし。
ASP.net+SQLServer2000でやったが、破滅的な状態になったぞ?

よーく考えてみそ。
82仕様書無しさん:03/04/04 04:03
>>81
具体的な現象が知りたい。
ココじゃなくて、C♯スレとか@ITの掲示板でね。
83仕様書無しさん:03/04/04 11:06
>>75は忍月35万なのに、よく研究してるなあ。えらいなあ。
8475:03/04/04 12:05
>>82
うーむ、、、なった現象を記載してみるかな。
去年10月頃にASP.net+SQLServer2000で懸賞系サイトを作った。紹介だけね。
おっと勿論今でも稼動してる奴。自分のサイトね。今は大体・・・80000/Day
ぐらい。んで、ID、Passを入力する手間を省いて貰う為にクッキーを見てOK
であれば、ログイン無しでいけるようにしていた。ところがところが。
何故か別の人のクッキーを読んでいた。信じられない現象だが実際に起こった。
つまり、Aさんがログインしようとして何故かBさんでログインすると言った感じ。

他に、こちらでは幾らでもログイン出来るのにログイン出来ない人が多数いた。
こちらは今でも修復できていない。出来る人と出来ない人がいる。パスワード入力
とかも間違えてはいないようだ。更に、絶対にNULLが入ってはいけないフィールド
に何故かNULLが入る。NULLを許容しないにしているにも関わらず。
負荷が高くなると起こりやすい現象かも知れない。正確に掴んで居る訳ではないよ。
ただ、不可思議な現象が起こるのも確か。
85仕様書無しさん:03/04/04 13:33
読んでて恥ずかしいからそれくらいにしておきなね。間違っても本スレに投げちゃだめよ。
86仕様書無しさん:03/04/04 17:48
>>85
だったら解決策を教えてやれ。また口だけか。
これはな。れっきとした解決策のないバグなんだよ。負荷集中による不信な挙動
だ。しったかを言うなよ。こっちが恥ずかしい。
87仕様書無しさん:03/04/04 18:48
教えてやれ?誰にですか?文章変ですよ。人称をはっきりしてくださいね。

>れっきとした解決策のないバグなんだよ。
ほほー。MSがバグと認めたんですね。それじゃあきっとHotFix作ってもらえますね。
なんたってそんなに負荷がかかるサイトを作ってるんだから。MSのマーケティングが
放っておかないでしょ。

大体クッキーでログインなんてひろみちゅに殺されっぞ。(w
ところで絶対NULLが入ってはいけないフィールドって何?(ww
88仕様書無しさん:03/04/04 19:04
>>87
「人称をはっきりしてくださいね。」という台詞は、
どなたに向けて発せられている発言なのでしょうか?w
89仕様書無しさん:03/04/04 23:11
初心者質問で悪いんだけど、80000/Dayって、1日80000アクセスっつーこと?
すげーな。俺そういうのやったことない。涙。
90仕様書無しさん:03/04/05 02:33
>> 75
ACTか何かできちんと負荷テストした?
91仕様書無しさん:03/04/05 09:48
>>90
個人でたらたらっと作った奴だろうから、そんな物はしていないのではないか
と想像出来るな。

>>87
本当に口だけなんだな・・・ MSがそんな事を公式に認める訳ないだろーが。
おまえは知らないかも知れないが、同時1000Session程度からNULLが入る
事は有名なのよ。でも未だに直ってないバグなのよ。ついでにMSはほったらかし
のバグが多い。それすらも知らないのね・・・
92仕様書無しさん:03/04/05 12:53
>>91
口だけは君のほうでしょう?MSが公式に認めたバグはたくさんあるし、HotFixがたくさんあるのも知らないの?
MSのバグFIXはサービスパックだけだと思っている?

それで純粋な興味なんですけど、同時1000Session程度から、どこにNULLが入るんですか?
まじめに興味があるので教えてください。私もASP.NETのプロジェクトに入りそうなものですから。
またはヒントとなるURLだけでもぜひ教えてください。知りませんでしたので。
93仕様書無しさん:03/04/05 12:55
間違えてsageちゃいました。
94仕様書無しさん:03/04/05 13:49
>>92
だまれ。雑魚。
95仕様書無しさん:03/04/05 14:47
>>94
えーっ、そういう反応がくるとは思わなかった......
96仕様書無しさん:03/04/05 19:01
>>87
ところで絶対NULLが入ってはいけないフィールドって何?(ww
>>92
>>それで純粋な興味なんですけど、同時1000Session程度から、どこにNULLが入るんですか?

>>84で「NULLを許容しない」にしているにも関わらず。
とあるから、そういう設定をしているフィールドでしょ。具体的にどんな項目か知る必要はないでしょう。

フィールドはNULLを許容する かつ 業務側はNULLを許容しない
なら業務側に原因があるかもしれないが。
97仕様書無しさん:03/04/07 09:15
>>96
プライマリキーの項目にNULLが入ってたりして・・・(w
98仕様書無しさん:03/04/07 09:49
非NULL制約がある属性にNULLが入ることがあるの?
致命的じゃん。
99仕様書無しさん:03/04/07 21:18
頼むからバグ疑惑の話題はC♯スレでやってくれ…

Office 2003――6つ(あるいはそれ以上!)の版のどれを選ぶか
http://www.zdnet.co.jp/news/0304/07/cead_coursey.html
> XMLスキーマ、リストコントロール(Excelをより効率のいいデータベースにするとされる)の
> 機能を備えており、これらを“Pro版”と呼ぶことで、Microsoftは大企業顧客に対して追加料金を
> 請求することができる。
> これら機能のほとんどはかなり複雑で、私を含む標準的なユーザーはおそらく手を出さない方がいい。
吉松タン、出番だぞw
100仕様書無しさん:03/04/12 18:53
Office 2003、XMLフルサポートは一部版のみ
http://www.zdnet.co.jp/news/0304/12/nebt_16.html
101仕様書無しさん:03/04/12 21:00
NULLと空白の違いが分かっていないに10000ブッシュ
102仕様書無しさん:03/04/12 22:00
このXMLを読み込んで。データ操作をするCOMモジュールが出る
VBScriptで操作可能
103山崎渉:03/04/17 12:09
(^^)
104山崎渉:03/04/20 06:19
   ∧_∧
  (  ^^ )< ぬるぽ(^^)
105仕様書無しさん:03/04/25 21:17
アドビ、Web/XML/PDFに対応した電子フォーム関連製品などを発表
http://www.zdnet.co.jp/enterprise/0304/23/epn24.html

これ、競合するよね?
106仕様書無しさん:03/04/25 21:53
『”体裁”はお客さんのほうで勝手にどうぞ』ってことになるん?
だったら嬉しいなぁ、やっぱり。
まぁ、そんなに甘くはないんだろうけど。。。
107仕様書無しさん:03/04/26 01:49
え?何よ、その勝手にNULLが入っちまうってバグ。
今ASP.NET使ってるから興味深い話なんだけど。
108山崎渉
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―