handling multiple tables

[Ap.Muthu]

Often multiple tables have to be independantly updated. How is this achieved thru' DaDaBIk?
eg.,
jokeID, joke, jokeCatID - in one table.
jokeCatID, jokeCategory - in another table
where jokeCatID field is used to join the two tables.

While the first table may be managed by selecting the jokeCategory for the jokeCatID field, when we wish to add a new jokeCategory, how is this done? - must we have another instance of DaDaBIk with a fresh internal table or manage with the same table with an extra field to segregate forms?

 

[Eugenio]

Ap.Muthu wrote:
>
> Often multiple tables have to be independantly updated. How
> is this achieved thru' DaDaBIk?
> eg.,
> jokeID, joke, jokeCatID - in one table.
> jokeCatID, jokeCategory - in another table
> where jokeCatID field is used to join the two tables.
>
> While the first table may be managed by selecting the
> jokeCategory for the jokeCatID field, when we wish to add a
> new jokeCategory, how is this done? - must we have another
> instance of DaDaBIk with a fresh internal table or manage
> with the same table with an extra field to segregate forms?

At the moment the only solution is to have another instance of DaDaBIK.
The possibility to edit multiple tables will be probably implemented in future versions of DaDaBIK.

(Latest version of DaDaBIK when this message was posted: 1.6)

 

[Ap.Muthu]

A temporary hack is to declare an internal table name prefix or suffix variable in the config.php and have it automatically generate the name of the internal table by itself and put the value of the $table_name variable in a separate ****.inc.php file to be included in the config.php where the $table_name variable would have been. This way, changing the table name in a single file would render it capable of being used for another table.

Possibly a field in the internal table to indicate a form name would be a more elegant solution.

 

[Eugenio]

Ap.Muthu wrote:
>
> A temporary hack is to declare an internal table name prefix
> or suffix variable in the config.php and have it
> automatically generate the name of the internal table by
> itself and put the value of the $table_name variable in a
> separate ****.inc.php file to be included in the config.php
> where the $table_name variable would have been. This way,
> changing the table name in a single file would render it
> capable of being used for another table.
>
> Possibly a field in the internal table to indicate a form
> name would be a more elegant solution.

Do you mean "to indicate a table name"?

(Latest version of DaDaBIK when this message was posted: 1.6)

 

[Ap.Muthu]

Actually, though each instance of DaDaBIk is for a table, it happens very often that only a subset of fields for viewing / updation is needed. Hence a distinction between table name and form name. The existing config file can have the internal table name declared as dependant on a new variable along with a suffix/prefix and an include statement for another include file at the place where table name would be. This new include file would have the table name & form name only.

eg., in config.php repl lines fro:-
comment: // select database name
to
comment: // please specify at least the above parameters

with:-
// select internal DB Suffix
$table_internal_prefix = "DaDaBIk_";
$table_internal_suffix = "_intdb";

include ("./include/table_config.php") // the file containing the form and table names
// select internal table name
$table_internal_name = $table_internal_prefix.$table_name.$table_internal_suffix;
// please specify at least the above parameters

-----
and in the new file table_config.php:-
// select main table name
$db_name = "booking";
$db_form_name = "booking_form_1"; // here you have just to invent a name, e.g. dadabik_my_tab
// please specify at least the above parameters

-----

This way after initial setup of host, db, pwd, etc, we can leave the config.php file alone and edit only the second file for the table, form names.

Hope this is useful in the meanwhile till you provide multi table functionality.

 

[Eugenio]

Ap.Muthu wrote:
>
> Actually, though each instance of DaDaBIk is for a table, it
> happens very often that only a subset of fields for viewing /
> updation is needed. Hence a distinction between table name
> and form name. The existing config file can have the internal
> table name declared as dependant on a new variable along with
> a suffix/prefix and an include statement for another include
> file at the place where table name would be. This new include
> file would have the table name & form name only.
> Hope this is useful in the meanwhile till you provide multi
> table functionality.

[......]

Ok, but the form name actually doesn't affect anything in DaDaBIK, why should you have different form name?

(Latest version of DaDaBIK when this message was posted: 1.6)

 

[Ap.Muthu]

When we wish to edit a certain sub-set of fields in a table, we use one form name and when we want to edit the whole or another subset of fields in the same table, we use another form name. As each view/form name would entail a different internal table, we use the form name as the unique identifier of the view whilst keeping the internal table prefix and / or suffix the same. This may be done till you come up with a single internal table with an extra field for unique form name so that the entire set of tables in a single database can be handled from therein.

 

[Eugenio]

Ap.Muthu wrote:
>
> When we wish to edit a certain sub-set of fields in a table,
> we use one form name and when we want to edit the whole or
> another subset of fields in the same table, we use another
> form name.

[......]

Ok, I understant what you mean, it could be a solution, even if I haven't tried it yet.


(Latest version of DaDaBIK when this message was posted: 1.6)