SQL Server login

FrancescFrancesc
edited January 2007 in Monitoring Software v12 and lower
Hello,



We have our Serverscheck linked to log into a SQL Server the values returned by the application (to get monthly statistics).



All the rules are logged correctly except the rules of memory, that aren't inserted into the database.



If we look into the serverscheck_checks database we see that all the rules have a record but in the Serverscheck_data, these memory rules don't have any record.



What could be the problem with this?



Greetings,

Francesc

Comments

  • AdministratorAdministrator
    Probably it is related to a SQL error or similar.



    Can your DBA check for SQL errors from ServersCheck?
  • FrancescFrancesc


    But this should be an internal Serverscheck error, doesnt' it?



    Because the rest of the rules are correctly inserted.







    Quote: Originally posted by Administrator on 08 January 2007

    Probably it is related to a SQL error or similar.



    Can your DBA check for SQL errors from ServersCheck?

  • AdministratorAdministrator
    Run it in debug mode and you might see some errors. However best is to check on a database level.
  • FrancescFrancesc
    Hi again,



    I'm executing the SC in debug mode. Where can I send the log file to be analyzed?



    Greetings,

    Francesc



    Quote: Originally posted by Administrator on 09 January 2007

    Run it in debug mode and you might see some errors. However best is to check on a database level.




  • AdministratorAdministrator
    Check for SQL errors. If there are non in there then verify with your DBA.
  • FrancescFrancesc
    I've droped all the tables and I've executed again the SQL sentences to creating the tables and index and now in the serverscheck_checks table I see 119 of 578 rules that shows all the values NULL except the UID.



    I think that the problem is from Serverscheck and not from our database. We don't see any SQL Server error and the debuglog doesn't show any SQL error.







    Quote: Originally posted by Francesc on 09 January 2007



    But this should be an internal Serverscheck error, doesnt' it?



    Because the rest of the rules are correctly inserted.







    Quote: Originally posted by Administrator on 08 January 2007

    Probably it is related to a SQL error or similar.



    Can your DBA check for SQL errors from ServersCheck?







  • FrancescFrancesc
    And other question,



    In the sentences that creates the tables, I think that the UID field in the Serverscheck_data table is a UNIQUE Key, so when SC is going to execute a second insert of a rule that exists in the table, it fails.



    Could you confirm me that the creation is correct?

    We have the same problem and the SQL Server doesn't show light to our problem.



    Thanks,



    Francesc
  • AdministratorAdministrator
    UID is indeed a unique key and should be unique (each rule needs to have a unique identifier - by default this is the UNIX EPOCH TIME when the rule was created)
  • FrancescFrancesc
    Yes, UID must be an unique key in the serverscheck_checks table because there isn't the possibility that 2 or more rules have the same UID.



    But the table serverscheck_checks can't have the UID as unique key because we want to have a register for every time a rule is executed.



    I'm right when I think that the serverscheck_data contains one register for every time that a rule is executed? If a rule is executed 2 times, should I have 2 registers?



    Other question:

    I create a rule of memory. The serverscheck_checks shows a register with the UID, GROUPS, DEVICES, TYPE...



    The rule is executed correctly but the table serverscheck_data don't show any rule with the UID.



    Could you test in your laboratory that the memory rules are correctly inseted in the database serverscheck_data? I think that could be a bug with this.



    Greetings,

    Francesc



    Quote: Originally posted by Administrator on 09 January 2007

    UID is indeed a unique key and should be unique (each rule needs to have a unique identifier - by default this is the UNIX EPOCH TIME when the rule was created)

  • AdministratorAdministrator
    Issue has been resolved in 6.9.4



    6.9.4 is available via manual upgrade. Automatic upgrade will be available as of Monday.
  • FrancescFrancesc
    How can I execute the manual upgrade? And from where can I download the new files?



    I've upgraded but the version is the 6.9.3.



    Francesc

    Quote: Originally posted by Administrator on 11 January 2007

    Issue has been resolved in 6.9.4



    6.9.4 is available via manual upgrade. Automatic upgrade will be available as of Monday.

  • AdministratorAdministrator
    Manual upgrade as per knowledge base:

    http://kb.serverscheck.com/index.php?page=index_v2&id=12&c=5
  • FrancescFrancesc
    But the version shown is the 6.9.3 instead of the 6.9.4.



    Is the last version updated in your website?

    Quote: Originally posted by Administrator on 15 January 2007

    Manual upgrade as per knowledge base:

    http://kb.serverscheck.com/index.php?page=index_v2&id=12&c=5

  • AdministratorAdministrator
    6.9.4 has not yet been officially released. Download the file and run the setup and you will see that it is 6.9.4
  • FrancescFrancesc
    Hello again,



    I've installed the last version but the rules based on memory checks continues without inserting in the SQL Server database.



    Francesc



    Quote: Originally posted by Administrator on 15 January 2007

    6.9.4 has not yet been officially released. Download the file and run the setup and you will see that it is 6.9.4

  • AdministratorAdministrator
    http://files.serverscheck.net/fixes/monitoring_rule.zip



    Replace the existing monitoring_rule.exe with the above one and let me know if it solves your problem
  • FrancescFrancesc
    Hi,



    I've replaced the file and it continues without working... :-(





    Quote: Originally posted by Administrator on 16 January 2007

    http://files.serverscheck.net/fixes/monitoring_rule.zip



    Replace the existing monitoring_rule.exe with the above one and let me know if it solves your problem

  • AdministratorAdministrator
    You are sure that not SQL statements are sent to the database?



    I have checked it here on a test system and it works fine.



    Can you please check yourself or a DBA what SQL statement for the memory check is sent to the database?
  • FrancescFrancesc
    How can I test this?



    All the rules writes on the database except the memory type.





    Quote: Originally posted by Administrator on 16 January 2007

    You are sure that not SQL statements are sent to the database?



    I have checked it here on a test system and it works fine.



    Can you please check yourself or a DBA what SQL statement for the memory check is sent to the database?

  • AdministratorAdministrator
    Apparently your DBA does not have SQL trace running or similar. A DBA should be able to track SQL statements send to his database server and analyze them.



    I am going to ask development to make a special debug build for you. It will be for beginning of next week.
  • FrancescFrancesc
    Ok, we'll be waiting for your reply.



    Thank you very much!!

    Francesc

    Quote: Originally posted by Administrator on 16 January 2007

    Apparently your DBA does not have SQL trace running or similar. A DBA should be able to track SQL statements send to his database server and analyze them.



    I am going to ask development to make a special debug build for you. It will be for beginning of next week.

  • AdministratorAdministrator
    Upgrade to the latest release: 6.10.0



    In debug mode all SQL statements are sent to the screen
  • FrancescFrancesc
    Hello,



    I've installed the last version and now the problem of login into the SQL Server has been solved!!



    Thanks,

    Francesc
  • AdministratorAdministrator
    It did create SQL statement for Memory but it had to be of type of float and probably your database was not setup like that. In 6.10.0 we changed it to integer.
This discussion has been closed.