Version 2

Rob Wingate rwingate at visual-book.com
Thu Jul 29 14:58:34 CDT 2004


Jochen and Ruslan,

Since I use Valentina every day, and since column widths were mentioned,
here's my opinion:

Any off-the-shelf database program that allows the developer to view tables
in a visual format maintains column-width settings for those tables.

IOW, if I open my "Customers" table, the column widths are formatted how I
left them last time.

When I open my "Transactions" table, it must have its own column settings,
and cannot use some global width setting.

To me, this is obvious and expected behavior. Each table, and certainly each
database, must retain its own settings. If it does not, it's not a useful
program to see one's data visually. I could not justify purchasing that
software.

Also, for the database programs I use (Access, FileMaker, etc), I never need
to trash my prefs. I have only done during VS beta, and after VS is
released, I would expect to never need to do it.

I believe MS Access solves this issue by adding a non-visible table to each
database, in which settings are stored (I could be wrong).

So the .gui file sounds like an interesting idea for VS. But I would expect
the Valentina engine itself to not require them. I would not expect to
deliver .gui files to my client.

Thanks,
Rob

----- Original Message ----- 
From: "Jochen Peters" <j.peters at valentina-db.de>
To: <valentina-studio at lists.macserve.net>
Sent: Thursday, July 29, 2004 2:33 PM
Subject: Fwd: Version 2


> Hi Jochen,
>
>> Ruslan - one important point of vStudio development still left open
>> from
>> one of our previous discussions is:
>> "Storing database preferences and vStudio related stuff"
>>
>> I REALLY RECOMMEND to think again about that!
>>
>> Let me recall:
>>
>> Your approach (and also my first approach) was to store all this stuff
>> INSIDE the Valentina database. (For example using System Tables)
>>
>> Let us discuss the Pro's and Contra's of this approach
>>
>> Pro's
>> ------
>>
>> 1) All stuff is safely inside the database - when the user moves the
>> database then he will still have all it's database preferences - like
>> for example the column width in the Databrowser.
>>
>> Well - i really see only this one advantage :-) Please let me know
>> if you see anymore.
>>
>> Contra's
>> --------
>>
>> 1) This approach does not work for other databases we can use with
>> vStudio
>>  via ODBC.
>
> yes
>
>> 2) Developers often want's to trash their db to start a fresh one -
>> with
>>  this approach all preferences will be lost, too. (Can be very bad
>>  if you have defined several individual columns widths for the
>>  databrowser.)
>
> But how you going relate later preferences of _deleted_ database
> To new one ?
>
> Well, this can be implemented as idea of STYLES in PageMaker/inDesign!
>
>
>> 3) This will also mean that vStudio will ALWAYS change a user's
>> database
>>  writing own stuff into it! I think this is very bad idea!
>
> May be
>
>> Having a seperate storage file (of course this will also be a
>> Valentina
>> database with a different extension) we do not have this
>> disadvantages!
>
> One more file?   .gui ?  :-)
> Interesting idea.
>
> But note, in Valentina use CAN say that all files must be in one
> physical.
>
>> 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!
>
> Yes.
>
> So do you mean that EACH Valentina db must get own such file?
> I think yes.
>
> Or you mean that Valentina Studio should maintain own single file to
> keep
> prefs for all dbs it have open? I think NO.
>
>> 2) We can save this preferences LOCALY for server database! (and of
>> course
>>  the preference db can be also a server db, if needed!)
>
> Yes.
>
>> 3) During development you can safely trash your db without loosing any
>>  preferences!
>
> This is not usual behavior for other Valentina files. But why not.
> So I have
>
>     db.vdb, db.dat, db.ind, db.gui
>
> I trash the first 4. Now I create new db with the same name,
> Valentina see that such file already exists in the folder and do not
> erase
> .gui file. This is what you want ?
>
>> 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.
>
> Single folder can make developer and put db files there
>
>> So - what you think?
>
> I think you should right now forward this letter to Valentina Studio
> list
> and beta list for discussion. :-)
>
>
> -- 
> Best regards,
> Ruslan Zasukhin      [ I feel the need...the need for speed ]
> -------------------------------------------------------------
> e-mail: ruslan at paradigmasoft.com
> web: http://www.paradigmasoft.com
>
> To subscribe to the Valentina mail list go to:
> http://lists.macserve.net/mailman/listinfo/valentina
> -------------------------------------------------------------
>

_______________________________________________
Valentina-studio mailing list
Valentina-studio at lists.macserve.net
http://lists.macserve.net/mailman/listinfo/valentina-studio



More information about the Valentina-studio mailing list