So what are libraries?
They are nothing but a collection of subroutines that somebody else has written. And what do you do if you can't find a function in your library that does exactly what you need?
You write your own, right?
And by the time you have found the right function in your library you could have written the 3 lines of code in Basic that do the same thing already. I write Databasic code every day and have done so for over 20 years and hardly ever have use for functions, because if I needed them I would have written my own library by.


On 14/07/2011 02:25, Rob Sobers wrote:
I have to heartily disagree that U2 has a sophisticated business rules
engine.  U2 Basic is such a limited language.  It barely has functions, and
you have to home brew almost everything.

Microsoft's T-SQL stored procedures are just as horrible to write as U2
Basic programs.  As Jeff Atwood put it -- "Stored procedures should be
considered database assembly language." [1] Why do you think Microsoft now
allows you to call CLR code from stored procedures?  Because it's so much
more efficient to work with the data (i.e., enforce the business rules) in a
modern language like C# that has *actual libraries* for doing useful things.

I agree that business rules shouldn't be on the client -- but who says they
have to be in the database?  Look at the ever-so-popular MVC architecture.
  The models (i.e., the code that works with the database and enforces all of
the business rules) are isolated from the views (i.e., the
client/presentation code) entirely.



On Wed, Jul 13, 2011 at 7:29 PM, Kevin King<>  wrote:

+1 for what David said.  Yes, there's the "limitation" that BASIC is the
only native supported language (not factoring external connectors), but as
language native to the environment, this BASIC is really pretty rich by
comparison to the stored procedure languages of other DBs.
U2-Users mailing list

U2-Users mailing list
U2-Users mailing list

Reply via email to