I needed to change a field from Choice to Dynamic Choice. So I created the new DC field and set up the correct data. Deleted the original static Choice and renamed the new DC one to the same name as the static one had been as that's what I want to use. But…
Two other tables that contain calculations that used that original field now have a problem as it has been deleted. No problem, I will simply edit the formula to refer to the new ffield (that now has the same name as the original that was used, now deleted). This is successful for one table, but the other complained when I entered the field name to use, the correct one that is the same as was used and now also clearly exists. It was an odd error as I was allowed to Ok and close the formula window, but then couldn't Save the table. So basically stuck.
Only solution, I cancelled thinking I'd quit Ninox and hope it got its field references sorted out. However, before I can do that there is a modal error disalog with a message that makes no sense to me, but presumably it's got its knickers in a twist about thsoe field references it screwed up. Trouble is, it is, as I said a modal dialog and I can do nothing - except Quit Ninox, which thankfully still works. But…
On restart I am unable to access that table. The rest seems to work ok, but any attempt to access that table results in a perpetual spinning circle and that's it. No option but to Quit again.
So Ninox has managed to screw up this table. Annoying though it would be, I could recreate it, if I could delete it in the first place. Which I cannot as it hangs before I can access the 'Delete Table button.
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 can't shed any light onto or add to the above but what I can say is - that I have learned to be very wary of Ninox's latest additions and lets face it the DC's are pretty new. So I have been using Ninox long enough and with bitter experience to know that often their new features can cause issues elsewhere. I have not had locked table but have had random files created that are locked etc or filed dissappear but are still referenced and not showing in the data model.
Thus when I am changing a fundimental but important element ( ie in your case a choice to a dynamic or Number to Text etc yo can expect some references to go south!
I would urge any one doing this to take 2 backups first! -
Sorry that may sound like a lecture - It is not but honestly I have been where you are - beacuse Ninox is releativly easy to alter etc it lulls you into thinking you can do most things (great!) but it lacks the rigid controls that ensures all changes ripple through the tables...
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.
Yes I agree, What would be great is the a bility to produce a system report that lists all tables, all fields belonging to each table. All attributes assoicated with each field. all forumlas etc.
I used Dataease RAD dataease since it's DOS days back in 1987 and ut's various windows incarnations up to last year for some of my databases. That could do this from way back then! Even MS Access is fairly robust. Ninox is good but I fear that some of its underlying structure is not very well implemented nor robust. Trouble is these days, I don't think much proving is done before some software houses push it out onto the public. Yes Ninox, basically markets itself as a no code system (like several others) but if they don't want us to go beyond this - then they should not give us the tools to do so. If they give us the ability to add/delete change field/table attributes and do scripts then the resulting action(s) should be robust. I get it if you change a number field into string etc you need to be aware of the impact on your data. But not internally keeping track of formulas or table structure is in my book a sin!
But what do I know - as said most times I want to do something a little different I back up there and then just in case!
But even that it not gurantee. cos UKenGB said you are not awlays aware you have bugged the system up!
Also - I use mac I only have a multiple cloud subscription and one of the advantages of the cloud version is that you can have many copies of your database directly to hand and thus I use one for testing. I don't know if this can be done with the mac/ipad apps as I don't use either of them.. Even though I manually backup my live copy once a week and before I alter anything major -even after I have tested in the spare copy. I very rarely require the backup. I don't know if this can be done with the mac/ipad apps as I don't use either of them.. Obvious the cloud version auto backups throughout the day. But as my DB"s are used by multiple users my manual backups give me the assurance that no one is in the system tables/records etc - thus reducing aother possible error.
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.
Yeah - been there - Done that one alteration/mod too many and boom data/db etc screwed !!!
Yes I agree Ninox does a very good job for what it is and you are quite correct the underlying structure has to be sound....
You have lost me on not being able to comment your code. I'm managing to comment mine okay or are you referring to commenting out whole blocks of code?
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'.