＊おすすめ書籍：失敗しないデータベース 設計

Access はインポート機能が充実してるよね。Excel で好きなようにデータを並び替えて、CSV ファイルに出力。
うんうん、中身は当然思ったとおり並んでる。さて、あとはインポートするだけか。
Excel で並び替えてるんだし、レポートでもフォームでも特に並び替えなんて指定する必要ないさ。
テーブルには主キーがないから、当然 CSV ファイルと同じ並びなんだしね。
……このようなつもりで設計している方はいらっしゃいませんよね？

Access はリレーショナル型データベースソフトです。リレーショナル型データベースの利点のひとつとして、いつでも手軽に好きな項目で指定したとおりに並び替えができることが挙げられます。
このため、リレーショナル型データベースでは、並び順を指定しない場合、どんな順番に並ぶか保証されません。
テーブルで指定した主キーの順に物理的に並んでいるとか、データが追加された順に並ぶということはありえません。
さらに Access は、データの登録順序をファイル内に持ちません。mdb ファイル内のどの部分に何番め（に追加処理をした）レコードが挿入されるかは、その時の HDD の状態しだいです。オートナンバー型の項目でも持たないかぎり、どんな順番で登録されたかは闇に葬られます。

「えーうそだね、ウチが作ったテーブルはいつだってデータ登録順にちゃーんと出てくるぜ」という方は、たいへん運がよろしい。たまたま HDD 内に連続した空き領域があり、いままで常にきちんとデータが格納されていたのですから。
ですから、並び順を指定しない場合、HDD をデフラグしただのMDB ファイルをコピーしただのといったことでデータ格納順が変わる可能性は十分すぎるほどあるのです。(実際、無償サポート時代にそういう問い合わせを受けたことがあります)

テーブルをデータシートビューで開いた時には、主キーの順に並び変わって見えています。これは、Access のテーブルデータシートビューが暗黙のうちに主キーで並び替えを行っているからです。つまり、データシートビューの機能なんです。
テーブル型レコードセットを作ったときも、データは主キーの順に並ぶわけではありません。どんな順番で読み込まれるかは予想がつきません。

このような理由で、「テーブルをただ CSV にエクスポートしただけなのに、テーブルを開いて見たときと CSV ファイルの中身の並び順が違う！」ということは至極当然です。
きちんと保証したい並び順があるなら、それを指定しなければいけません。主キーとは本来、テーブルをデータシートビューで開いたときの並び替えのためにあるのではなく、レコードを一意にするためにあるのです。（もちろん、主キーの順に並び替える場合には並び替えインデックスとして利用されますが、主たる目的は違うはずでしょということが言いたい）

ではどうしたらいいのか？並び順が大きな意味を持つ表形式フォームは必ず並び順を指定したクエリーをレコードソースにしましょう。
（レポートの場合は独自で並び替えプロパティを持っており、レコードソースでの並び順は意味がありません。並び替えプロパティを指定しないとまた並び順は保証されなくなってしまいます。）
並び順を保持したまま CSV ファイルを作りたい場合は、クエリーからエクスポートしましょう。
コードのキーブレイク等の処理を行う（思ったとおり並んでないと処理に影響がある）レコードセットを作る場合は、Order By 句を指定しましょう。

また、たとえ Order By をきちんと指定しても、指定したソートキーでユニークにならない場合は、同じキー値を持つレコード同士の並び順も保証されません。
最悪、並び替えを実行するたびに結果が違うということもありえます。確実に並び順を保証したい場合は、たとえ意味がなくても、主キー項目はソートキーに加えるようにしましょう。

では、主キーがない場合は・・・？
主キーがないテーブルを作ることは可能です。重複なしのインデックスが存在しないテーブルを作ることができてしまいます。ということは、まるっきり同一内容のレコードが複数できるかもしれないってことですね。
いままでの説明をお読みになった方なら、この状態がどんなに危険かおわかりですよね。
だいいち、レコードの特定ができませんから(^^;)あとで読み出すこともできないと思うんですが・・・
あとから取り出せないレコードなんて保存しといたってしょうがないですよね。
余談でした。

常に「並び順」を意識する、これがリレーショナル型データベースの常識です。