テストサーバーの再セットアップ

テストで使うサーバーはいつも、調子の悪くなったクライアントPCを使っている。今回Access2016 64bit版の試験用に2011年に購入したPCをテストサーバーとして使っていたが、立ち上がらなくなってしまい、HDを交換して再セットアップした。

いつも同じようなセットアップなのだが、トラブルは付き物で、今回もはまってしまったところがあったので、改めてメモしておく。

CentOS7のインストール(CentOS-7-x86_64-Minimal-1611.iso)
最小インストール版をダウンロードしてきて、CD（DVDではなく）に焼いた。
最小インストールなので「開発ツール」はインストールされていない。
パーティションは自分で設定する。自動で作成すると「/home」に400Gも割り当てられて、「/」には50Gしか割り当てられなかった。
「セキュリティー」はOFFにして、ネートワーク設定を忘れないこと。「IPv4の場合はアドレス変換が必要」にチェックを入れること。

（１）emacsのインストール
vi を使うなら不要
#yum -y install emacs

（２）SELinuxを止める
/etc/sysconfig/selinuxを編集
SELINUX=disabled
#SELINUXTYPE=targeted コメントアウトした

（３）ファイアフォールを止める
#sysctl disable firewalld.service
#systemctl disable firewalld

（４）sambaのインストール
#yum -y install samba samba-common
#mkdir /home/pub
#chmod 777 /home/pub
#chown nobody:nobody /home/pub

/etc/samba/smb.confの編集（今回ここではまった）
プリンター関係の設定は全てコメントアウトした
[global]
workgroup = DOMAIN
security = user （shareはサポートされなくなった！！！）
map to guest = Bad User（これがないと、ユーザー認証画面が表示されてしまう）
[public]
path = /home/pub
public = yes
writable = yes
printable = no
guest ok = yes
guest only = yes
create mask = 0777 （今回から新たに追加）
directory mask = 0777　（今回から新たに追加）

編集後
#systemctl enable smb
#systemctl enable nmb

再起動は
#service smb restart

（５）telnetサーバーのインストール
#yum -y install telnet-server
#systemctl enable telnet.socket


（６）その他のインストール
#yum -y install unzip
#yum -y install gcc （「開発ツール」がインストールされていないので）
#yum -y install readline readline-devel　(PostgreSQLのコンパイルに必要）
#yum -y install zlib zlib-devel　　(PostgreSQLのコンパイルに必要）

（７）不要なサービスの停止
とりあえず
#systemctl disable postfix
#systemctl disable crond

（８）usbメモリーのマウント
/etc/fstabに下記を追加
/dev/sdb /mnt auto noauto,user 0 0

（９）PostgreSQLのインストール
ソースをmakeしてインストール
データフォルダは/usr/local/pgsql/data

・アカウントの作成
rootでログイン
#/usr/sbin/adduser postgres
#/usr/bin/passwd postgres

・フォルダーの作成
#mkdir /usr/local/pgsql
#chown postgres:postgres /usr/local/pgsql
#chown posrgres:postgres /usr/local/src （フォルダーは既にあるので、オーナーだけ変更）

・ソースの展開
/mntに圧縮されたソース(.tar.gz)を用意して
$cd /usr/local/src
$tar xfz /mnt/ソースファイル名

・コンパイル
$cd /usr/local/src/p*
$./configure オプション無し
$make all
$make install

・初期化
postgresで/home/postgres/.bashrcに下記を追加
PATH="$PATH":/usr/local/pgsql/bin
export PGDATA=/usr/local/pgsql/data

$source ~/.bashrc

PGDATAが環境変数として設定されているか確認
$printenv


$initdb --no-locale --encoding=UTF8　

