Bugs
Export SQL
Surely not many of us tend to export data from the graphs, but when it happens and you update data on the SQL lite export, it is a lottery to guess when the updated database will be recognised by BOS or when it will simply be ignored.
The below table is backed-up, a record in the table updated, database record written and ACK, database closed, then restored and......chan, BOS says it has imported the data (i.e. no error) but BOS has no data on the table. Unfortunately this is not the first time this happens, it is random, apparently, but surely there is a pattern driven more than likely by "puntuaction" marks in the source code which are not properly interpreted -this has been quite usual-
In this case, and due to the lack of any manuals, it looks like BOS must be storing a foreign key ID somewhere linked to some databases, which makes the restore process ignore the data. Effectively once the table is uploaded, BOS shows nothing despite there is data, and if you export the "empty" table the file created has actually data, so definitively something hidden in the way BOS handles the data files which hinders the ability to modify records.......
BOS version: 4.8.15, but this has been happening in previous versions already
Customer support service by UserEcho
This is what the LOG shows, successful restore of the DB, but actually nothing on the table within BOS, despite if anyone opens it through any sql app there is actually data. Interesting.......Again, this is random, happens for some tables but not for others, so definitively there is something wrong in the restore utility
Hello,
we've been using this method for quite some time now and never got a complaint that the log was empty after importing refreshed data from SQL.
We tried and backed up a couple of different logs, used the SQL Lite, to check the data, and all data from bOS was visible in SQL.
We tried adding values, changing values, playing with the date, time and value itself, applied everything rewrite the database.
Imported in bOS and at first it may look like nothing happened, but if you press Refresh button, the values are then shown in the log (not sure if you pressed the refresh button or not, as the log values on the image you provided looks empty).
After refresh button is presset, values are visibile and everything looks OK.
Hope this helps, best regards,
Thanks, but I had tried everything, the load just does not work, here's today's follow/up screenshots. The load did not work yesterday, I cleaned all the data, there is new data, I try to load data on the existing database and nothing is loaded. There's definitively something happening.
By the way everything works in a controlled environment, and the problem this type I bet, is that BOS might have an issue handling special characters on names, not the first time I have reported something like this and BOS have had to fix those issues, but I might have found the pattern.....Why you do not try to put names with special characters like commas, dashes..ect on names and see what happens or why you do not try to backup, delete records, and try to load...ect, there are mutliple basic items you need to handle to try a software properly
Current
Restore from file
Execution sucesful no error
Nothing loaded
Same screenshot as previously shown. Btw, there is no refresh issue at all.....that's not even a 101 on databse management, guys, you have a problem handling special characters on names when managing backup and restore, that or is the recording of foreign keys stored somewhere else that is used as integrity check, and does nto spit any error
Definitively, you guys have a bug, the usual one, very basic and standard in IT, novel error to say the least.
BOS cannot process nor handle properly at least the following symbol when introduced in names (e.g. variables, graphs names..ect) "/", same as windows does not allow file names to have a slash, you allow it but you do not parse, ignore the exception and swallow it. Better to apply same logic as Windows, just do not allow to use it across the patch because it is pretty much impossible for you guys to test where it works and where it does not.
Even far worse thaan expected, if a KNX variable comes with special characters, a slash, "/", BOS swallows it, no issues, but when you export and restore a DB associated to that variable that results from hanging from tables, BOS cannot handle it and worse it does not spit any error.....
The commas were / before, and backup and restore did not work at all, / removed, replaced by commas and voila, the restore and backup utility works.
Guys in BOS, you better do better testing, and better SW programming, this special character management is so so so so basic. So, with the so many bugs I have discovered, I should be paid
Hello,
thank you for reporting this issue, we'll correct the problem and expect a fix with the next bOS update.
Best regards.
Hopefully soon because KNX variables imported with the forward or background slash will prevent the backup and restore database utility to work at all, so it is actually important one. In fact the table structure gets corrupted, because the data backedup cannot be used lo be loaded even if the name of the BOS variables..ect are resolved. so very very weird
Do you have any schedules when automatic exporting or sending of databases will be available? Exporting to CSV takes random values. Sometimes only one day, sometimes more. DB export works ok, but would be very important to be able to send Data DB or CSV automatically.