実行時に「インデックス配列の境界外です。」と出てしまう。
お客様でRIAの実行環境を設定し、いざ立ち上げたところタイトルのようなエラーが発生してしまいました。
これが発生すると、Brokerモニタではコンテキストが立ち上がりっぱなしになり
アプリケーションサーバーを停止するとmgerror.log に Aborting context と1行追加されます。
社内では立ち上がったので環境の問題かと思われますが、ご意見を伺いたく投稿させていただきました。
以下、設定を行った環境となります。
OS:windows server 2016(お客様)
OS:windows server 2012R2(社内)
RIA Server バージョン:3.3d(共通)
Studio バージョン:3.3d
-
こちらへ投稿する前に見てはいるのですが、コーディングに関する情報ですので該当しないと思われます。
社内で同様に立ち上がらないのであれば、コーディングミスだとは思うのですが社内環境で立ち上がってしまったので
環境回り?なのかと思いました。
-
データも同じ環境ですね。
社内のDBをお客様環境に復元しているので。
最初に起動するECFも同様のものを使用しております。
-
「インデックス配列の境界外です。」という表示でしょうか?あるいは「インデックスが配列の境界外です。」という表示でしょうか?インターネットで検索すると、どうやらSQLServerが出しているメッセージのような気がしますね。
「DB」を「復元した」とコメントされていますが、そのときの手順はどのようにされたのでしょうか?ふつうはSQLServerの「アタッチ」コマンドを使用しますが。
-
後者の「インデックスが~」の方ですね、タイトルが異なっていて申し訳ないです。
DBの方は、社内(sqlserver 2016)からバックアップを取得しまして
先方(sqlserver 2017)の環境にコピーして、データベースの復元を実施しました。
-
「バックアップ」→「コピー」→「復元」でも間違いではないと思いますが、私は「コピー」→「アタッチ」を勧めています。あと、実行環境においても何らかの形でF8の構文チェックができるといいですね。クライアント環境で事前にアタッチがうまく行っているか確認しておくとか、あるいはサーバ実行環境にも開発版を入れて構文チェックをするとかですね。
ぶっつけ本番でDBをコピーしただけでは、思わぬ不整合が潜んでいる場合があるかと思います。
コメントをよく見ますと、コピー元とコピー先のSQLServerのバージョンが違っていますね。これはまずそうですね。
-
DBバージョンの違いは、他社で同様の作業を行って問題なく使用できていたので問題視しておりませんでした。
しかし、ご指摘内容を充分に調査は行っておりませんので復元ではなく新規作成をして全テーブルをSQL文で作成や
開発版を入れてみて開いてみる等を試してみます。
-
「アタッチ」が一番楽ですよ。メニューから選んでファイルを指定するだけです。
-
たしか、「アタッチ」を使用すれば、バージョン違いも自動的にコンバートしてくれたような記憶があります。確認が必要ですが。。
-
mdfが11GB もあるので、圧縮した後にコピー→解凍してアタッチを実行しましたが同じようなエラーが発生しました。
今度はStudioを入れて実行を試してみます。
-
開発版を入れる場合、デフォルトのままインストールするとIISのエイリアスが上書きされてしまいますので注意してくださいね。エイリアス名はRIAサーバとは別の文字列にしたほうがいいです。
それと、使用するポート番号も注意してみてくださいね。 -
こんにちは Puです
SQLserverはバックアップ==>復元が一般的です。 全く問題ありません。
(バージョン違いも復元で対応されます)
ですのでDBの移行方法に問題があるとは考えにくいですね。
でもSQLserverが出しているエラーなので、起動時SQLserverに対してどの様なアクセス命令を出しているか
GATEWAYのLOGを出力してみるか、またgatewayのdllのタイムスタンプは同じか調べてみるとか...
でわ~でわ~
-
「バックアップ・復元」とはその名が示す通り、万が一の場合に備えてデータベースをバックアップしておき、いざという時にそれを復元するという意味の機能です。
それに対して、「デタッチ・アタッチ」とは、こちらもその名が示す通り、必要に応じてデータベースを切り離したり接続したりするという意味の機能です。
データベースを本番環境にコピーするという作業はいざという場合の非常事態ではありませんので、そうした場合にはアタッチを使用するのが安全で確実です。
下記のリンクの解説がそれを分かりやすく説明していますね。
-
>どのような状況でエラーが発生するのか(起動直後とか複数立げ後とか・・・)
→起動直後ですね。システムを立ち上げようとすると出ますね・・・。
>GATEWAYのLOGを出力してみるか、またgatewayのdllのタイムスタンプは同じか調べてみるとか...
→差し支えなければ方法を教えていただくことは可能でしょうか。初めて発生した現象なのでそういった調査は
行ったことがないもので・・・。
-
単純なAPGを実テーブルの照会・メモリテーブルの照会両方試しましたが同じエラーとなりますね・・・。
-
データベース接続の段階でエラーが出ているようですので、起動するプログラムは関係ないかと思います。
-
先方の環境で開発版から実行すると普通に立ち上がりますね・・・。
DBも照会できているようですし。
-
こんにちはPuです
マイクロソフトのドキュメントサイトには「データベースの移行」
方法に、バックアップ==>復元
デタッチ==>アタッチと両方記載されております。 別にどうのこうのではありませんが。
gatewayのlogはオプション==>設定==>ロギングから設定できます
Magicのドキュメントのログだったか??に記載されております。
一番わかりやすいのはManagementStudioのプロファイラーでMagicが出しているSQLをひらうのも方法ですが
でわ~でわ~
-
>先方の環境とはサーバー上でしょうか?
→そうですね。先方のサーバーにSutdioを入れて、私の端末のプログラムをコピーしてパス等を設定してF7実行をしました。
>普通にアプリケーションは動いていてログにエラーが発生しているという事ですか?
→ブローカーには、実行してエラーが発生した状態でコンテキスト数は1のままになり、エラーログは更新されません。
ブローカーからアプリケーションを落とすと、「アボートされたました」といった1行がエラーログへ更新されます。
-
「バックアップ」→「復元」は、必ずその両方の操作が必要になりますが、「デタッチ」→「アタッチ」の場合は、単純コピーなら「デタッチ」操作は不要です。「アタッチ」だけで処理が完了します。
上で紹介したサイトでも解説されていますが、「バックアップ」→「復元」が誤りだとは決して言っておりません。推奨されないと言っているだけですね。そして、私自身も推奨しません。
-
>クライアント側のRIAアプリは何事もなく起動しているという事でしょうか?
→それは「インデックスが・・・」というエラーで動きません。
開発版からのF7実行は動作します。
バックアップ・アタッチは両方試しましたが、両方進展はありませんでした。
UniPaaS時代よりバックアップ→復元で動作しているのでそこは問題ないかと。
元々のDBサイズが大きいのでどうしてもバックアップを圧縮した方が早いんですよね…。
-
> 開発版からのF7実行は動作します。
IISのエイリアスの重複はチェックしましたか?上書き更新されて、意図しないパスを読み込んでいる場合があります。
-
> 開発版からのF7実行は動作します
ポート番号の重複チェックもしましたか?Brokerが意図しないポートのプロジェクトを起動している場合もあります。
-
>IISのエイリアスの重複はチェックしましたか?上書き更新されて、意図しないパスを読み込んでいる場合があります。
→エイリアスは実行・開発版別々に指定しているので問題ないかと・・・。
>実行時に最初に起動するプログラムをF7実行で起動して実行できているという事でしょうか?
→そうですね。マニフェストを作成する際に指定したプログラムを開発版でF7実行すると社内と同様に動作します。
>ポート番号の重複チェックもしましたか?Brokerが意図しないポートのプロジェクトを起動している場合もあります。
→ポート番号が間違っていればブローカーに起動したいアプリケーションが出てこないのでそこは問題ないと思います。
Studioを入れる前から発生しているエラーなので…。
-
そうですね…。簡単なAPGで作って公開名を変えずにECFを作成しても同じエラーが出てしまいました。
-
下記の画面を表示するように実行するようPGを変更しましたが、
社内では動作OK、先方の環境ではNG(インデックスが…)になりますね・・・。