(2017/4/6
オプション無しで使ってみるとソートした時に並びが変だった）

/usr/local/pgsql/data/pg_hba.confの編集（編集前に元ファイルを.bkを付けて保存しておく）
下記を追加
host all all 0.0.0.0/0 trust

/usr/local/pgsql/data/postgresql.confの編集（編集前に元ファイルを.bkを付けて保存しておく）
listen_addresses = '*'
以下はいつも設定しいるが、今回はテストサーバーなので既定のままで変更しなかった。
shared_buffers = 160MB
temp_buffers = 40MB
work_mem = 10MB
max_connection = 32

・postgresql.serviceの自動起動
下記を/lib/systemd/systemディレクトリに作成し"postgresql.service"というファイル名で保存

[Unit]
Description=PostgreSQL database server
After=network.target

[Service]
Type=forking
PIDFile=/usr/local/pgsql/data/postmaster.pid
User=postgres
ExecStart=/usr/local/pgsql/bin/pg_ctl -s -D /usr/local/pgsql/data start
ExecStop=/usr/local/pgsql/bin/pg_ctl -s -D /usr/local/pgsql/data stop -m fast

[Install]
WantedBy=multi-user.target

#chown postgres:postgres /lib/systemd/system/postgresql.service
#systemctl enable postgresql.service

として登録。再起動してpostgresql.serviceが起動しているか確認。

#systemctl --type service
#top

・データベースの作成
$createdb DataBaseMei -E UTF-8 -l ja_JP.UTF-8 -T template0
$psql DataBaseMei -e < ダンプデータ

・ユーザーの作成（スーパーユーザーとして）
$createuser -s Namae

・ユーザーの削除
$dropdb Namae

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

2019/8/21
１．sambaが開かなかった、telnetがつながらなかったので、
#systemctl disable firewalld

２．ホスト名の変更
#hostnamectl set-hostname [ホスト名]

あるいは下記を編集
/etc/hostname

３．IPアドレスの変更
デバイスを確認
#nmcli d

IPアドレス、サブネットマスクを変更
/etc/sysconfig/network-scripts/ifcfg-enp6s0 （例えば）を修正

インストール終了後、テスト環境ではクライアントPCとピアツーピアになる。その際、クラアントPCからの接続が遅くなってしまう時
で設定したDNSは見えなくなっているので。コメントアウト(#を付ける）する。
それでも遅い場合は/hostsにクライアントPCを追加する。

accdb 64bit版 結局のところ（まとめ）

レコードロックのエラーが解消できて、一応、32bit版との違いが出尽くしたように思うので一応、まとめ。


移行前の環境（OS、Officeとも32bitは32bit、64bitは64bitに統一）
32bit環境　WindowsXP SP3 ＋　Office2007

移行後の環境
64bit環境　Windows10 ＋　Office2016 (Office365)　

○修正しなければならなかったところ

１．レコードロックのエラー（バグ？）
これが一番、問題だった。
最初はPostgreSQLに直接、連結していて、コードでレコード更新する時にレコードロックしてしまい、これはAccess内に作ったテーブル（１レコードしか含まない）にリンクしてコードで更新する形に変更した。
（この形式だとinsert into TempTable select * from MotoTable where で修正前データを一行で呼び出してこれるので楽）
しかし、これではロックがかかったままだった。
別の空accdbにテーブルをリンクして該当行だけ表示させて、手修正した場合もロックがかかるので、作成したプログラム側の問題ではなかった。
この時はpgAdminでも修正できなかったので、わけが分からなくなった。
別のサーバー、クライアントに同一環境を用意して試してみても、やはりロックがかかるので、何らかバグがありそうだった。
結局、PostgreSQL直接の連結フォームをやめて、パススルークエリで更新ではなく、レコード削除、新規登録することでロックしなくなった。
別のテーブルでも同様の症状が出たが、この時はパススルークエリから更新できた。

2017/4/4
やっぱりこれはハッキリ、バグだ。64bitのWindows10でエラーが出るaccdbファイルを32bit版WindowsXPで実行するとエラーがでない。Access側に原因があるのか、PostgreSQLのodbcドライバー側に原因があるのかはわからない。
リンクテーブルを
rst.Edit
rst.Update
でエラーになってしまう。パススルークエリーでupdateするとOK。

2017/4/6
別のフォームではrst.Editで更新してもエラーにならないこともある。
全くわからない。

2017/4/19
結局、データに特定の文字が含まれている場合は更新できないようだ。
どの文字が含まれている場合かはよくわからない。
rst.Edit
rst.Update
でもだめ、パススルークエリーでもupdateはだめ。
新規登録はできる。
rst.Addnew
rst.Update
はOK。
rst.Deleteはダメ
パススルークエリーからdeleteはOK

まとめると
rst.Delete ×
rst.Edit ×
rst.Addnew OK

パススルークエリー
delete OK
update ×
insert 試してない
(insert into TableMei select * form TempTableMei where cd = ShouhinCD はダメだった）

結局、更新する場合は、パススルークエリーでdeleteして、rst.Addnewする。

2017/4/20
結局これで更新できる。何てことなかった。
Dim lngC As Long
lngC = Me.cd

Me.AllowAdditions = True　　’連結しているテーブルのレコードを進める。
DoCmd.GoToRecord acDataForm, Me.Name, acNewRec
CurrentDb.Execute "delete from t_shouhin where cd = " & lngC　　’ODBC接続しているリンクテーブルを更新
CurrentDb.Execute "insert into t_shouhin select * from temp_shouhin where cd = " & lngC



２．Setfocus（仕様違い？）
フォームでの話。32bit版の時はヘッダーから詳細部へEnterでフォーカスが移動していたが、64bit版だとヘッダーから詳細部へ移動しない。ヘッダー部最後のコントロールからコードで詳細部最初のコントロールへ移動するように修正。

３．F7のショートカットでスペルチェックが起動してしまう（仕様違い？）
Office2007の時はファンクションキーF7にスペルチェックが割り当てられていなかったのか、Office2016だとスペルチェックが起動してしまう。KeyEventを処理する時にkeycode=0を追加してスペルチェックが起動しないようにした。
（Office2007の時はF1でヘルプが起動していた。実際、プログラム作成時には良く使っていたこともあり、これはそのままにして、F1はプログラム側でキー割当しなかった。Office2007ではF7は何もショートカットが設定されていなかったのだと思う。）

４．テーブル表示時にデータソースに標準関数をつかっていると、落ちてしまう（バグ？）
データソースに社名とかで「株式会社」を「(株)」に変換する標準関数を含んでいると、落ちてしまう。
データ数が多い時だけの現象。

５．チェックボックスのNullの画面表示が変わった（仕様違い）
データがNullのチェックボックスはOffice2007だと、Falseの場合とあまり表示が変わらなかったが、Office2016の場合は黒くなってしまい、見た目が非常に悪くなってしまう。ちゃんとFalseをセットしておかなければならない。

６．コントロールの表示が正確になった
テキストコントロールの立体表示がはっきり分かるようになったので、修正することなった。これはバグでもなんでもないのだが、、、

７．OLEオートメーションでの動作不良（バグ？）
AccessからWordを開いて、文書中の表を操作するとうまく動作しない場合があった。
テンプレートとして用意している.doc中の表の行を削除すると列幅が変わってしまった。

８．bioPDFで同期処理ができなくなった
請求書をbioPDFを使ってtif化してＦＡＸ送信していたが、AccessとbioPDFの同期がとれなくなってしまい、複数枚請求書を送信する場合は使えなくなってしまった。実際6枚目くらいからファイル名とデータの整合性がなくなった。Access2016側が速い。
bioPDFを使わないで、Access2016でPDF化することで解消。

９．連結フォームでカレントレコードが先頭行に移動してしまう
フォームでコマンドボタンにファンクションキーを割り当ているが、マウスでクリックする時はフォーカスがコマンドボタンに移動する。ファンクションキーを使った場合は、コードでSetfocusしてやらないと、フォーカスがコマンドボタンに移動しない。これを怠っていて、商品選択画面から伝票入力画面に商品CDをセットする時、カレントレコードが先頭に移動してしまう。伝票入力画面はデータ入力用のテーブルと連結していて、行数に制約を設けていない。
(2017/3/29)

１０．クエリー抽出条件でリストアップされる明細が違う
クエリーで条件「<>1」で表示されてたものが「0 or is NULL」にしないと表示されなくなった。
NULLは「<>1」に含まれなくなった。
(2017/3/29)

１１．「引数が無効です」
リンクテーブルではなく、Access内の「テーブル編集時に、初回のみ "引数が無効です" とエラー メッセージ表示される」。初回だけの場合もあり、毎回表示される場合もある。
Access2007のテーブルをAccess2016の空ファイルにインポートしたせいか。
(2017/4/19)

https://support.microsoft.com/ja-jp/help/2480088


○64bit版にしてよかったところ

１．月末請求書を一度に印刷できるようになった
32bit版では一度に印刷すると、後半、罫線だけ印刷されていたが、64bit版だと一度で印刷できる。
32bit版では3回に分けて、いちいち再起動して印刷していた。

２．「メモリー使い果たした！」エラーが出なくなった
32bit版では続けて受注伝票入力をしていると、「メモリー使い果たした！」エラーが出て、再起動しないと販売管理プログラムが使えなくなったりしていたが、このエラーは出なくなった。
32bit版ではデータ更新時に、一度削除して新規登録する場合もあり、データが消えてしまうこともあって困っていた。

３．AccessでPDF化できるようになった
これはAccess2007でもできていたのかもしれないが、Access2016で初めて使ってみた。bioPDFを使うより簡単だし、速い。

４．動作が速い
PCの性能もあるのだろうが、全般に動作がOffice2007より速いように思う。
商品テーブルは読み順とコード順で一度に２つのフォームを開くようにしていて、タブキーだけでテーブルを移動するようにしている。32bit版の環境ではフォームを移動すると、ソートされていないことがよくあったが、64bit環境ではその回数が激減。1～2秒待てばちゃんとソートされている。


○感想

「○修正しなければならなかったところ」「１」はバグと思うのだが、データベースのフロントエンドで使っている場合、致命的なバグだと思う。32bit版では動作していても64bit版では動作しないので、これが問題になるようだと64bit版への移行は時期尚早ということになる。
ただ、私の場合はデータベースはPostgreSQLなので、PostgreSQL固有の現象かもしれない。例えばSQL Serverなら問題なく動作するのかもしれない。
「OLEオートメションの動作」不良も場合によっては致命的になるかもしれない。
残りの問題は、簡単に対応可能だと思う。

利点については「メモリー使い果たした！」エラーが出なくなったのが大きい。
大量のレポートを発行するのは月に一度だけなので、使い易くはなったが、これだけなら64bit化はあまり意味がない。

まだまだ動作確認中だが、一応、「○修正しなければならなかったところ」「１」は修正方法もわかったので、64bit化は予定通り進めていく予定だ。