メインコンテンツへスキップ

応答なしになってしまう

コメント

60件のコメント

  • Tanda

    よく見てみますと、nakajimaさんの環境はuniPaaS V1Plusですね。MSJ社のサイトで確認してみますと、uniPaaS V1Plus + SQLServer 2017では「動作確認レポート」が結構出ているみたいですが、こちらは参照されましたか?

  • Y・N

    何処にのってますか。

  • Tanda

    > 何処にのってますか。

    ここです↓

    https://devnet.magicsoftware.co.jp/magicxpa/oldversion/unipaasv1plus/dbmsunipaas1plus/

     

  • Tanda

    nakajimaさん、私も30年前まではMagicのエンドユーザサポートをやってましたので、nakajimaさんの気苦労お察しします。頑張ってくださいよ!

  • Tanda

    > 前のバージョンで問題なければ戻した方が良いのでは?

    ISHIJIMAさん、DBをダウングレードする場合は、データ構造に下位互換性があるかどうかを充分に調査してから行なったほうが安全だと思いますよ。

  • Tanda

    やはり、マルチユーザ時の現象の可能性が高そうですね。

  • Tanda

    nakajimaさん、やはり、誰もテーブルを使用していない状態で、Management Studioでテーブルをオープンしてみるという検証を行ってみる価値はあると思いますよ。

  • Tanda

    その検証で問題なければ、少なくともデータは破損していないという確証にも繋がるかもしれませんよ。

  • Y・N

    夜遅くまでありがとうございます。

    前のバージョンは

    サーバー windows2008r2server

    クライアント   windows7

    sql            SQL2008SERVER

    MAGIC  UNIPAAS V1 PLUS 1.8C

    サーバー入れ替えにより 昨年入れ替えました

    WINDOWS2016SERVER

    WINDOWS10

    SQL2016SERVER

    UNIPAAS V1 PLUS 1.9g

    の環境です。

    動作確認レポートを確認してみました。

    UNIPAAS V1 PLUS 1.9gno の確認は

    WINDOWS2016SERVER ==> SQL2016SERVER

    WINDOWS10                    ==> SQL2014SERVER 迄ですね。

    仮設置環境で問題なく動作したので、最新のSQL2017SERVERを導入してしまいました。

    データがSQL2017SERVERのデータになってしまったので、ダウングレードをするにも

    データが使用できるかわかりません。

    SQL2016SERVER環境を社内に作成して、動作するか確認してみようと思います。

     

    今朝、誰も使用いない環境でManagement Studioでテーブルをオープンしてみましたが

    問題なく表示しました。データは壊れていないような気がしますが、削除しておきました。

    本日より、メニュに接続すると新規ユーザーが登録されるとおもいます。

    その結果を追ってみます。

     

    マルチユーザーの中にデットロック防止がありましたが、これは関係ないですかね。

    現在は初期値の NOになっています

     

     

     

     

  • Tanda

    > ダウングレードをするにもデータが使用できるかわかりません。

    ダウングレードされるようでしたら、バックアップをしっかり取って、事前に入念にテストしてから実行されることをお勧めします。

    たしか、Microsoftのサイトとかにもその際の手順や留意事項とかも、掲載されていたと思います。

  • Tanda

    > 下記URLでアップグレードについて説明があります。

    ISHIJIMAさん、nakajimaさんの場合はアップグレードではなくて、ダウングレードですよ。ダウングレードの場合はアップグレードと違って、留意事項が多いです。

  • Tanda

    nakajimaさん、Microsoftのサイトにはダウングレードに関しての適切な手順を述べたページが無さそうですね。

    ダウングレードの手順と留意事項については、一般プログなどを個別に検索するしかないかもしれません。

  • Tanda

    しかも、2017から元の2008R2への一気のダウングレードは、危険がかなり伴いそうですね。

    どこか、途中のバージョンへのダウングレードで妥協するほかないかもしれません。

  • Tanda

    ちなみに、互換レベル指定を使用される場合は、果たして機能の互換だけなのか、あるいはデータ構造にも互換があるのかを入念にチェックされたほうがいいですね。

  • Y・N

    SQL2017SERVER

    UNIPAAS V1 PLUSで6つのシステムが導入されていますが、問題がおきるのは1システムだけ

    なんです。まあ一番頻度かたかいいて言うのもありますが。

    もしダウングレードする場合はこの問題となっているシステムだけと考えております。

    この顧客より先に、サーバー クライアントを当社からセットアップした会社がありまして、同環境に

    (WINDOWS2016 WINDOWS10)環境に30クライアントと同じくらいのお客様に導入していますが

    こちらはなんの問題もなかったので、今回同一環境と言うことで確認レポートにのっていない

    SQL2017SERVERを導入してしまいました。

    雄一違うとすれば、前火薬のプログラムは全てUNIPAAS V1 PLUSで作成したもので

    問題のお客様は MAGIC V8よりアップグレードしたものです。

    ISIYAMAの質問にありましたが、問題となるプログラムはSQL構文の書かれているプログラムが

    問題を起こしているように思われます。

     

     

  • Y・N

    週末にuserプログラム使用一覧のファイルがAPGで開かなくなり、夜間になると開くと言う現象が

    ありました。

    データが買われたのではないかとも考え、週末に削除しました。

    本日、システムを立ち上げの際にuserファイルがこうしんされますので、先程確認しました。

    やはり、固まり照会画面が表示されませんでした。

    使用中の53番のuserのシステムを終了しましたらプログラムは表示されるようになりました。

    再度メニューにはいってもらうと、照会画面は表示しなくなりました。

    確認の為、もう一度終了して、メニューを開いてもらうと、其のあとからは問題なく表示しています。

     

    書き込み中のデータを照会すると(新規登録時が怪しい)問題がおこっている気がします。

    この辺対応はなにかないのでしょうか。

     

     

  • Pu

    こんにちはPuです

    当方unipaas1.9gとSQLserver2017を多く使用しておりますが

    そのような問題は発生しておりません

    バージョンの問題ではないと思いますよ

    でわ~でわ~

  • Tanda

    SQL文の直接記述は直感的ではありますが、あとあと保守に支障をきたす要因ともなりかねませんので、その使用には慎重を要しますね。

    いずれにしても、解決の糸口が掴めてきてよかったですね。

  • Y・N

    プログラム使用一覧表示のデータですが、1度削除して再度データが作成されましたが

    Management Studioのテーブルで1000件表示をさせてもデータはひらきません。

    夜間になると開くので壊れてはいない気がしますが。

    Management Studioのテーブルは処理中のデータは表示できないものでしょうか?

    新規データ作成方法は

     

    1.システム起動

    2.ログイン画面 ID入力

    3.メインメニュー プログラム番号1の場所所で

     ログインしたユーザーがファイルになかったら新規作成 キーは USER (0)

                                                                  あったら メインフラグ1 時間更新

    4.確認するプログラムの タスク前処理で フラグ 時間更新

    5          タスク後処理で フラグ 時間クリアー   両方とソトのタスクで作成してあります。

     

    この状態でManagement Studioのテーブルが表示できなくなります。

    誰かプログラム実行中の場合に起きているようで、開いているものを閉じるとプログラムも

    正常状態になるような感じです。

     

     

  • Tanda

    プログラムは現在と過去とで全く同じものが動いていて、WindowsのバージョンとSQLServerのバージョンを上げたら、とたんに動きがおかしくなったということですよね?

  • Pu

    こんにちはPuです

    まさかとは思いますがトランザクションとレコードロックではないかと

    でわ~でわ~

  • Tanda

    私もそんなような気がします。例えば、以前はMagicロックで動いていたものが、今はDBロックで動いているとか。

  • Y・N

    はい。

    カナ検索等はそのとうり、2008の時は問題ありませんでした。

    プログラム使用一覧表示は一週間前に作成したものです。

    SQLのエラーログを見ていましたら、SQLSERVER接続のエラーがでていました。

    ポートの解放 1434 のエラーがでていました。

    listening locally on port 1434.
    2020-10-02 16:26:xx.xx Logon エラー: 17187、重大度: 16、状態: 1。
    2020-10-02 16:26.xx.xx Logon SQL Server is not ready to accept new client connections. Wait a few minutes before trying again. If you have access to the error log, look for the informational message that indicates that SQL Server is ready before trying to connect again. [クライアント: 192.168.xx.xx]
    2020-10-02 16:26:xx.xx Logon エラー: 17187、重大度: 16、状態: 1。
    2020-10-02 16:26:xx.xx Logon SQL Server is not ready to accept new client connections. Wait a few minutes before trying again. If you have access to the error log, look for the informational message that indicates that SQL Server is ready before trying to connect again. [クライアント: 192.168.xx.xx]
    2020-10-02 16:26:xx.xx Logon エラー: 17187、重大度: 16、状態: 1。
    2020-10-02 16:26:xx.xx Logon SQL Server is not ready to accept new client connections. Wait a few minutes before trying again. If you have access to the error log, look for the informational message that indicates that SQL Server is ready before trying to connect again. [クライアント: 192.168.xx.xx]
    2020-10-02 16:26:xx.xx Logon エラー: 17187、重大度: 16、状態: 1。
    2020-10-02 16:26:xx.xx Logon SQL Server is not ready to accept new client connections. Wait a few minutes before trying again. If you have access to the error log, look for the informational message that indicates that SQL Server is ready before trying to connect again. [クライアント: 192.168.xx.xx]

     

    何でしょうか。

  • Y・N

    magicのerrlogには、locがかかると載ってますし、locがかかると

    画面左下にキーが重複していますとエラー表示もされます。

  • Tanda

    やはり、最初に予測したように、キーの重複エラーですね。

  • Y・N

     

    今回のエラーは応答なしになってしまい、エラーらしきものはどこにもでません。

    エラーが出るときには上記のようにでますということですね。すみません

     

  • Tanda

    キーの重複エラーはですね、結構、裏だけで起こっていて、表にはエラーメッセージとして明確に出てこない場合もあって、結構厄介なこともありますね。一瞬だけ出て、すぐに消えるいるようなケースもあるようです。

  • Y・N

    エラーが出ている時間は、システムが応答なしにしまい、全てのクライアントから得意先検索

    ができなくなってしまったので、サービスからsqlserverを停止して、起動させた時のものです。

    起動時に1434がエラーをおこしているのではと思ってしまいました

     

  • Y・N

    最終投稿から時間が経ってしまいましたが、プログラム改善等でいくつかのプログラムは

    少しだけ改善されましたが、やはり先頭からデータの最後迄検索する、カナのグローバル検索時に

    固まります。

    magic ini の中で下記を見つけました

    MAGIC_DBMSから削除しても大丈夫でしょうか。

    また、今回の現象の関連性はあるのでしょうか。

  • Tanda

    データベーステーブルの「DBMS」欄で使用していなければ基本的には不要ですが、デフォルトのDBMSテーブルに入っていないものが何故含まれているのかを、「MSSQL2008Express」という行を追加した人に確認されるのがいいと思いますね。

サインインしてコメントを残してください。