Ninox names vs user names

Alan Cooke Sorry, you need to get the noncompacted version of your database. I think you’ll have to contact Ninox for that.

Geez, I really need to read everything carefully before I post! Alan I reread your original post so disregard my post about the non compacted version. I mistakenly thought you were trying to recover that part of your database.

My original post stands as a method to get that information. "caption" is your field name and the letter before it is the Ninox name.

Sean Alan Cooke What I do is to download the Ninox database. As result you get the database name with the extention .ninox

When you change that to the extention .zip, you can extract the database with a decompression program.

And I think you could extract the wanted information out the file data.db then....

(not sure though, Sean any idea?)

RoSoft_Steven That's what I would do if I still used the cloud version. Since I work with the Mac app and all my files are local, I can get the data.db file directly without extracting it. If I use "Save archive as" in the Mac app I would need to use the method you described to get to the data.db file.

It looks like Jacques has provided a handy function to use though. 

Sean you can obtain the schema directly with this function:

function getDBConfig( ) do
   #{:text return JSON.stringify(database.schema.toJSON());
}#;
end;

getDBConfig();

Jacques TUR Sorry for the late reply. Long day in the Pacific time zone.

I like it! I removed the toJSON() method and it didn't affect the output any. When I compared the strings using and not using that method, the length was the same. I also modified it to use the space parameter and that makes the output more readable.

function getDBConfig() do
   #{:text return JSON.stringify(database.schema, null, 3);
}#;
end;

getDBConfig();

You can also use tab instead, but that creates a lot of whitespace.

function getDBConfig() do
   #{:text return JSON.stringify(database.schema, null, '\t');
}#;
end;

getDBConfig();

Sean You can also use it directly as a JSON object (any) in Ninox to retrieve information from the database schema.

function getFieldNameById( table : text, fieldId : text ) do
var fr := {};
var s := #{:any return database.schema}#;
for t, tv in s.types do
 if tv.caption = table then
   for f, fv in tv.fields do
     if f = fieldId then
       fr := fv;
      end;
   end;
  end;
end;
fr.caption;
end;

getFieldNameById( "Customer", "A")

Jacques TUR Would you be interested in making a function to copy the initial database file object as a string to the clipboard? Another way of saying it is the file object that has just been read from the server and before it has been processed... the raw file.

Sean I am still on vacation. I will look into it when I return next week.
Just to clarify the need a bit, what would be, in your opinion, the differences between the raw schema and the processed schema ?

Jacques TUR No rush. For me, statistical information about database bloat. I started a thread on this topic here

Sean The schema read from the server is database.originalSchema. This NativeJS function copies it to the clipboard in the form of formatted text.

Be careful when manipulating the schema and orginialSchema variables. A wrong modification can permanently alter the database.

#{
var t = JSON.stringify(database.originalSchema, null, '\t');
navigator.clipboard.writeText(t);
}#;

Jacques TUR Thank you. Unfortunately, that is not quite what I am asking for

Sean said:
Another way of saying it is the file object that has just been read from the server and before it has been processed... the raw file.

Which means more than the schema. It includes everything from schemas to modified records to deleted records to modified Table columns. All of that is stored in the raw file. I have attached an example file.

I can create a directory on my Mac where all of the other Ninox directories/data.db files are stored and rename that file to data.db and then open it with Ninox.

Sean It will require me more investigation than I thought and it's not even sure that it's possible. If we do, what will it make it possible to do?

Jacques TUR Don't worry about it.

Jacques TUR said:
If we do, what will it make it possible to do?

Sean said:
For me, statistical information about database bloat.

With the unprocessed file you could count how many old schema there are in your database file. Any time you make a change to your database structure and save the change a complete copy of your schema is appended to your database file. Even if you just made a spelling correction to one of your field names, a complete copy of the schema is appended to your database file. If someone has a lot of tables and formulas that can add up.

Same goes for deleted records, modified table columns, modified data and I think relationships are handled separately from the schema. This is just a personal interest, but for users of the cloud version it could be useful information for managing their allotted space.

Hi Jacques TUR . Does this use your NativeJS add-in?

How do I get that working in my databases?

Regards, Terry.

Sean 

It would indeed be interesting to be able to extract the history of schema modifications, and why not the deleted records as well.

However, on the cloud, only the latest schema is loaded, and the records are called as needed for displaying data in response to queries. The only time the file could be loaded in its entirety is when downloading a backup. I will check if this function is achievable.

Terry Hopper 

Yes, the function that retrieves the field name from its Ninox ID uses NativeJS with Ninext.

If you want to install it, send me an email at jacques.tur@neuf.fr, and I will send you the installation procedure.

Jacques TUR 

Jacques TUR said:
However, on the cloud, only the latest schema is loaded

...into the database object? I'm sure it's the same for the Mac app as well. But where is the schema being loaded from? The stored text file? So, how does the code know where to look for the latest schema since it could be anywhere in the file? Also, you could have an old record that is somewhere near the top of the file, but if you modify a field much later that modification would be further down in the file.

Jacques TUR said:
The only time the file could be loaded in its entirety is when downloading a backup.

I'm fairly certain that download will be compacted, but I don't have a cloud account anymore so I can't confirm that.

prototype.openDatabase or prototype.loadBootstrap