MAJOR problem (v3.7.14 Mac)
Made some changes yesterday for first time in a few months. Made some minor structural modifications and went through a fair bit of data, updating to suit the changes (a new field or 2). All was proceeding according to plan.
This morning (not shut down in between) I wanted to remove an old field and since Ninox provides NO means to search for occurrences of a field, I duplicated the database first (structure AND data), before deleting the field, just in case. In fact I had only missed one instance and was easily able to fix that.
A while later I noticed some old data that I KNOW I changed this morning. On further checking, ALL data changed since I started yesterday has reverted back. So NOTHING I have done to the data has been saved. The modifications to the structure are intact, but changes to data have been discarded. E.g. a new (lookup) table I added is there, but NO records, zero, zilch. The entire table has been 'reset' and all records entered this morning are gone.
I checked the copy I had made and that is also missing all the data changes since yesterday, so presumably all that new data was discarded before making the copy.
Ninox updated itself a few days ago, but I only started making changes since then.
I'm not partial to wasting hours (or more) to have it all thrown away. Either this is a HUGE problem, with Ninox failing to save data (its PRIME function of course) or somehow I have missed something that tells Ninox to not save changes to data, which would be news to me if it existed.
What can I possibly have done to cause this, or has Ninox completely let me down and trashed my data?
35 replies
-
Before typing the above, I entered new records into the table that had been 'emptied', so it was as it should be (and had been). In the time it took me to type the above, the same table has again been emptied.
WTF Ninox?
-
In fact, I am unable to save ANYTHING.
Great.
-
Every time I close the database, like going to 'My databases' at the top of the left panel, it throws away any data changes since it was last opened - although as I said, structural alterations ARE saved.
No reason I can see why it is not saving data. If it cannot write to the file, surely it should display an error to state that. As it is, it's just silently throwing away all data changes.
Only change I can think of since it was working (months ago) is that I am running from a different drive. For reasons not worth getting into here, I copied everything to a new drive and am now using that as boot and main drive. All working as it should, except 'Watch unlock' that did work, but now refuses. No idea why, but I doubt has any connection to Ninox's current aberrant behaviour.
-
I updated my MacOS app to 3.7.14 last night and I can't duplicate your issue. I've added new records and modified records and even when I quit the app and then go back in all the changes are there. I did this on a local stored DB and one stored in iCloud.
For the new records not showing up, I would say check to make sure you have not filtered your view in a way that would not show the new records. I've done this before and freaked out that things are broken.
For modified data, I don't know what to say.
-
Looking in the folder where it is all stored and schema.json is updated whenever I make a structural change. But data.db (which I assume is the actual data file) has not been updated since Dec 12th, which is probably the last time I changed something and that was saved.
Ownership and permissions are exactly the same for these 2 files. So back to the same question, why is Ninox unable to save any actual data?
-
To be clear, it's not just that new table (which happens to conveniently illustrate the problem). Any change to other tables' data is similarly never saved. The data that already exists remains, but no changes or additions are saved. To any table that I have tried.
-
UKenGB As Fred said, I can't reproduce the problem either.
MacOS app v 3.7.14
-
Tried a different database (totally different, nothing to do with the first one) and just opening it caused its data.db file mod time to be updated, whereas NOTHING I can do to the other one updates the data file.
So something up with this database. A bit worrying that Ninox might do this, unprovoked. Now I need to figure if it's fixable.
-
Having previously created an archive, I imported that back in and that seems to be able to save its data.
I also tried the duplicate I made which although also doesn't have the missing data (thrown away when quitting the original db), it IS able to save data. I will use that.
So the main db that I was using is utterly stuffed and silently threw away almost 2 days work entering new data.
So I finally have a working db again, but I now have to re-create all that data and to say I am not happy would be a HUGE understatement.
-
I would email support.
-
Fred Yup, have done. Not expecting rapid response though as it was New Year's Day.
What I have noticed is that the data.db file, although updated when you first open the database (and when you close it), it is not necessarily updated when data is then added/edited. However, a file (or files) in the 'sync' folder are updated. So looks like Ninox saves changes to some file (or files) in the sync folder and then at some later time (at least when closing the db) it copies those changes to the main data.db file.
Presumably, at the exact time of changing the data, it exists only in memory, then it's written to 'sync' and then later to the data.db file which I am still sure has to be the actual database file. Anyway, that's how it seems to save the data. Except…
It is possible for it to somehow think it cannot update the data.db file, yet when closing the db it clears those edits from 'sync' and so those data changes are silently lost.
I am currently trying to recreate my thought processes of yesterday and enter it all in again this morning and regularly checking that it IS actually saving it.
-
UKenGB Interestingly, it appears I was slightly wrong as in fact Ninox does NOT write to its data.db file on closing the db. As far as I can see it only writes to that file on opening the db. All data otherwise just seems to be held in the 'sync' folder.
So the problem I was experiencing seems to be that the data, although being saving in 'sync', on reopening, it was unable to update data.db from what was in 'sync' and so all I then had was what was in data.db and all recent edits and additions (that were in 'sync') had been lost. Well, they may still be in 'sync', but that's obviously not what is read on opening the db, so it's effectively lost.
Still no reason I can think of as to why Ninox was unable to update data.db. File looks ok with correct ownership and perms and can clearly be read perfectly. So what caused Ninox to NOT be able to write to it?
-
-
Good morning and Happy New Year. I kind of have the same problem. I have a specific date field, which I tried to empty for one record, and after a went back to db screen and then again into the table, the date field wasn't empty but instead said "01/01/1970"!!!!!!!!!!!!!!!!! This is very troubling!!!!
-
For what it is worth
I am am on latest version (cloud) and in fact on the cloud one does not get a choice as soon as updated version is released you are auto updated (like it or not)
However over last few days I have been very busy doing 2023 mods - adding/deleting fields re thinking client cards and adding branch sub records and moving 1000's of records data. adding @seans dark mode etc
I honestly have not had a single issue with this version. so from a web point of view I would say it is a stable as I could expect.
-
UKenGB When you first updated to v3.7.14 and opened your main DB did you noticed that you didn't have the wrench in the upper right corner and have to "reorganize" the DB so you had admin rights to it? I finally opened my main DB, I track a sport so it is in the off season so I haven't had the need to enter in data yet, and noticed that I didn't have the ability to go into admin mode. When I reorganized the DB I had admin access again.
-
IT'S HAPPENED AGAIN!!!!
Yes, caps intended because this is really ******* me off.
Data I added late yesterday is gone and checking the files I can see that Ninox did not update the data.db file since 17h00 yesterday, after which the new data was added. The 'sync' folder has been updated, but that's not being sync'd to the actual data file and so when the db is re-opened, that last added data is gone.
So it was not a one-off.
-
This time it's even worse as even a reloaded archive will NOT save data.
Really, what is the point of a database that chooses to NOT SAVE DATA.
-
UKenGB Sorry to hear this - But I think given all the issues you have been experiencing, I would urge you to escalate this with Ninox support themselves (support @ninox.com) , as we are only users that try to help likewise fellow users with application issues etc. Your issue is clearly something isolated/more technical and needs their direct input and investigation.
If it helps and you want to upload copy db here - I would be more than willing to input data etc my end and see what result I get. But fundamentality I think this forum can't provide you with the kind of assistance you now need.
Silly question but does rolling back to even older archives work?
-
Mel Charles Oh trust me, I am escalating this to Ninox support. I followed their suggestion to set up a Zoom meeting, but that was a complete mess in that no link to join was ever provided and then the meeting was summarily cancelled. So I'm chasing them further as they need to get on top of this.
I am confident that all the other issues I have experienced are not unique to me as I have read on here of others with same issues. Even this problem of not saving data has been reported by at least one other. It is NOT a user problem. This is something fundamental to Ninox. For reasons of which I have no idea, Ninox can silently fail to update its data file(s) and everything is apparently lost when you re-open the db. I suspect it is still there buried in the 'sync' folder, but when the db is opened, the data.db file is not updated and so you only get all the previous data. What Ninox need to determine is under what circumstances Ninox will fail in this way. Once that is known, they can work on a fix, but in the meantime, suggestions that Time Machine might help is guaranteed to enrage me even further.
-
Mel Charles Yes, the previous archive does work and saves data. However, in the day between those archives, I spent many hours tweaking and adjusting many aspects of the db, with the addition and renaming of many fields. All those changes are of course lost. So that's not a route I wish to rely on. In fact if I had to do that all over again, I might just shoot myself instead.
For the last couple of years I have had the utmost faith in Ninox's robust reliability. Whatever its shortcomings, it did always save everything so nothing was ever lost. I may have spent a long time figuring out how to achieve certain functionality, but everything was always saved. Now, when a database cannot be relied on to save the data… What's the point of using it?
-
UKenGB I do empathise with you. Just unsure as to how to help you further. The issue seems to be erratic. ie Ninox saves you data until it doesn't. A selected archive once restored seems to work (albeit for a while).
Conversely at my end we process over 70+ multiline orders a day, have lots of interaction from multi users and files are bounced/copied from table to table. Loads of deleted jobs/quotes/delivery notes if job date over 7 years from todays date etc and I am altering structure almost every day. Plus batch updating records from our mailing files into table with over 800k records.... and all is fine including sync files to tablets/phones
I am at a loss (nope - I mean stumped) to how to assist your further
my - re question are you able to upload a copy of the db? GDPR etc allowing? I know it's something you are probably extremely aware but I have a table view of all my tables with all main fields in. and every week do a data dump to csv as an extreme back up. That way if Ninox fails, I can construct a Excel flat sheet or Access data table very quickly for emergencies
I do sincerely hope you get a fix soon - it must be very worrying !
-
Mel Charles Yes I realise this is something Ninox need to fix, rather than anyone here being able to help, but sometimes one just has to 'vent'.
Not only that, but users need to be aware of this potential minefield.I've been able to merge older data with the latest structural changes by copying the data.db file and the 'files' folder (they need to stay together or it loses track of all images so they are basically lost) to the latest version that would not save data. It was then able to save data again and I've manually added the new data it was missing. So I now have the latest structure and the latest data and it saves data.
So back to where I should have been this morning. However still with the massive worry of when it will again stop saving data and the only way to tell is to close the db and re-open it and check if it's still there. It is of course simply not practical (or acceptable) to have to keep doing that.
I'm still waiting for sensible communication from Ninox. They keep emailing incomplete messages so I've no idea what they're on about. So beginning to look like support is on par with their actual developers.
-
Content aside
- 1 yr agoLast active
- 35Replies
- 805Views
-
7
Following