FAQ
技術的な質問> データベース
技術的な質問> データベース
Q94：MySQL自動連番生成(オートインクリメント)で突然連番がおかしくなった。
Q94-1：
取引マスターIDの自動連番生成(オートインクリメント)で、突然1000番台になりました。(添付エクセルファイル参照ください)
受入入力(受入入力の自動連番IDの値と似ているので 、、、)と並行して使うと フィニッシュUPDATEの番号がそのまま マスター更新時に影響をうけるものでしょうか? 試しに同時に使ってみましたが、問題は出てきませんでした。
受入入力(受入入力の自動連番IDの値と似ているので 、、、)と並行して使うと フィニッシュUPDATEの番号がそのまま マスター更新時に影響をうけるものでしょうか? 試しに同時に使ってみましたが、問題は出てきませんでした。
A94-1：
2点質問がございます。
１）取引マスターの全データを取得（Select * from tori_mas 等)して点検した場合、全くばらばらにIDが振られているでしょうか。それとも何か規則性が発見できるでしょうか。
２）取引マスターのテーブルは、a:削除は基本的に行わず、Insert、Updateで追加・更新のみが行われる、b:不要になったデータがあれば削除してしまう、のどちらの方針で更新されているでしょうか。
１）取引マスターの全データを取得（Select * from tori_mas 等)して点検した場合、全くばらばらにIDが振られているでしょうか。それとも何か規則性が発見できるでしょうか。
２）取引マスターのテーブルは、a:削除は基本的に行わず、Insert、Updateで追加・更新のみが行われる、b:不要になったデータがあれば削除してしまう、のどちらの方針で更新されているでしょうか。
Q94-2：
1については、
2828、2819と連番で登録されている場所もあれば、7000と一気に1000番台まで飛んでる数字もあります。
2については、
bの不要になったデータがあれば削除しています。
2828、2819と連番で登録されている場所もあれば、7000と一気に1000番台まで飛んでる数字もあります。
2については、
bの不要になったデータがあれば削除しています。
A94-2：
以下原因確定の手掛かりになれば良いのですが、
MySQLの自動連番はデータInsertの際、自分で意図的に番号を付けることもでき、その番号が使用されているものでなければ受け付けられます。
例えば急に「8000」に番号が飛んでいる場合、その番号を自分で付けてしまった可能性が高いと考えられます。
その後連番「8001,8002...」となっているのであれば、その間のデータはID値はNULLでInsertされ、自動採番されていたのでしょう。
幾つか飛んでいる箇所はあるかと思うのですが、飛んでいる先頭の番号に何か見覚え（他のデータテーブルで使用していた）はないでしょうか。
Insert文に記述してあれば発見しやすいかと思いますが、テーブルやテーブル格納変数のデータを用い「InsertDirectly()」などでテーブル全てInsertやUpdateをしている箇所も、どうぞご点検ください。
特にテーブル格納変数など、前に設定されたデータがそのまま残っている可能性もあるかと存じます。
MySQLの自動連番はデータInsertの際、自分で意図的に番号を付けることもでき、その番号が使用されているものでなければ受け付けられます。
例えば急に「8000」に番号が飛んでいる場合、その番号を自分で付けてしまった可能性が高いと考えられます。
その後連番「8001,8002...」となっているのであれば、その間のデータはID値はNULLでInsertされ、自動採番されていたのでしょう。
幾つか飛んでいる箇所はあるかと思うのですが、飛んでいる先頭の番号に何か見覚え（他のデータテーブルで使用していた）はないでしょうか。
Insert文に記述してあれば発見しやすいかと思いますが、テーブルやテーブル格納変数のデータを用い「InsertDirectly()」などでテーブル全てInsertやUpdateをしている箇所も、どうぞご点検ください。
特にテーブル格納変数など、前に設定されたデータがそのまま残っている可能性もあるかと存じます。