Dbname.gui file for visual info

[Jochen Peters]

> Having a seperate storage file (of course this will also be a Valentina
> database with a different extension) we do not have this disadvantages!
> I see only advantages for this approach:
> 1) We do not touch a users database! We can even open a read-only database
>    and are still able to save preferences!
> 2) We can save this preferences LOCALY for server database! (and of course
>    the preference db can be also a server db, if needed!)
> 3) During development you can safely trash your db without loosing any
>    preferences!
> 4) We currently recommend to use several files for security reasons - so
> it does not matter to have one more! AND: On Mac you can put all files
> Into single PACKAGE (which i would RECOMMEND to implement for 2.x) - on
> Windows you can store all files in single folder.
>
>
> Now we have add:
>
>
> -----------
> 5) .gui file is optional and it have sense only for Valentina Studio.
>     V4RB/V4MD/... Develoepr do not need distribute It with their
> solutions.
>     This file will never be created by V4RB/V4MD/... application.
Yes.
>
>
> 6) .gui file have sense only for Valentina Studio.
>     and it have sense only in conjuction with rest Valentina DB files.
>
>     so it looks to be good idea, that this file must be created by Vstudio
>     in the same folder where db is.
Agree.
>
>
> 7) creation of this file must be on Vstudio.
>     i.e. Valentina kernel do not know about this file,
>     about this extension, ...
Yes, of course!

>
>
> -----------------
> More ideas:
>
> 8) we can have for THE SAME database several different .gui files.
>     this can be used to make solutions tuned for different groups
>     of users.
>
>     i.e. Data is data,
>     and it is other question how we display them.
Good idea, yes!

>
> 9) Jochen, it seems latest FileMaker was proud by their features in this
> area. May be there is sense for you to check it...
I will have a look.

>
>
> ------------
> ** I still do not see how you technically will be able link NOT DELETED
> .gui
> file to new db?
>
> What if new db is of different structure?
> How you will see that?
> What is difference only in one fields from 100? Already bad?
> Here many such small technical problems, Jochen.
Well - i must think about the technical solution, but i am sure that
this is not a big problem.


> ----------
> And the main, so it seems that if we go by this way, then you can do
> everything self? Yes?
Absolutly!

>
> I must not put into engine nothing special for this file?
Exactly!
> And with 2.0 you have access to I_Volume so you can control self creation
> of
> Volume. And you can use even not relational tables, but simply one or few
> embedded files on that volume.
Ahh - ok - i will study I_Volume..

-- 
Best regards,
Jochen Peters
PIIT GmbH

------------------------
http://www.valentina-db.de