Hosed table

I've been able to access that table through the 'Data Model' as clicking on a Table there takes you direct to the Edit fields mode and I deleted that problematic field. No more hangs.

However I recreated the (Dynamic Choice) field and entered the required code to build the list (was working prior to changes outlined above). I then tried adding a button for some testing and before I realised it, there were suddenly multiple buttons and about 4 copies of the tabs so above the form were 4 identical tabs, although none of them seemed to work. Ninox had simply lost its marbles.

The topmost field was a link to another table and the label was being overwritten by some other text. I dragged it to hopefully cause a redraw and the field appeared to be duplicated on the form. The actual field list showed nothing untoward. No duplicated tabs or fields. But the form was now displayed as a complete mess.

I Quit Ninox and started agaiin. I was able to access the problematic table and the duplicates were gone. I tried to set up the DC field again with code that as far as I can tell is correct and allows me to Save and exit the Formula window. But the table field list window again won't let me save and I get the odd error message again. Hopefully I can attach a screen shot.

Makes no sense to me at all as I've certainly entered nothong like that. I'm sure it's down to Ninox being confused about its internal field references, as it all worked prior to deleting and recreating a couple of fields.

I've had all the nonsense I can take for today, but can anyone shed any light on Ninox'x bizarre behaviour? Any solution apart from really deleting that table and recreating it from scratch - assuming that will clear out its errant field references in that table?

I guess I had been lulled into a false sense of security as Ninox was seeming very robust. However these problems were not of my doing. Deleting a field is an acceptable practice, it HAS to be possible. But Ninox then losing track of its field references, in a way that made it behave very strangely indeed is poor, very poor. A database holds together lots of pieces of data which only make sense when linked appropriately. If the underlying system loses or mixes up those links, that is a VERY BIG problem. A database simply should NEVER do that.

I don't think the problem was related to the use of any particular field type and the new field contained all that it needed before I deleted the unneeded one. The worst result should have been just having to adjust some formulas to utilise the new field name. Instead, I was for a while very concerned that my entire database was toast and having to start again from the previous day's backup was not something I relished as I had made a lot of complex changes.

This morning I started Ninox and with some new ideas about how to improve that aspect of the system, I created some new formulas as required and no further re-occurance of the problems. I think what I had done allowed Ninox to clear out the old references so nothing left for it to be confused about.

Until just now. I deleted a formula field I thought I no longer needed, only to find there was a reference to it in another forumla. Since I had made a backup immediately prior to this deletion, I figured it would be easier to open that than try to remember the deleted field's formula. My first irritation is that the only way to find out if someting is actually in use is to delete it and then when you find that it is required, it's too late. I cannot help thinking that there needs to be a simple option to show where a field of any sort is being used. So whether it's needed or not can be established BEFORE it gets deleted and then having to revert to using a backup.

Speaking of which, even that was problemmatic, in a serious manner. On opening the backup and looking at a particular table, a Dynamic Choice field has been mixed up in some records. It's not a big table with currently only 10 or so records but I think 4 of them had the DC field mixed up. So whatever they had been set to, they were now clearly and unequivocally set to a different selected option. Being a small dataset I was able to manually adjust them back to the correct choice, but can I be sure it hasn't screwed up other data. That's going to be hard to figure out, before it becomes too late to go back. A quick check reveals the photo is missing from one record. A look back at the previous database shows the expected photo. The new databse created from the other's archive is missing that photo (and the other fields screwed up as mentioned above).

There I was feeling pretty happy with how things were working out with Ninox, but these fundamental screw ups have seriously shaken my confidence.

I use a combination of archives and basic duplication of the database, so I have several on hand I can return to. Trouble is, when 'in the zone' one can race on ahead and make a lot of clever changes and just when really pleased with what you've achieved, it goes wrong and the last backup was before you made all those clever changes and if anyone's like me, it can be very hard recreating the mindset to enable you to easily recreate those changes.

Fortunately I seem to have dodged a bullet there and it's all behaving well again.

Regarding other databases' ability to show where fields are in use, I don't think there are many at a comparable level with Ninox. More sophisticated development environments certainly do, but what comes most obviously to mind is straightforward SQL. When everything is all just text, you can easily find anything, anywhere.

I understand the 'no-coding' premise, but to me that's just a euphemism for 'no power'. However, direct development of a good web front end to a SQL server is a fairly mamoth task. I really like the middle ground that Ninox occupies and overall it does a very good job, but it seems to have grown from a 'no-coding' origin without full implementaton of the structures and rigours that a coding developmnet environment really ought to provide. Simple case in point (and that I have been criticised for complaining about) is the lack of any ability to comment code. Any worthwhile development environment must provide this ability, but Ninox has introduced the ability to code, yet missed some of the vital compliments to that. Yes I can get by without it, but boy is it irritating.

Going back to the problem of choice field options being mixed up in the backup, it occurred in an archive and also when simply duplicating the database. In each case, the 'copy' had the same choices switched. This was a Dynamic Choice field and whichever way I tried to look at the data, there was nothing apparently wrong. But any copy of that database switched some options. So I corrected those choices in the duplicated database and duplicated that one. They did not then get switched. That's the database I am currently using which has been without any further problem, but something weird was going on 'under the hood' as it were, with Ninox not only losing track of links, but maintaining links that it did not show visually, on screen. I can even guess at how Ninox works with its own internal references, but whatever, with some of those it was definitely doing it wrong.

So Ninox developers definitely should look into this. As I said, data integrity is of paramount importance, indeed it is singularly the MOST important aspect of a database. Without that, it's useless.

Note. Before anyone sounds off at me, I am NOT saying Ninox is useless. It is doing a great job for me and I've recommended it to others. But there is some tidying up required, including in a very important area.

In its simplest form, like in a bash script, a # at the beginning of a line marks it as a comment and to be ignored. Other languages use e.g. // and something like /*…*/ to mark blocks of code as comment. This makes it easy to create guidance, instructions, reminders etc (always helps later when reading back code, even if written by yourself, but essential when someone else wrote it) and also to comment out chucks of code to try something different. There is no such facility in Ninox. 

Yes you can fudge it by using surrounding it in "", but that is not actually a comment. It is an instruction and is processed (although probably has no effect), whereas a true comment is NOT processed. It is specifically ignored when executing the code. Besides which, when the code contains actual ", then trying to get around that becomes more of a chore.

As I said, I think this is a result of how Ninox has grown and developed and I would hope they do 'flesh out' the development environment in time to include such traditional coding facilities, but what can be done now in no way constitutes true 'commenting'.