Scriptcase Depencencies

Applications Forms
#1

Before I ask my question I would like to point out that I am very much in favour of RTFM (i.e. read the f****g manual). I have scoured everywhere: the manual, this forum, the net in general - and I am now here. If it has been answered before then I apologise, but if it has been answered here it is clearly is buried waaaay to deep for us mere mortals to find!

Certainly the scriptcase manual, tutorial, videos give very little info on this area (just an introduction really).

So - the question is three-fold:

  1. If you set up “Dependencies” in SC and you also have foreign key relationships set up in the database itself (in my case, MySQL InnoDB tables) - if they are defined not quite the same what takes precedence? In other words - does the database win, or SC?

  2. Related to the above question - if you do require dependencies / foreign key relationships, is it assumed by SC, that such relationships would be defined either in SC OR the database - but ideally not both?

  3. Does anyone know what the “dependency” tree symbol on the right of a dependency is for? It seems to allow you to “nest” dependencies - but if so I am unsure what this actually means, or where or why you would use it?

(NetMake - definitely more detail on the whys and wherefores of this feature would be very helpful in general please)

In advance, many thanks :slight_smile:

Adz

#2

Nobody wins. The Dependencies are handled by Scriptcase before shooting the sql to the database. Then the database does it’s thing. But why setting up dependencies if you use referential integrity in your database?
Not every database engine like ISAM has the ability of referential integrity. So you use the dependencies. If you use InnoDB then you should make a choice: maintain integrity by the software or by the innoDB engine. I don’t recommend using both.
I can’t answer 3 actually, never looked into that.

#3

Thanks for reply Albert - that makes a lot of sense.

Up until now (prior to using SC) I always maintained Referential Integrity (RI) at the database level. In my current (and first SC) project the RI was already set up at the database level (MySQL innoDB).

However, I quite like the ease that handling messaging / cascading deletes via SC brings. So I am considering stripping out the RI from the database and managing RI via SC Dependencies only. I appreciate that this is feasible - however, is it wise? Are there pros / cons of either approach?

Thanks again.

#4

[QUOTE=adz1111;23940]Thanks for reply Albert - that makes a lot of sense.

Up until now (prior to using SC) I always maintained Referential Integrity (RI) at the database level. In my current (and first SC) project the RI was already set up at the database level (MySQL innoDB).

However, I quite like the ease that handling messaging / cascading deletes via SC brings. So I am considering stripping out the RI from the database and managing RI via SC Dependencies only. I appreciate that this is feasible - however, is it wise? Are there pros / cons of either approach?

Thanks again.[/QUOTE]

At database level always is more fast. Is you have database level behaviour, you can add features with other platforms (a java webservice, for example) and database will do his work correctly, and nothing has to be developed on development side. (example, an update to a stock table when a product is sold)

At development side, it’s ok because you can change MySql, and use instead Firebird, and behaviour will be the same. This update to a stock table when a product is sold will work, because you do it programatically, and nothing is needed to add to this new database.

Main problem is when you work with legacy databases. Business Logic is better inside database with Triggers and Stored Procedures IMHO. This allows too modify database code instead of modifying you app code. If you work with your own database, and you don’t have plans to move it (I mean, from MySQL to SQL Server for example), do whatever you are more comfortable… You can always develop this BL on your code. If you have a legacy database you can’t change, then option is obvious.

#5

Got it. Thanks Guiseppe

#6

One thing to consider is that within SC you can delete child records and within the DB that might be not that easy without the proper sql. Also, referential integrity might differ if you need to create a database independent application. I.e. Oracle and MySQL do things in a different way. But in general I prefer the database way as the integrity is maintained even outside of SC.

#7

Thanks Albert