I've attached you a tar.gz archive containing three host definitions (files renamed for convenience):

- the original host definition: real life example from our system, with three templates, and I've alse defined max_check_attempts at 12;

- the file that I've imported: I've basically copied the existing host definition, deleted one template of the three, and removed max_check_attempts completely.

"Overwrite database" was checked, and I have imported only this single file into the NagiosQL database. Right after import, the host in the web interface appeared as "out-of-date", but it still had three templates, and max_check_attempts set to 12. Same with the existing host file in /etc/nagiosql/hosts/

I've written out the configuration file, so the host file turned "up-to-date", but there was no (real) change in it, and of course the web interface showed the same settings (three templates, max-check attempts set to 12).

- the third file is the host file from /etc/nagiosql/hosts after import and write config.

System info (what I though might be relevant, if you need more, I'll provide):
- Gentoo Linux, mostly up-to-date stable packages;
- mysql 5.0.90
- php 5.2.13
- HTML_Template_IT 1.2.1
- NagiosQL 3.0.3, installed from the stable version found on this site
- nagios 3.2.0 (although this probably has nothing to do with it), Nagios version in NagiosQL is set to 3.0+
This attachment is hidden for guests. Please login or register to see it.

Here's what I've found so far, all in functions/import_class.php

- around line 423: tbl_lnkHostToHosttemplate's type is 3, not 4, so basically hosttemplates linked to a host are not deleted when importing with overwrite. At least that's what is happening in my case. When importing a host, the $arrRelations array contains a single relation with type 4, namely tbl_lnkHostToVariabledefinition.

- this only after a quick survey of the code, so I'm not sure, but you seem to only do an UPDATE of the host entry, SET-ting variables that are actually in the imported file. So if I leave out a variable alltogether, it's value will not change, but it will stay as it were. (lines 418, then @ line 664 you're parsing only the imported array, checking it against the known object variables. you seem to submit the update query on line 733, without ever adding the undefined variable's default values to the UPDATE)

While I agree that UPDATE is good to keep relations you would want to keep (like group membership for hosts), you should make sure, that all un-included variables are set to their respective defaults, since you're not deleting the original definition (maybe always, or maybe as a choice option in the front-end, that's up to you)

- variables included in the imported file, but with values explicitly set to "null" (I'm not sure if comparison of an empty string with "null" string would work, but I don't think so) are almost working, however, the SQL should be instead of as the latter would insert a string instead on NULL value. This is on line 674

The importer will be reworked in 3.1 - it is one of our next steps. I will then check that.

Great. I'm looking forward to 3.1

Here's a tip, might help, I've just learned it you can use in an SQL string (as it is, without any quotes for the value) to set a field to it's default value as specified in the table structure.

It will spare you from checking the type of each field, and what should have been it's default value (eg. NULL, or 2 or 0 or -1 or whatever)