-
数十件ぐらい実施してきましたが、特問題なく起動できていますね。
今回のような事象は初めてです。
-
そうですね…。
皆さんの貴重な時間をいただいて申し訳ございませんが、サポートセンターに問い合わせてみます。
何事か判明しましたら、コメントします。
-
使用しているデータソースのカラム定義ですが、すべてMagic側で定義を行っていますか?ひょっとして、SQL Server側のManagement Studioやらで手動で直接、定義しているとかいうことはありませんか?SQL Server側で手動で定義を行うと、SQL Serverのバージョンの違いで思わぬ不具合を起こすことがあります。
-
当件ですが、原因が判明しました。
まず、投稿した内容に記載しておらず申し訳ないのですが、社内・お客様共にAzure上でシステムを動作させておりました。
そして、eSupportさんにお客様環境を確認してもらったところ以下の回答をいただきました。
> ブローカのサービスがSYSTEMアカウントで、言語設定が日本語になっていないのが問題でした。
>失敗時(ブローカ起動)の通信データを見てみると、var_name="Ep.機能\" というような要素がある。
>「能」のコードは 945C で、5C をエスケープするために \ が追加されています。
>その為、ダブルバイト文字として 「能」が認識されていませんでした。
>成功時(コマンドライン起動)のログでは、var_name="Ep.機能" となっており、「能」がダブルバイト文字として認識>されます。
ブローカーのアカウントを日本語設定が適用されているアカウントにすると動作しました。
(やり取りさせていただいた中で、「テーブルを一切読み込ませないで画面」のみでも起動できないとありましたが
それは該当リポジトリのコンポーネント内でテーブルを読み込ませていたのが原因でした。)
色々とアドバイスいただきありがとうございました。
-
Microsoftは、日本向けのシステムであっても言語指定が英語になってしまっているサービスがあるんですね。
先日、日本語106キーボードが効かず、英語101キーボードを仮想化して入力したら通ったという、日本市場向けの日本語クラウドサービスに出会ったことがあります。
アメリカ製のシステムを日本市場で稼働させる場合は、まずは言語設定からですね。
サインインしてコメントを残してください。
コメント
35件のコメント