みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
いつも大変お世話になっております。
顧客T -----< 点検一覧T
という、リレーションで点検票を作成しようとしています。
複数人で点検をしていて、一人当たり年2500回ほど点検レコードが発生する想定です。
この点検票に点検番号を付与するにあたって、次の要件を満たせるものを検討しています。
・ユニークであること（主キーとなるUUIDは別にあります）
・できれば短い桁数のもの（最大12桁くらいでテキストと数字の混合でも可）
・点検票をPDF出力したときに管理しやすいよう、ファイル名に点検番号を含める予定（日付_点検番号 など）
現在は以下のように単純に考えてGet（アカウント名）＆シリアル番号で作成してみましたが、アカウントごとにシリアル番号を振らないと桁数が足りなくなることに気づいたところで詰まっています。
今の状態
アカウント名は数字３桁にしています（001、002、003・・・・）
シリアル番号は数字６桁（999999/2500で400年分あるため）
点検番号とは別にシリアル番号カウント用のフィールドを作成
フィールドの計算式
Get ( アカウント名 )
& Right ( "000000" & 計算用シリアル番号 ; 6 )
アカウントごとにシリアル番号を付与するための計算式が分からないので教えていただきたいということもあるのですが、
もし他に上記の要件を満たす上手な点検番号の付与方法がございましたら合わせてご教授いただければ幸いです。
何卒よろしくお願いいたします。
Last edited by tak (2023-01-13 10:56:32)
Offline
全レコードを通してシリアル番号を振ります。
自己リレーション
アカウント名 = アカウント名
and
シリアル番号 >= シリアル番号
このリレーションの関連レコード数が求めるシリアル値になります。
ただし、これは途中のレコード削除が有るとだめです。
その可能性はありますか？
ある場合、
その番号は欠番
それ以降を振りなおし
どちらか決める必要がありますね。
Offline
チポ様
ご回答くださりありがとうございます。
まだテストの段階ですので決定ではないですので、方向性でのお話になり恐縮なんですが、以下のようになります。
＞このリレーションの関連レコード数が求めるシリアル値になります。
ただし、これは途中のレコード削除が有るとだめです。
その可能性はありますか？
今のところ誤ってレコードを作成することが多いのでは？と考えられますので、不要な空レコードがたくさんあるのは邪魔なので、点検レコードの削除は論理削除ではなく物理削除で実装する方向で考えております。
＞ある場合、
その番号は欠番
それ以降を振りなおし
どちらか決める必要がありますね。
それ以降を振り直しの方がスマートではあるのですが、デメリットが多い場合は欠番でも運用上問題はありません。
（細かい従業員に欠番だと気持ち悪がられるくらいだと思います）
以上よろしくお願いします。
Offline
欠番にしないのなら、
前設定のフィールドを計算フィールドにすればいいんです。
> 誤ってレコードを作成することが多いのでは
作らせない工夫を考えられたらいかがでしょう。
方法はいろいろ考えられますよ。
Offline
＞ 誤ってレコードを作成することが多いのでは
＞作らせない工夫を考えられたらいかがでしょう。
やはり、物理削除より論理削除の方がよいということでしょうか？（無料のClaris アカデミーで学んでおりまして、削除機能は慎重にとあったのですが、勘所が分かってなくすみません）
点検で使用した商品の請求や集計があるので、レコードがない方が都合がいいかと思ったのですが。
＞全レコードを通してシリアル番号を振ります。
自己リレーション
アカウント名 = アカウント名
and
シリアル番号 >= シリアル番号
教えていただいた通り、リレーションを組み、以下のところまで来ました。
フィールド設定 内容
アカウント名（計算タイプ） Get(アカウント名)
シリアル番号（テキストタイプ） 入力値の自動化 シリアル番号
点検番号（計算タイプ） 点検一覧_点検一覧｜自己_点検番号用::アカウント名 & Right ( "000000" & 点検一覧_点検一覧｜自己_点検番号用::シリアル番号 ; 6 )
ここで3点ほど質問がございます。
１, 点検番号フィールドに、アカウント＋シリアル番号で表示はされるのですが、アカウントごとにシリアル番号が付与されず全アカウントで連番となっているようです。どこかで間違っていますでしょうか？（001000001→001000002→002000003→003000004となってしまう）
２，リレーションのシリアル番号 >= シリアル番号の部分ですが>=ではなくて<=にするとカウントアップしていくのですがこちらで合っていますでしょうか？
3，＞欠番にしないのなら、前設定のフィールドを計算フィールドにすればいいんです。
欠番にしないのならシリアル番号フィールドを計算タイプにするということでしょうか？（欠番にするパターンとしないパターンの両方をテストしてみようとしたのですが、シリアル番号を振る計算式が調べてもわからず欠番解消のテストできずにおります）
Last edited by tak (2023-01-15 00:23:40)
Offline
> シリアル番号（テキストタイプ） 入力値の自動化 シリアル番号
大小の比較をしますから、数字タイプがいいですね。
これは完全な連続したシリアル値ではなくてもいいので、
計算フィールドとして
Get ( レコードID )
でもいいでしょう。
求めるシリアル番号は、前にも書いた通り
> このリレーションの関連レコード数
ですよ。
関連レコード数は
Count関数
で求められます。
> 物理削除より論理削除の方がよい
そうですが、、
それより誤ったレコードを作らせない工夫をしたらいいのでは。
と言いました。
一例ですが、、
入力を全部グローバルフィールドにして、
全て入力後、「確定」で新規レコード作成、それらの値を移す。
必要フィールドに全て入力しないと「確定」ができない。
誤りがぐっと減るでしょう。
Offline
誤りレコードの回避には、最新バージョンなら
トランザクションを開く
が最適でしょうね。
Offline
チポ様
＞それより誤ったレコードを作らせない工夫
事例を教えてくださりありがとうございます。
必要フィールドに全て入力しないと「確定」ができない。と、shin様のおっしゃっているトランザクションの両方をテストしてみたいと思います。
＞関連レコード数はCount関数で求められます。
「このリレーションの関連レコード数」とレコードIDの使い方がとても勉強になりました。
教えていただいた通り設定し、点検番号フィールドを計算タイプにして以下の様にしましたら、うまく動くようになりました。
レコード削除時の挙動（関連レコード数をカウントしているので、レコード削除するとそれ以降のレコードの番号が詰められて再計算されてしまう）もよく分かりました。
点検一覧_点検一覧｜自己_点検番号用::アカウント名
&Right ( "000000" &Count (点検一覧_点検一覧｜自己_点検番号用::シリアル番号) ; 6 )
テストしている中で分からない動きがあったのでもし可能であれば教えてください。
誤ったレコードを作らせない＋削除はなし。の条件で決定なのですが、点検番号フィールドを計算タイプではなく数字タイプまたはテキストタイプとし、「入力値の自動化」→「計算」とすると、
１件目のレコードは空欄、２件目のレコードから001000001と採番されます。リレーションではシリアル番号 >= シリアル番号となっているのになぜ空欄となるのでしょうか？
shin様
トランザクションを開くへのリンクありがとうございます。
現在考えている点検レコード作成の流れは、
新規点検レコード作成→顧客の選択（主キー入力）→点検内容入力という流れですが、この中でどのように実装すればいいか考えてみたいと思います。
Offline
> 点検番号フィールドを計算タイプではなく数字タイプまたはテキストタイプとし、「入力値の自動化」→「計算」とすると、
> １件目のレコードは空欄、２件目のレコードから001000001と採番されます。リレーションではシリアル番号 >= シリアル番号となっているのになぜ空欄となるのでしょうか？
そのレコードを作った状態では、まだそのレコードが確定されていないので、データとして存在しません。ですから、リレーション先のレコードが存在しないので null が返されます。2レコード目も同じで、自身のレコードはカウントされません。
計算にした場合は、リレーション先のレコードを参照していますので、レコードが確定された時点で自動入力の計算式が評価されますので、自身も含まれます。
Last edited by Shin (2023-01-17 08:45:45)
Offline
Shinさんの通りですが、、
試しに点検番号の計算フィールドの
レコード確定前後の動きを見るとお分かりになると思いますよ。
自動入力の場合は式に
+1
を加えて、計算式の指定のオプション
「式内の全フィールドの値が空欄のとき、計算しない」
のチェックを外します。
これでよかったともいますが、、
Offline
shin様チポ様
ご回答ありがとうございます。
＞そのレコードを作った状態では、まだそのレコードが確定されていないので、データとして存在しません。ですから、リレーション先のレコードが存在しないので null が返されます。2レコード目も同じで、自身のレコードはカウントされません。
これを念頭に置いてレコード確定前後の動きを見てテストしてみたところ以下の動きが発生するのでよく分かりました。
1.最初のレコードが空欄となる→自身のレコードはカウントされないから
2.途中のレコードを削除して再度新規レコード作成を行うと、番号が重複する→自身のレコードはカウントされない＋この時点の関連レコード数をカウントしているから
この度は、大変勉強になりました。今後ともよろしくお願いいたします。
Offline
Pages: 1
[ Generated in 0.009 seconds, 9 queries executed - Memory usage: 604.77 KiB (Peak: 621.67 KiB) ]