Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
What's your opinion on best way to deploy an ElevateDB app |
Wed, Apr 1 2009 8:36 PM | Permanent Link |
Phil Read | Hi All,
This is a general question and I guess there many answers, but how does everyone else prefer to deploy their database in a new install? Do you include the physical empty database files ? Or maybe you have code in the app to create the blank database structure? Or maybe you have another method? I'd be interested to hear different methods. Thanks, Phil. |
Thu, Apr 2 2009 4:08 AM | Permanent Link |
Uli Becker | Phil,
> Or maybe you have another method? > I'd be interested to hear different methods. I ship the catalog-file together with my application. After the user has chosen the directory where he wants to store his data, my application first checks, it there is an existing database. If not, it just copies the catalog-file into the database-dir. When the user starts the application and the tables are opened, EDB automatically creates empty tables from the catalog. Uli |
Thu, Apr 2 2009 6:06 AM | Permanent Link |
"Iztok Lajovic" | Phil,
> This is a general question and I guess there many answers, but how does > everyone else prefer to deploy their database in a new install? > Do you include the physical empty database files ? > Or maybe you have code in the app to create the blank database structure? > Or maybe you have another method? We use following approach: - all our applications are stored in common directory, in our case named 'kres' (name of our company) and directory 'kres' must have all privileges for all users because the applications handle the users' privileges by themselves (otherwise the access problems arise) - there is a common subdirectory 'EDB' where the configuration file is placed - each application has its own subdirectory named <application name> and this subdirectory has two subsequent subdirectories <archives> and <data> - if particular application is used for managing data of different domains (= business data for different companies) then for each of companies in directory <data> the subdirectory <domain name> is created for each domain, otherwise the data are stord in <data> subdirectory - databaseName of each application is '<application name>-<domain name>' or only '<application name>' if there is no need for domains - every application has embedded code for catalog creation in <EDB> directory if there the configuration file is missing and the code for database named '<application name>-<domain name>' creation if it is not yet created and all code for creation of all files that must be in particular database - the code for file creation has all necessary information to upgrade the tables if the table restructure took place in time when the application has already been put in use. - initial code for table creation is made on reverse-engineering code basis supplied by Tim in edbmgr and by use of our program thyat we made for transformation of reverse-engineering code to use in Delphi program. The program can be found in'elevatesoft.public.elevatedb.extensions' group (last entry). All description ir rather long but I put it here in whole to describe our approach to application deployment. Regards Iztok Lajovic KreS, Kreativni sistemi, d.o.o. |
Thu, Apr 2 2009 7:57 AM | Permanent Link |
Francisco Fernandez | Phil,
I have an .ini file that contain the structure and indexes of tables like this: [Tablas] Tabla1 = FormasPago Tabla2 = Familias . . [FormasPago] Campo1 = CODIGO,C,2, Campo2 = NOMBRE,C,30, Indice1=CODIGO,CODIGO,"" [Familias] Campo1 = CODIGO,C,3, Campo2 = DESCRIPCIO,C,30, Indice1=CODIGO,CODIGO,"" Indice2=DESCRIPCIO,DESCRIPCIO,"" . . . I have a procedure that read this file .ini and if the table exists update and if not exists create it. This is very comfortable because when you want to modify or create tables only must to modify the .ini file and execute the procedure to update all tables with new structure. |
Mon, Apr 6 2009 8:07 PM | Permanent Link |
"Lucian Radulescu" | Hi,
I just started with EDB and I'd really like to have the same that I was able to do with DBISAM. That is: I have a script that defines all the tables, all physical/computed fields, tables, indexes (with EDB I started to add constraints and more will come I'm sure), startup demo data, configuration protected data, etc. The script allows to define reporting elements, like for a column: report heading, summary footer, formats, lengths min-max, etc. The script is compiled as a resource and is contained in the .exe. It could also sit in the application folder thus overriding the internal resource. This is useful when you have users that need different data size than what you thought was enough. (It may be a good idea to encrypt the script but I never did it) Anyway, when program starts first time it would ask where the database is and after this stuff is resolved, it will automatically create the tables (local|remote). Next time it starts, it checks each physical table structure against the "logical" structure that's compiled in the exe and if necessary automatically restructure any table that changed (oh yes, the tables changes a lot in the first year or 2 of a new application). The database location is stored in the .ini file. I don't use the registry for anything. The "scripting engine" supports external files, merging, allowing user to setup its own data sizes/lengths/language. It supports aliases for often used data so, for example, instead of explicitly selecting values for a phone-like field, you'd select DOM_TELFAX and there you go, all phone numbers in various tables will be stored the same way. Also, I have a script wizard application which allows me to friendly design the database and which also does write for me a lot of template code. That's about it ... probably I forgot some features. Now all this is being adapted for EDB, I'm almost done except for the run-time check and restructuring part. Lucian |
Wed, Apr 8 2009 2:06 PM | Permanent Link |
"Terry Swiers" | Lucian,
> The "scripting engine" supports external files, merging, allowing user > to setup its own data sizes/lengths/language. It supports aliases for > often used data so, for example, instead of explicitly selecting values > for a phone-like field, you'd select DOM_TELFAX and there you go, all > phone numbers in various tables will be stored the same way. Any chance that you would be willing to share your "scripting engine"? I'm currently in the process of working on something similar and it would be great to get something already working. -- --------------------------------------- Terry Swiers Millennium Software, Inc. http://www.1000years.com http://www.atrex.com Atrex Inventory Control/POS - Big business features without spending big business bucks! Atrex Electronic Support Options: Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp Email: mailto:support@atrex.com Newsgroup: news://news.1000years.com/millennium.atrex Fax: 1-925-829-1851 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific) --------------------------------------- |
Mon, Apr 20 2009 12:17 AM | Permanent Link |
Phil Read | I second that Lucian, would you be willing to share the scripting engine?
Thanks, Phil. Terry Swiers wrote: > Lucian, > >> The "scripting engine" supports external files, merging, allowing user >> to setup its own data sizes/lengths/language. It supports aliases for >> often used data so, for example, instead of explicitly selecting values >> for a phone-like field, you'd select DOM_TELFAX and there you go, all >> phone numbers in various tables will be stored the same way. > > Any chance that you would be willing to share your "scripting engine"? I'm > currently in the process of working on something similar and it would be > great to get something already working. > |
Mon, Apr 20 2009 2:37 PM | Permanent Link |
"Lucian Radulescu" | > I second that Lucian, would you be willing to share the scripting
> engine? The thing is I can't find a suitable way of sharing something compilable without posting a lot of adjacent code which I don't want (or can't) to share. I think I could share some code that does not compile at first and supply missing stuff on a case-by-case basis so that I won't be open-sourcing stuff that I might intend to sell sometime. I would do this thing with the condition that I could get back improved versions of this stuff .... because it seems I underestimated the time it would take me to finish (spare-time is something rare here). There are two things I am currently after: the on-fly restructuring (when the script changes) and a new wizard. The most important being the restructuring. What do you think? |
Tue, Apr 21 2009 9:28 PM | Permanent Link |
Dale Derix | Lucian Radulescu wrote:
>> I second that Lucian, would you be willing to share the scripting >> engine? > > The thing is I can't find a suitable way of sharing something > compilable without posting a lot of adjacent code which I don't want > (or can't) to share. > > I think I could share some code that does not compile at first and > supply missing stuff on a case-by-case basis so that I won't be > open-sourcing stuff that I might intend to sell sometime. I would do > this thing with the condition that I could get back improved versions > of this stuff .... because it seems I underestimated the time it would > take me to finish (spare-time is something rare here). > > There are two things I am currently after: the on-fly restructuring > (when the script changes) and a new wizard. The most important being > the restructuring. > > What do you think? The restructuring part would be a godsend. Like you said.... the database structure changes a LOT in the early stages of the design. I am holding off on releasing my first beta-release to my beta sites because I'm worried about having to harass them with minor changes to the database. Dale |
This web page was last updated on Tuesday, May 7, 2024 at 02:40 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |