[過去ログ] Access総合相談所 28 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
903
(1): 2019/09/12(木)00:03 AAS
客毎の売上明細毎に計算した消費税を積み上げるのと、日次ないしは月次の売上合計から消費税計算するのでは誤差が出る
もちろん日次に計算した消費税を積み上げて月次売上から計算した消費税も誤差が出る
さらに月次で出した消費税を積み上げて年間合計出したのと年次売上合計から(ry

税務署的にはどっちでもいいみたいだけど、敵は身内や客
904
(1): 2019/09/12(木)01:20 AAS
消費税は掛締日の合計ごと・伝票一枚ごと・商品一行ごと とか相手によって変わるから困る
905
(3): 2019/09/12(木)07:25 AAS
レポートで複数のクエリ結果をまとめて出力しようと思っています
高さを自動的に変更することは出来ますか?
906: 2019/09/12(木)07:35 AAS
すいません、サブフォームの高さです
907: 2019/09/12(木)07:54 AAS
>>905
もう少し詳しく。
ただすべての行を広げるなら左の灰色の下境のところで
excelと同じ要領で広げるだけ。
908: 2019/09/12(木)08:17 AAS
>>898
統計学的に言うと
自由度を下げない処理ということだね
909: 2019/09/12(木)08:19 AAS
>>905
印刷時拡張でググって
910
(5): 2019/09/12(木)08:59 AAS
【 システム環境  】 Windows10, Access(office365)
【 VBAが使えるか 】 はい
【 VBAでの回答  】 否
【 検索キーワード 】 access 一部だけ分岐・・・など

以下のような、営業部ごとの売上データがあります

営業部,性別,売上
1,0,100
1,0,80
1,1,150
1,1,70
省15
911: 2019/09/12(木)09:58 AAS
dsum関数使うのが早くない?
912: 2019/09/12(木)10:24 AAS
dsumってand,orや範囲で条件づけの集計できるからif文と組み合わせれば結構いろんなパターンで集計できるよ
913
(1): 2019/09/12(木)12:11 AAS
>>905
ちなみに印刷時拡張では罫線まで拡張されなかったかも
印刷時のイベントでlineメソッドで引いて代用してた
914: 2019/09/12(木)12:32 AAS
>>910
選択クエリで営業部と性別のフィールド値を条件とした新たなフィールドを追加して
それを元に集計
915
(2): 2019/09/12(木)12:49 AAS
>>910
売上データテーブルの全フィールドを選択したクエリを作り

性別_:Iif([営業部]<>1”-“,iif([性別]=0,”男”,“女”)
というフィールドを追加
(フィールド名はなんでいいけど)

このクエリを元に集計
でいいんじゃね
916: 2019/09/12(木)12:51 AAS
>>913
印刷時じゃなくてページフォーマット時だったかも
917: 2019/09/12(木)13:39 AAS
>>910
男女雇用機会均等法に思いっきり抵触しそうやなw
別の区分を言い換えてるだけかもしれんけど。
私は>>915に一票。
918: 2019/09/12(木)19:12 AAS
>>910です、ありがとうございます!

>>915
さんの方法で行ってみます
919
(1): 2019/09/12(木)21:40 AAS
>>910です。仕様変更になりました。

【 システム環境  】 Windows10, Access(office365)
【 VBAが使えるか 】 はい
【 VBAでの回答  】 否
【 検索キーワード 】 access 一部だけ分岐・・・など

以下のような、営業部ごとの売上データがあります

営業部,性別,年齢,カテゴリ,売上

営業部1は性別ごとに集計
営業部2は年齢30未満、30以上で集計
営業部3はカテゴリ(A・B・C)で集計
省14
920: 2019/09/12(木)21:41 AAS
カテゴリというのは商品カテゴリです
921
(2): 2019/09/12(木)22:07 AAS
そもそも、属性フィールドにいろんなのをまとめるのがまちがいでは?

性別、年齢(層)、カテゴリの3つのフィールドに分ければ簡単になるのに

すでに属性フィールドにひとまとめに入力されているのであれば、新たに3つフィールド作って、更新クエリかければいい
922
(3): 2019/09/12(木)22:09 AAS
>>921
いえ、データ自体は
営業部,性別,年齢,カテゴリ,売上
この形です

営業部ごとの特性をみたいようで、属性を1カラムにして用意してほしいとのことです
923
(1): 2019/09/13(金)07:30 AAS
>>922
>属性を1カラム
となると営業部毎に選択クエリ作って
それぞれの属性のフィールドを追加して
(フィールド名は“属性”とかで統一)
それらをSQL文にして
Unionクエリにまとめて
営業部と属性でグループ化して集計
924
(2): 2019/09/13(金)08:07 AAS
>>922
統計情報で軸が違うのを一つにまとめるのは
やや心地悪い。レポートにするなら3つのサブフォームを張り付けるか
915の技を応用すれば良いのではないかと。
あるいはデータベースの基本ルールは1列に格納するものは同じ属性の情報、であるので
accessのテーブルからexcelにリンクしてピボットテーブルで軸を変えればいいのではないかと。
また、人属性情報は改変性低いのでマスターテーブル化してリレーションシップ作れるよね。
それはもうやってる?
925
(1): 2019/09/13(金)08:24 AAS
>>921
属性:Switch([営業部]=1,iif([性別]=0,”男”,”女”),[営業部]=2,iif([年齢]<30,”-29”,”30-“),[営業部]=3,[カテゴリ])
でもええか
ただ、もっと複数になると営業部毎に属性設定してunionクエリでまとめる方が楽かと思われ
926
(1): 2019/09/13(金)12:05 AAS
>>924
気持ち悪いといえば、年齢
年齢はテーブルに記録しない
生年月日を記録して演算で出す
まあ、そこら辺は説明で省略してるのだろうけどね
927
(1): 2019/09/13(金)12:53 AAS
>>922
>営業部ごとの特性をみたい
のなら様々な属性でグループ化して集計
更にグラフ化すべきかと

あと年齢は生年月日と販売日のDateDiffで求めてるよね?
928
(1): 2019/09/14(土)16:26 AAS
【 システム環境  】 Windows10, Access(office365)
【 VBAが使えるか 】 はい
【 VBAでの回答  】 否
【 検索キーワード 】 access 一部だけ分岐・・・など

顧客のユニークIDの数を調べたいと思っています
グループ化してすぐにカウント、のような事は出来ますか?
クエリテーブルを二重にすれば出来ますが、なんか間違ってる気がします
929: 2019/09/14(土)16:31 AAS
すいません、返答を送信していませんでした

>>923
了解です!uniion使っていきます

>>924
試してみましたが、サブフォームだと高さがに困ってしまいました
vbaを使えれば可変の高さ調整ができそうな感じはしているのですが、なかなかそっちまで勉強している時間が無いです・・・

>>925
恐らく複雑になると思います。昨今の流れで、性別とか増えそうで戦々恐々としています

>>926>>927
入っているのは生年月日です
省2
930
(1): 2019/09/14(土)16:44 AAS
>>928
少なくとも昔は、AccessのSQL規格が古くて、他のデータベースで
SELECT COUNT(DISTINCT customer_id) FROM order_table
と書けるものも、
SELECT COUNT(customer_id) FROM (SELECT DISTINCT custoemr_id FROM order_table)
とサブクエリみたいにして呼ぶ必要があった。
いまも変わってないなら、二重にするのは変じゃないです。現状は未確認ですが。
931: 2019/09/14(土)16:53 AAS
>>930
あれ、そうなんですね
ありがとうございます、素直に二重にしておきます
932
(1): 2019/09/14(土)19:09 AAS
【 システム環境  】 Windows10, Access(office365)
【 VBAが使えるか 】 はい
【 VBAでの回答  】 否
【 検索キーワード 】 access プロンプト 初期値 など

プロンプトの初期値は設定できないでしょうか

Between [開始日を入力してください:] And [終了日を入力してください:]
としているのですが、
予め前月を入れたいのです
具体的には
#2019/8/1#
省4
933
(3): 2019/09/14(土)20:15 AAS
>>932
それはプロンプトじゃなくて既定値では?

既定値なら
テーブルのフィールドやフォームのテキストボックス等のコントロールで既定値を設定することができるので
そこに入れる。

なお、先月1日は
=DateSerial(year(Date),Month(Date)-1,1)
Dateとはシステムの日付を取得する関数で()付けても付けなくても同じ
DateAdd関数使わなくてもきちんと年またぎ出来るよ。

また先月末日は
省2
934
(2): 2019/09/14(土)21:35 AAS
>>933
入力の時ではなく、selectクエリで抽出する時の範囲を自動で決めたいのです
935: 2019/09/14(土)22:15 AAS
フォームにして引数みたいな感じで渡せば良いよ
936
(2): 2019/09/15(日)00:02 AAS
>>934
クエリでも>>933の式を入れるだけやろ
抽出条件に
>=DateSerial(year(Date),Month(Date)-1,1) AND <=DateSerial(Year(Date), Month(Date), 1)-1
とな

それにしても、既定値のことでないとすると、プロンプトとは何だろなと
通常、プロンプトってCUIで入力可の状態を示すサインやろ
それ以外に解釈できんのだが?
DBMS用語ではないし
937
(1): 2019/09/15(日)00:35 AAS
>>934
抽出条件は
Between DateSerial(year(Date),Month(Date)-1,1) And DateSerial(Year(Date), Month(Date), 1)-1
でも可
また
Like Format(DateAdd("m", -1, Date),"yyyy/mm") & "*"
でも可
938: 2019/09/15(日)09:13 AAS
>>936
>>通常、プロンプトってCUIで入力可の状態を示すサインやろ

CUI限定じゃなくて、GUIでウィンドウを開いて入力を促す文字もプロンプトでいいと思う
VBAのInputBox関数の引数名もPromptだし
ただ、この質問での話だと既定値の間違いだと思う
939
(1): 2019/09/15(日)12:34 AAS
DBサーバー立てたくない時、
mdbまたはsqliteかなと思うけど、
みなさんならどうしますか
さらにいえばVBA古臭いし冗長なのでC#で+mdbが最適解なのかなと
940: 2019/09/15(日)12:59 AAS
周りが使いやすい奴が良い
確実に自分だけしか使わない+ちょっとしたものでいいならmdbかな
941
(1): 2019/09/15(日)13:07 AAS
Access採用の理由は利用ユーザーのPCにインストール済みだからって事が多いと思うな
942: 2019/09/15(日)15:02 AAS
>>941
ランタイム入れればインストールしてなくても
Accde動かせるけどね
943: 2019/09/15(日)18:32 AAS
sqliteもdll拾ってくればドライバいらないけど、
どうも動きが怪しい気がする
944
(1): 2019/09/15(日)19:21 AAS
>>939
sqliteという選択肢を持ってくるのは、単にAndroidアプリの開発手法に似せたいから?
それであれば、環境設定も含めたインストールパッケージを作成する必要があるから
無理にAccessで作る必要はないとおもうけど。
945
(1): 2019/09/15(日)20:40 AAS
>>944
VBAは要らない、Pythonで組むということではないかと
VBA抜いてもAccessはクエリの組み易さ,フォームやレポートの作り易さの利点があるから
それも活かしたいんだろうな
でもいっそDelphi上で全部設計した方が見通し良くなると思われ
946
(1): 2019/09/16(月)09:11 AAS
【 システム環境  】 Windows10, Access(office365)
【 VBAが使えるか 】 はい
【 VBAでの回答  】 否
【 検索キーワード 】 access フォーム テキスト 取得 クエリ など

フォームに配置したテキストボックスの情報をクエリに含めたいのですが、どのように記述すれば良いでしょうか?

抽出条件に
[フォーム1].[テキスト4]

[フォーム1]![テキスト4]
としてみましたが、駄目でした
省2
947: 2019/09/16(月)09:14 AAS
>>936>>937
ありがとうございます!
accessではパラメータというのですね
単語間違ってしまい、すいません
948: 2019/09/16(月)09:29 AAS
>>946ですが自己解決しました

[フォーム1].[テキスト4]

[forms].[フォーム1].[テキスト4]
でした
949
(1): 2019/09/16(月)09:36 AAS
>>933
さんの
=DateSerial(year(Date),Month(Date)-1,1)


規定値に入れると
DateSerial(Year([Date]),Month([Date])-1,1)

抽出条件に入れると
DateSerial(Year("Date"),Month("Date")-1,1)

と変換されてしまい、うまく動きませんでした
date()にすると解決しました
省1
950
(1): 2019/09/16(月)12:21 AAS
【 システム環境  】 Windows10, Access(office365)
【 VBAが使えるか 】 はい
【 VBAでの回答  】 否
【 検索キーワード 】 access 式が正しく入力されていないか、複雑すぎるために評価できません エラー

フォームを作っていてエラーが発生し、解決しました

サブフォームを作成し、クエリを表示させ、更新を行うとエラーになりました
https://i.imgur.com/Njzkz8f.png

その下にも別のクエリがあり、こちらはエラーになりません
https://i.imgur.com/9nxg60w.png

なんとなく位置を変えた所、エラーにならなくなりました
省3
951: 2019/09/16(月)14:59 AAS
>>949
参照設定に依るかもね
Date()は関数、Dateはシステム変数だったかな
952
(2): 2019/09/16(月)15:54 AAS
フォームってデザインビューの状態でも、フォーム内の情報を取り出せるの?
953
(1): 2019/09/16(月)16:19 AAS
>>950
そのエラーの原因は様々ある
AccessのJITコンパイラが解釈に失敗すると出る
大きな原因のひとつはリレーションシップをしていないこと
コントロールの位置をいじって直ったとしても
再発の可能性は高い
JITコンパイラが何処まで解釈出来るのかははっきりとしないが
経験上、メッセージにある通り
一つのクエリでアレもコレもとやらないで
クエリを元にクエリを作るなどしたり一つのクエリでの処理を単純化したり
省7
954: 2019/09/16(月)16:33 AAS
>>945
Delphi良いよな
おっさんかよ
955
(2): 2019/09/16(月)17:15 AAS
>>953
DBから吐き出されたデータを元に、収支の集計を行っています

・元データは40000行、50カラムほどあります(小売の売買データです。様々なテーブルをjoinした後の一覧データが吐き出されています)
・もうひとつ、販売の種類を表すテーブルがあります。2フィールドで10行、「通常販売」「ネット販売」「社内販売」など。最後にjoinします
※リレーションで繋ぐフィールドは両方「数値型」になっていました

・クエリの流れ。一行が1クエリです
フォームの日付を元にフィルタ
キャンセルデータ(キャンセルフラグフィールドが1だと除外)、お試し商品を除外(あるフィールドが「2」だと除外)、
営業部でフィルタ(営業部ごとに3種類、>>919のように分類・集計します)
顧客IDでグループ化
省5
956
(1): 2019/09/16(月)20:53 AAS
読めないくらいややこしいw
フィルターって、なんとなく重いから個人的には使わないこと多いかな。
パラメーター仕込んでおいて、vbaのquerydefのパラメーター代入してrequeryしたりする。
あとinner join inner joinを何個も繋げてると自分でもワケわからなくなるのでクエリー何個かにわけて
段階を踏む作り方する。
957
(1): 2019/09/16(月)21:14 AAS
主キー無しって重くならない?
3万行ぐらいならそうでもないんかね
958: 2019/09/17(火)00:10 AAS
>>955
>>957
主キーは設定すべきでしょう。
そうすれば1対多の関係が明確になります。

>もうひとつ、販売の種類を表すテーブルがあります。2フィールドで10行
>※リレーションで繋ぐフィールドは両方「数値型」になっていました
販売の種類を表すテーブルのそのフィールドを主キーに設定

>>956
段階を踏んだ方が、作るのも、機能の追加による修正も楽なんですよね。
大本のクエリから派生とかできますからね。
959: 2019/09/17(火)00:38 AAS
>>955
エラーの原因はおそらく主キーを設定していなかったことでしょう。
それ以外は段階を踏んでいるから問題無いです。
960
(1): 2019/09/17(火)01:07 AAS
アクセスで高度なものを作っても単体アプリケーション化できないのが一番駄目なところだね
ランタイムもイマイチだし
アクセスからだとデータベースを直接書き換えられるリスクがあるしかっこ悪い
961: 2019/09/17(火)06:33 AAS
>アクセスからだとデータベースを直接書き換えられるリスクがあるしかっこ悪い
それはDBをいじれるどんなアプリでも同じでは?
962
(1): 2019/09/17(火)06:52 AAS
>>960
それ、アクセス制御での完全性の問題ではないか?
どのアプリがという問題ではないのでは?

ランタイムがイマイチという意味も分からない。
どうイマイチなんだろう?

俺の場合、単体アプリを作るためにAccess使ってる訳じゃなくて
日常の事務作業を楽にするために使ってるだけ
無論だけど、俺には権限が無いから、会社の基幹システムのDBを直接干渉したりは出来ないが、
そこから取り出したデータを元に報告書を作ったりはしている。
963
(1): 2019/09/17(火)08:14 AAS
>>962
そういう余計なことをする奴が出てくるのが管理上は問題になるんだよ
964
(1): 2019/09/17(火)12:01 AAS
元データ触れないor分からないから、それを元に別データ作っといたで(以下ループ)
965: 2019/09/17(火)12:03 AAS
>>963
余計な事とは?
それが仕事なんだが?
何が言いたいのか?
966
(1): 2019/09/17(火)12:12 AAS
>>964
それシステム管理として失敗してるやん
そんな愚痴をこのスレで言われてもな
967
(1): 2019/09/17(火)12:21 AAS
アクセスだとテーブル直接書き換えをするのが簡単だから、安全性を担保できない
酷い仕様だよ
968: 2019/09/17(火)12:26 AAS
>>966
失敗例を横から書いただけで主とは関係ないのに愚痴とか言われてもな
969: 2019/09/17(火)12:27 AAS
性能も安全性も全体的に退化させてるのが酷い
970: 2019/09/17(火)13:02 AAS
>>967
テーブルを完全に隠せよ
俺が5年くらい前に書いてやった手法を使え
971: 2019/09/17(火)13:06 AAS
知らんけど、そこまで嫌なら他DBへお引越しすればいいだけで
ここでぐだぐだ文句言って改善するものでも無し

早い・安い・うまい がうたい文句の外食産業も有りゃ、
高級食材を四ツ星シェフがお料理して、最高級グレードのお持て成しをしまっせも有る
ミソクソ一緒に比較したって何の意味も無い 時間の無駄

データベースファイル自体にパスワード付けられるんだし、セキュリティだの改竄だの
気が気で無いなら、それなりのセキュリティに注力するだけのこと
レコードの必要な部分にだけアクセスできるようにするとか、無闇に接続しようとする輩が
居るような環境なら、そこをブロックできるように改善するだけのこと Access の問題では無い  個人の感想やけど
972: 2019/09/17(火)13:34 AAS
まあまあ二人ともそんなに熱くならないで。
accessはreadonly権限を与えるのが逆にマイナーな技になってしまうのは事実だし。
一方で、「私だけが欲しい集計軸」のためにシステム管理の手を煩わせないことも大切だとも思うし。
私は、一般的なスキルを信用してる社内ユーザーには、sqlserverのビューからexcelにreadonlyの接続詞つけて
一覧貼っておき、「更新は右クリックで「更新」押せ、あとは好きに集計しろ」といったことをやってるけど。
973: 2019/09/17(火)17:36 AAS
>>Read Only
だとExcelで使え、となる会社も有る
VBAでデータ抜いて編集ってしんどいだけ
974
(1): 2019/09/18(水)01:47 AAS
>>901-904
ちょうどこの件でセブンがまたやらかし(?)てしまったようだな
https://www3.nhk.or.jp/news/html/20190918/k10012086721000.html

やはり敵は税務署ではなかった
975: 2019/09/18(水)02:00 AAS
>>974
ははは、ニュース見てこのスレに来てしまった
これってマーフィーの法則でトラブルの可能性のあるものは必ずトラブルを起こす、っていうやつ。
すべてのケースに対応できるようにしておかないとな。
経理のスタッフとかめちゃくちゃ機嫌悪くなるというかまともに話してもらえなくなる
976: 2019/09/18(水)04:46 AAS
やらかしたというか、これは仕方ないことなんじゃないのかね
977: 2019/09/18(水)05:09 AAS
周知不足でネットで騒がれちゃって後手に回ってしまったやらかし
内税積み上げ方式のまま軽減税率に対応することができたのに外税に切り替えちゃったやらかし

7payとか時短営業の案件レベルではないけど、だからこそこれくらいきっちり詰めとくべきでは
978: 2019/09/18(水)06:07 AAS
少なくとも10月1日付での変更で、周知してれば何も問題なかったのでは
979
(2): 2019/09/18(水)07:12 AAS
問題の次元としてはどうでもいいっちゃどうでもいいけどね
違法とかではないし

でも個人的にはせっかく10%という切りのいい税率のくせに1円単位の端数が出てしまうのは欠陥だと思ってる
スーパーみたいにどうあがいても1円単位の端数が出るような店なら分かるけど
980: 2019/09/18(水)12:56 AAS
>>979
端数切捨てで税務署もええと言ってるんだから
それでええねん
世文はまた顧客に嫌われることをやったな
981: 2019/09/18(水)12:58 AAS
>>979
こういうのってさ
いくつかの計算方法をやって
ゴールシークで最適なの求めれば
済むんけどね
そういう発想すらしなうのかよと
どんだけ無能なのか
982
(1): 2019/09/18(水)16:37 AAS
なぜ総合計を再計算するんだ。内税計算するなら総合計は単純合計で、そこから「うち消費税」を整えて表示、差し引きを本体価格にすれば良いものを。
983: 2019/09/18(水)17:33 AAS
>>982
世文が無能だから
984: 2019/09/18(水)17:37 AAS
違法でなければ良いという浅はかな考えで
計算方法を変えて
1円でも値上がりしたら、客離れを起こすという事態を想定出来ない無能経営者
985: 2019/09/18(水)17:44 AAS
ポイントのメリットをなくした上で消費税でポイント以上に客からお金取っちゃうなんて、すごい無能よね
986
(1): 2019/09/20(金)20:49 AAS
そもそもデジタルセキュリティの知識無い社長をみずほからヘッドハントするくらいだし
987: 2019/09/21(土)11:41 AAS
>>986
みずほ
システム統合に失敗してるのが
経営陣の方針がコロコロ変わって
仕様が確定できんためだとか
結局 無能やったんやな

なんでそんな屑を引き抜いたんか
みずほから押し付けられたんちゃう?
988: 2019/09/21(土)13:27 AAS
経営者「ボクはITに詳しいんだ」

どこかで耳に入れてきた知識を社内でかき混ぜる無能がクソ憎い
989: 2019/09/21(土)15:04 AAS
掻き混ぜられようと、クズが上に居ようと、ムダな会議で時間が取られようともだ
実務は止まらない 待ってくれない 粛々と実績を積み上げるしか無い  個人の感想やけど
990: 2019/09/21(土)17:19 AAS
エライエライ
991: 2019/09/21(土)21:08 AAS
みずほはシステム統合自体、それまでPL/Iで動いてた銀行有るからCOBOLで統一するしか無かった
勘定系は未だにメインフレームだよ
OpenCOBOL導入すら出来て無い
992
(1): 2019/09/23(月)13:30 AAS
>>952
お願いします

起動後は一回フォームを呼び出さないと駄目なんでしょうか?
微妙に挙動が良くわかりません
993: 2019/09/23(月)13:43 AAS
他の人には質問の意味がわかりません
994: 2019/09/23(月)14:04 AAS
なにをどうしたいのかを書かないと >>952 お願い ったって、何が何だか
フォーム内の情報を、「どこ」から読みたいんだか
そのフォーム自体はどういう構造なんだか コチラには何にも伝わらないよ

データベースの中身を他のアプリから読みたい ってんなら、フォームなんか要らないし
フォームのソースがクエリとかで整えられたデータだ ってんなら、デザイン状態じゃ読めないし
おまえの挙動が良く判らんわ
995: 2019/09/23(月)17:40 AAS
フォームの情報はデザインビューでも取得できるよ
既定値に入れておけば良い
996: 2019/09/23(月)17:53 AAS
次スレ要る?
997: 2019/09/23(月)18:00 AAS
居る
スレタイに、"桐にしとけ" って入れてね
998: 2019/09/23(月)18:04 AAS
>>992
そう
フォームビューかレイアウトビューで開いておけばバックグラウンドで起動する
閉じた状態では既定値だろうがなんだろうが取得できない
999: 2019/09/23(月)20:06 AAS
次スレ
Access総合相談所 29
2chスレ:bsoft
少しテンプレ変更しました。
1000: 2019/09/23(月)22:09 AAS
みんながんばろー!
1001
(1): 1001 Over 1000 Thread AAS
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 388日 22時間 53分 10秒
1002
(1): 1002 Over 1000 Thread AAS
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。

───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
省4
1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.297s*