一、问题原因

    该问题可能是数据库服务没有启动或数据库没有初始化。




二、解决办法

1、检查数据库服务启动情况
      如果数据库服务未启动，请先启动。 

      如果数据库启动报错，请查看系统和数据库日志，对应排查服务启动失败原因，直至成功启动。
      如下是一个数据库启动失败的例子。

      查看数据库日志（Linux默认日志路径在/var/i2data/pgsql/data/log/）后，判定为pg_wal误删，引起启动报错checkpoint（检查点）找不到。
      这种情况的解决办法是：
su - postgres
pg_resetwal -f /var/lib/postgresql/data/
如果是7.1.60以上版本:
pg_resetwal -f /var/i2data/pgsql/data/


2、检查数据库是否初始化
      如果数据库服务已经启动，但仍然还出现该报告，则需要进行数据库初始化。
      可手动进行数据库初始化，或采用如下介绍的方式，来完成该工作。





如得到如上弹窗反馈，则说明已初始化数据库成功，可尝试重新登录。


Windows的控制机，如果点击后得到如下反馈“Oh no! A problem with the Ajax request!”，请检查数据库监听是否被修改。
（Linux的排查方法见后文）


Windows查看数据库监听的方法如下：
可查看 C:\Program Files (x86)\info2soft\ctrlcenter\pgsql\data\postgresql.conf 文件中的port配置，或根据下述步骤查看当前监听端口。

（1）进程管理器，找到postgres.exe的PID；


（2）查看主机端口监听情况，根据PID找到postgres数据库的当前监听端口；
    本例中，默认的监听端口（58083）已经被改过，所以当前数据库监听的是38083端口。此时，需要查看database.php文件，检查DB连接部分的端口配置是否也做了对应修改，如没有做修改，需要同步进行修改。


（3）检查和修改database.php
    该文件的默认存储路径是：
C:\Program Files (x86)\info2soft\ctrlcenter\wwwroot\default\application\config\database.php
    如DB监听端口做了修改，则上述文件中所有的58083部分都需要做对应修改。



  将该文件中所有旧的端口改成新的端口，再尝试登录即可。



如果是Linux的控制机，遇到“Oh no! A problem with the Ajax request!”，也是类似的操作，需要检查数据库监听是否被修改，请进行如下操作。

1、查看数据库监听端口
netstat -anp|grep PGSQ
本例中，默认的58086端口被修改过，因此此处看到的是监听了38086、


2、检查database.php
vim /var/i2data/www/default/application/config/database.php
检查该文件中的'port' =>对应的值是否与当前数据库监听端口对应，如不相同，请全部进行修改（三处都需要对应修改）。


  将该文件中所有旧的端口改成新的端口，再尝试登录即可。