nesess様に教えていただいたチケット（#1438）を確認しました。
今回の現象ではdtb_shippingにはそもそも問題の受注の登録が行われていないようです。
dtb_shippingでソースをGrepし確認しましたが、この辺りに特にソース変更されているような箇所はありませんでした。
ただ、教えていただいた障害履歴は今回の件とは全く関係がないとは言い切れないと思いますので、
#1438の変更、LONGTEXT型への変更を行い、しばらく様子を見たいと思います。

ご協力くださった皆様、大変ありがとうございました。

nanasess様

ご返信、ありがとうございます。
発生現象としては同じようですね。

http://svn.ec-cube.net/open_trac/changeset/21197
こちらから修正箇所をGrepで探してみましたが、現状のソースに下記のコードは見つかりませんでした。
$objPurchase->unsetShippingTemp();

再現手順を確認し同様の操作を行ってみましたが、こちらでは再現しませんでした。
また後出しで申し訳ありませんが、問題のサイトは会員限定サイトですので、
全ての会員が銀行振込のみとなり、支払い方法ページは存在しません。
購入手続きからの受注完了までのページ遷移は下記のようになっています。
　お届け先の指定→問い合わせ・要望等の記載→入力内容確認→受注完了

今回教えていただいたチケットは全く関係ないとは言い切れないと思いますので、
チェンジセットに従い、ソースの変更を行いたいと思います。ありがとうございます。

--------------------------------------------------------------------

申し訳ありませんが、これ以降の書き込みは月曜日に返答させていただきます。

引用：

すみません、ちょっと勘違いしておりました(汗)

もしかしたら、以下のチケットが関係していたりしますでしょうか?
http://svn.ec-cube.net/open_trac/ticket/1438
2.11.4 ということで、解消されているとは思うのですが。。

nanasess様

ご返信、ありがとうございます。

申し訳ありません。
先ほどdtb_order_temp内を確認した際に、差分でsessionを確認したのですが下記ような確認方法ではないということでしょうか？

引用：

引用：

dtb_order_temp の session というカラムがあります。
この中に、購入完了時のセッションデータが格納されてますので、ご確認いただけたらと思います。

nanasess様

ご返信、ありがとうございます。

dtb_order_temp、確認致しました。
恥ずかしながらセッション管理については全くの無知ですので、どの辺りを見れば良いか教えていただければ幸いです。

前後に同じような受注がありましたので、sessionのデータの差分をとり、確認しました。
前半部分には共に住所らしきものがありましたが、後半部分の配送先と思われる住所は、
正常にdeliv_feeがセットされている受注にはありましたが、
問題のあった受注にはそのような箇所は見られませんでした。

エンコードについて
申し訳ありません。前任者から移行時にデータベースの移行を行う際は、エンコードの指定が必要と聞いていたのですが、
具体的になにからなにへ行ったのか、資料を探してみたのですが、わからず終いでした・・
先ほどMYSQLにて文字セットを確認したところ、HETEML、さくら、共に「UTF-8 Unicode (utf8) 」となっていることを確認致しました。

--------------------------------------------------------------------

土日は出勤予定ではないので、データの確認することができないため、返答が出来ないかと思います。
ご返信いただいた際は月曜日に回答させていただきます。ご協力いただいているにも関わらず、申し訳ありません。

引用：

どのように変わったのでしょうか??
EUC-JP は最大2バイトですが、 UTF-8 になると最大3バイトになります。

dtb_order_temp テーブルの session の中を見たら何かヒントがあるかもしれません。

karin様

ご返信、ありがとうございます。
HETEMLで動作させていたときのsess_Dataの型を調べましたが、同様にTEXT型となっていました。
HETEMLでも1件発生しているのを発見したので、現状さくらが・・・とは言い難いですが、急に頻発したため、気になるところではあります。

私自身、ECCUBEについては初心者であり勉強中ですので、
どういった情報をご提供させていただければ解決の糸口になるのかわからないのですが、
問題のサイトでは「購入商品の個数が○個以上で送料○円引き」といったことを5段階に分けて行っています。
購入商品の個数が増えるほど、送料の値引率があがる仕組みです。

dtb_orderにはdeliv_fee以外に、もう一つ送料を格納するカラムがあり、
値引き前の送料を格納、deliv_feeには値引き後の送料を格納しています。

問題の発生する受注では、送料値引き前カラムには、
管理画面＞配送方法設定画面で設定した配送料金が正しくセットされているのに、
deliv_fee（値引き後送料）が0になっています。（計算上は0はありえない受注です）

問題が発生した受注の共通点は、受注完了メール内の配送先が空欄だったことです。
送料値引きの対象でない受注、送料全額値引き対象の受注、送料数十円のみ値引きの受注、
配送先が空欄になっているメールから洗い出すと、全く共通点はありませんでした。

私が推測する今回の問題がプログラムバグであれば、バグはこの辺りにあるのかなと思います。

>うーん、なぜなんでしょう。。。気になりますね。私も引き続き調べてみます。
ありがとうございます。何か情報がありましたらご教授願います。

upfront様

引用：

すみません、私の報告した事項は本件とは関係ないかもしれませんね。
(※sess_dataをlongtext型へ変更しておく事にこしたことはないと思います)

うーん、なぜなんでしょう。。。気になりますね。私も引き続き調べてみます。

----------------

karin様

ご返信、ありがとうございます。
私の場合、管理情報には配送先が正しく表示されているのですが、
受注完了メール内に配送先が表示されておらず、調べてみるとdtb_orderのdeliv_feeにデータがセットされていないことで発覚しました。
（送料無料の受注ではないのに送料無料扱いとなり、経理が合わなかった）
また後出しになってしまい、申し訳ありません。

sess_dataの型をlongtextへ変更し、しばらく様子を見たいと思います。
情報、ありがとうございました。