Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread Ross Ferris
"why haven't the MV DBMS vendors created a READUO"

Possibly in part because of the need to then have resolution mechanism for when 
2 processes change the same data (assuming of course that the data wasn't, say, 
an accumulation total) --> what interface would you use  telnet will not 
work nicely with the web app described, nor with someone using, say UOJ

Still, extend a bit, and it could throw an error with the differences to be 
handled by "whatever" application layer --> but of course the real kicker in 
all of this is, and always has been, the wealth of legacy code that WOULDN'T 
use the new mechanism without a major rewrite  and if you get to THAT 
point, refer to "why U2" thread :-(



Ross Ferris
Stamina Software
Visage > Better by Design!

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Thursday, 14 July 2011 8:46 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Record Locks - How long should they last for? (Opinion)

After all of these years, why o why haven't the MV DBMS vendors created a 
READUO mechanism which allows us to optimistically lock records in exactly the 
way that George, Rex, and a hundred other app developers have indicated over 
the last 15 years?

Design tip: For all new development, abstract your file IO and all OS access 
into separate functions, Includes, and/or subroutines, away from the business 
code.  This way you can change your datastore interaction without messing with 
your application logic, and you can re-use the routines for a lot of different 
work.  The application needs to be aware of whether you're moving forward with 
a pessimistic or optimistic lock, but your app code shouldn't have to manage 
those mechanisms.

T

> From: George Gallen
> ... instead of the checksum token method, I was going to write the 
> record to a holding file with an ID that was a combination of 
> file/record/transaction token
> 
> And do a comparison using the saved item to see if record changed, but 
> only if the record lock had expired - I still wanted to keep the locks 
> since the system could be used by local users as well, which is easier 
> using the READU locally to test for locking.

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Hona, David
Always...use the right tool, for the right job...one size doesn't fit all, 
etc., etc.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen
Sent: Thursday, 14 July 2011 3:56 AM
To: 'U2 Users List'
Subject: Re: [U2] Why use U2, was Interesting Article

I am a bit of a mongo DB fanboy myself, I think regarding performance,
because of its autosharding any large scale application will definitely beat
u2.  Mongo db powers many mainstream enterprise solutions, and high profile
websites, - bit.ly comes to mind, so it certainly has a pedigree as well.

However i am also a u2 fanboy  for many many reasons.



** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains 
information which may be
confidential. 
If you are not the intended recipient please advise the sender by return email, 
do not use or
disclose the contents, and delete the message and any attachments from your 
system. Unless
specifically indicated, this email does not constitute formal advice or 
commitment by the sender
or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us, please 
reply to this
e-mail by typing Unsubscribe in the subject line. 
**



___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why Pick U2 ?

2011-07-13 Thread Rob Sobers
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.

-Rob

[1]:
http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html

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
> a
> 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@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread Kevin King
Ah... thank you for clarifying - and gently at that!
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread Bill Haskett

Kevin:

According to the BASIC manual:

Description
The UniBasic MATREADL command assigns the values found in successive 
attributes of a record to corresponding elements of a dimensioned array. 
MATREADL checks for locks and will not read a record locked with an 
exclusive (U) lock. If the record is available, MATREADL reads and sets 
a shared (L) lock on it.


Note: UniBasic locks are advisory only. They prevent access by other 
lock-checking commands only. For more information about UniBasic locks, 
see Developing UniBasic Applications.


I think this is different than the "optimistic" locking Tony was talking 
about, and another thread was discussing.  This is where one reads a 
record over the web, makes changes, then sends the data back to be 
updated.  During the update, one reads & locks the record, compares this 
record with the originally read record that was sent over the web , and 
aborts if the original record was changed during this time period.  It 
would be nice if this could be done via a statement in BASIC.  We add to 
this by accepting any changes to data we didn't change on the web side.


I think that's what Tony was talking about, but I could be wrong.

Bill


- Original Message -
*From:* precisonl...@gmail.com
*To:* U2 Users List 
*Date:* 7/13/2011 4:35 PM
*Subject:* Re: [U2] Record Locks - How long should they last for? (Opinion)

Tony, wouldn't READL in Unidata count?
___

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread Kevin King
Tony, wouldn't READL in Unidata count?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why Pick U2 ?

2011-07-13 Thread Kevin King
+1 for what David said.  Yes, there's the "limitation" that BASIC is the
only native supported language (not factoring external connectors), but as a
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@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting article

2011-07-13 Thread Tony Gravagno
> > Tony wrote:
> >> ... the MV market needs to define a consistent web 
> >> service / REST API...

Dawn Wolthuis responded:
> > Any clues on how to get any standard that all MV 
> > vendors would deploy? I'm thinking this would require 
> > third-party software...

Glen responded to Dawn:
> ...
>  there has to be an adopted RFC to define how the comm 
>  happens and gives granular detail that can not be 
>  misinterpreted by anyone implementing it. Once that is 
>  done, it's a matter of building wrappers and 
>  interfaces for all of the popular languages. ... More 
>  importantly are there more than 3 developers out there 
>  willing to suit up and then actually spend time 
>  building a language hook?

Dawn, we don't need the MV DBMS vendors to provide anything,
whether code, consent, approval, or even advocacy.  We just need
a RFC, created by us the community, which is a spec to define a
consistent API.  Here is an example of a basic interface which
can be implemented in any language:

We define a basic connection through a class called
mvEnvironment.
>From an environment we can derive an mvAccount, synonymous with
mvDatabase.  From a databasee with get a mvFile.  And from a file
we get a mvItem.  In PHP this might look like this, though the
same pattern can be applied to Ruby, Java, Go, F#, ObjectiveC, or
other common or esoteric languages:

$env = new mvEnvironment($connInfo);
$db = $env.Login($myAcccountName);
$file = $db.FileOpen("CUSTOMER");
$rec = $file.Read($ID);
$db.Logout();
$name = $rec["NAME"]; //...

That API is completely DBMS-independent, transport-independent,
and language-independent.  Based on the $connInfo, the underlying
code can use Java, a web service, .NET, C++, along with
UniObjects, UOJ, QMClient, MVSP, or any other tools to get into
the target system.  The underlying connectivity can be coded by
anyone who has interest, and a variety of such connectors will
allow developers to choose those which are more performant or
better suited to specific needs.

That's the way the rest of the world works, but someone in this
market people keep looking to the MV vendors to not only provide
the API but also the supporting implementation.  That's
completely unnecessary.  They can help, and they all do, but we
don't need to rely on them for leadership or to create the
various language bindings we need.

For what it's worth, I already have such a project defined called
mvEsperanto, and a PHP binding has been partially coded.  I just
haven't had the time to publish or maintain it.  With so little
interest (as Glen attests) even for something that most people
can appreciate, it's hard to dedicate time to anything like this
- especially without compensation.  (Nod to recent comments on
FOSS.)

T

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting article

2011-07-13 Thread Tony Gravagno
> From: Wol
> You only need a couple of users who aren't 
> free-loading, and the project is unlikely to die ...

I agree with Wol and Ian.  Most people just free-load, abuse a
generous author, and then abandon the project when the author
gets burned out, while blaming the open source model for the
failure.  There is a concept that most people don't understand
about FOSS: the "free and open" part of FOSS imply both an
ability and a responsibility to contribute back to the source.
Offer to pay FOSS authors something for their effort.  Offer to
pay some other developer to improve your free (liberty AND beer)
and open source code, and then give your updates back to the
author.  Heck, just offer some documentation to the project
website, or dedicate some time to helping other users, to free up
the author's time to write code.  One rarely sees software with
multiple contributors rotting on the vine.  More often it's a
single burned out author who chooses time with his family over
people who nag for changes and give nothing in return.

Yeah, I know that sounds preachy, but someone needs to say it in
response to this:

>From David Jordan:
> I need to know that it has ongoing support if I commit 
> a package on it, I have seen too many people get into 
> trouble when an open source application is no longer 
> supported.  Organisations have not been able to apply 
> security patches because their free application cannot 
> support the security patch.

C'mon, all of us here know that software is just text that can be
changed by anyone with competent skills.  People who "get into
trouble" have obviously not looked at the code or hired someone
competent to do so.  There's no magic in there, nothing that only
one person can figure out.  Is the cost of switching to new
software (from something 'that' important to you) really less
than the cost of fixing something you got for free?

T

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting article

2011-07-13 Thread Tony Gravagno
From:John Thompson
> This may or may not satisfy your yearning for "a 
> distributed cloud based MV environment" 
> http://devwiki.neosys.com/index.php/Main_Page

Thanks John.  I'd rather not go off the menu to another platform.
I use Pick because its fast, easy to code, and easy to adapt.  I
won't say it's more economical like some of our colleagues.
We're going to lose that battle almost every time because the MV
DBMS vendors still have their heads stuck in the per-seat
licensing model, and the rest of the world moved beyond that over
a decade ago.

I use Pick because it has served me well for decades but I am
compelled to look elsewhere for modern needs because in addition
to licensing, the MVDBMS vendors have not made fundamental
changes to the MV model in many years.  The database has
stagnated as all development efforts have been dedicated to
connectivity options.  In the 1990's when client/server was the
rage, sure, that was the time when these companies needed to
adapt to communications needs.  But they're still there.  The
rest of the world has accepted communications as a given and is
now on to new methods of deployment over those pipes.  For some
reason our market stops and focuses on things for years at a time
when they need to be much more agile and move with the markets.

Dove-tailing with other postings here: MongoDB and others aren't
usually chosen for their technical superiority.  They're used
because they're easily accessible via bindings from popular
languages in modern topologies.  The typical coding pattern for
all of these environments is something like this:

env = new MyPlatform(serverpath)
db = env.getDatabase(dbname)
info = db.getField(table,field)
change(info)
result = db.setField(table,field)

With that pattern, the location of the database is irrelevant.
The pipes are irrelevant.  The actual storage mechanisms are
irrelevant.  What's important is the set of functions exposed in
the API which allow developers to do whatever they want from
wherever the code is deployed.

We can do all of this with U2 and all other MV platforms using
every technology out there.  Again, I've done it.  The difference
between us and them is that we don't publish those bindings, nor
do we publish tutorials for mainstream developer consumption, nor
do we have people in our community extending beyond forums like
this to help newcomers to adopt the model.

We talk about how easy MV is to use compared to other platfoms,
but we position in a very different fashion.  We leave marketing
to the DBMS vendors who don't do it, and we leave sales to app
vars who are motivated to sell to individual sites rather than
evangelize the platform.  We don't attract individual developers
because the platform is unapproachable to individuals without an
application as a context.  Competing models (not Oracle or SQL
Server, but MySQL, Mongo, and the cloud offerings) aren't being
sold to companies as a bundled solution, but to individuals, who
then seek to build or buy on their newfound platform of choice.
Through individuals, the platforms gain a grassroots following,
much like the one we used to claim.

Yes, it would be easy for me to use a completely different
platform for distributed computing, or even to create an ugly
mechanism to bind U2 with Mongo or Amazon, but I would much
prefer for the leaders in this market to wake up and sell me a
modern solution.  Note that Caché actually does have such a
solution, and while I'm very fond of that platform, creating a
distributed topology for an MV app may still be as challenging as
using a completely different platform.

T

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread Tony Gravagno
After all of these years, why o why haven't the MV DBMS vendors
created a READUO mechanism which allows us to optimistically lock
records in exactly the way that George, Rex, and a hundred other
app developers have indicated over the last 15 years?

Design tip: For all new development, abstract your file IO and
all OS access into separate functions, Includes, and/or
subroutines, away from the business code.  This way you can
change your datastore interaction without messing with your
application logic, and you can re-use the routines for a lot of
different work.  The application needs to be aware of whether
you're moving forward with a pessimistic or optimistic lock, but
your app code shouldn't have to manage those mechanisms.

T

> From: George Gallen
> ... instead of the checksum token method, I was going 
> to write the record to a holding file with an ID that 
> was a combination of file/record/transaction token
> 
> And do a comparison using the saved item to see if 
> record changed, but only if the record lock had 
> expired - I still wanted to keep the locks since the 
> system could be used by local users as well, which is 
> easier using the READU locally to test for locking.

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why Pick U2 ?

2011-07-13 Thread David Jordan
One thing that all the other database lack is that U2 has a sophisticated 
business rules engine.   The SQL bastardise language in other databases is a 
nightmare compared to unibasic.When everyone is talking APIs, they are 
mostly talking about the presentation layer.  Presentation layer interface to 
other databases is better than U2, but U2 is better for storing business logic 
in the database.   I am seeing too many applications being developed out their 
that are breaking the rules of client server where the business logic is in the 
client.  Too many tools use the database as a simple data repository and 
require business rules to be built into the client.   

David Jordan
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread Dawn Wolthuis
We use "optimistic locking" with a version number in each record (in our
case Cache' handles the versioning based on our specification of the files,
but either versioning or checksums works). This is a solid approach for web
apps instead of using pessimistic locking.  --dawn

On Wed, Jul 13, 2011 at 12:07 PM, Rex Gozar  wrote:

> Based on your description, you are using a pessimistic locking
> approach (similar to a telnet user) for a web application, so choosing
> a timeout would be arbitrary.  Your "heartbeat" idea could be tied in
> to avoid having to manually release records.
>
> It seems like a bad idea to force a connectionless, stateless web
> browser to act like a connected, stateful telnet session.
>
> Why not switch to an optimistic locking approach?  Checksum the
> original data (record) when it is passed to the browser.  When
> returned from the browser, lock the record and checksum it again. If
> the checksums match proceed with the write; otherwise, send a message
> back to the browser allowing the user to cancel or resubmit their
> changes.  This way, record locks should only last a few milliseconds.
>
> rex
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>



-- 
Dawn M. Wolthuis

Take and give some delight today
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread John Hester
That sounds feasable, but depending on how your web application is used
you might also have to consider the possibility of multiple web users
accessing the same record.  You might need some unique user id key
included in the token that gets carried around by the web session.  I
think you would have to completely deny access to all but the first web
user because you only have stale data to give them at that point.  And
of course there's always the possibility someone's browser might crash
and cause them to lock themselves out of the application for the
pre-determined READU period.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen
Sent: Wednesday, July 13, 2011 10:28 AM
To: U2 Users List
Subject: Re: [U2] Record Locks - How long should they last for?
(Opinion)

> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
> boun...@listserver.u2ug.org] On Behalf Of Rex Gozar
> Sent: Wednesday, July 13, 2011 1:08 PM
> To: U2 Users List
> Subject: Re: [U2] Record Locks - How long should they last for?
> (Opinion)
> 
> Why not switch to an optimistic locking approach?  Checksum the
> original data (record) when it is passed to the browser.  When
> returned from the browser, lock the record and checksum it again. If
> the checksums match proceed with the write; otherwise, send a message
> back to the browser allowing the user to cancel or resubmit their
> changes.  This way, record locks should only last a few milliseconds.
> 

I was thinking along similar lines as well as an option, instead of the
checksum token method, I was going to write the record to a holding file
with an ID that was a combination of file/record/transaction token

And do a comparison using the saved item to see if record changed, but 
only if the record lock had expired - I still wanted to keep the locks
since the system could be used by local users as well, which is easier
using the READU locally to test for locking.

> rex
> ___
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Symeon Breen
Primarily the mv data structure - is simple yet powerfull (to a point i
agree) 
Databasic feels like you are really in the data when programming, and not
divorced via layers and api's - i know you could correlate to stored
procedures, but it is not the same.
I like the way you open a udt shell and then inside it can do lots of
things, or pass things into it. It all follows the normal linux shell ethos.
Obviously i use high level (vs2010) tools sets as well, but the ability to
go command line, at linux and at u2 is great.
Similarly the way the database tables are os files - bit of a plus and minus
point for some - but gives you massive flexibility.
Being able to write databasic in ED with one eye closed, a beer in one hand,
a cat on my knee, holding a conversation with the kids and watching tv - all
at the same time - even with Visual Studios being a fantastic ide, and my
experience of using .net from the start and java for many years, i still
seem to need to concentrate much more on these other languages, and t-sql -
well its the manual out every time i venture in there.

Many more things as well - these are not really tangible business case
things but personal usage things.



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rob Sobers
Sent: 13 July 2011 21:12
To: U2 Users List
Subject: Re: [U2] Why use U2, was Interesting Article

Let's see if I can draw a response from you, Symeon :-)...

What exactly makes you a U2 fanboy?  What features in U2 are you happy to
pay for?

-Rob

On Wed, Jul 13, 2011 at 1:56 PM, Symeon Breen  wrote:

> I am a bit of a mongo DB fanboy myself, I think regarding performance,
> because of its autosharding any large scale application will definitely
> beat
> u2.  Mongo db powers many mainstream enterprise solutions, and high
profile
> websites, - bit.ly comes to mind, so it certainly has a pedigree as well.
>
> However i am also a u2 fanboy  for many many reasons.
>
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rob Sobers
> Sent: 13 July 2011 16:52
> To: U2 Users List
> Subject: Re: [U2] Why use U2, was Interesting Article
>
> Wait, why can't you add a new column to a table in MySQL or SQL Server?
>
> Putting aside the RDMS arguments, (*apart from familiarity*) why wouldn't
> you use something like MongoDB or CouchDB, which are accessible from more
> programming environments, over U2?  They offer the same schema flexibility
> and disk space benefits you cite with U2 and so much more.
>
> MongoDB, for instance, has built-in mechanisms for auto-sharding,
> replication, REST API, full-text index, and I can go on and on.  And it's
> FREE! :-)
>
> I can't speak to performance, but I'd love to benchmark MongoDB versus U2.
>  Maybe I will.
>
> I know I sound like a MongoDB fanboy, but I think it's a straight-up U2
> killer.  I challenge anyone to find an area where U2 beats it.
>
> -Rob
>
> On Wed, Jul 13, 2011 at 10:59 AM, Jeff Schasny  wrote:
>
> > It scales well. I benchmarked 20K concurrent users for a wholesale
> > distribution application on a single (HP Superdome) server and that was
> 10
> > years ago.
> >
> > The database structure can be painlessly modified which makes it much
> > easier for new applications development. Need a new field, slap it on
the
> > end of the table and go on with your day, try that with your favorite
> > relational environment.
> >
> > Not so important today as it once was when disk was more expensive,but
it
> > uses significantly less disk space than a relational database storing
the
> > equivalent data. This also contributes to needing significantly less
> overall
> > computing power to support X number of users for a given application due
> to
> > more efficient IO, i.e. less disk reads required.
> >
> > You can use SQL, but you don't have to. This, above all, is the MY most
> > significant reason to use U2.
> >
> > Holt, Jake wrote:
> >
> >> I'm not sure being cheaper than Oracle can really be touted as an
> >> advantage, there aren't many things out there that are more expensive
> than
> >> oracle =D.  And all of those things you just mentioned are also true of
> many
> >> FREE databases, so again, why pick U2?
> >>
> >> -Original Message-
> >> From:
> u2-users-bounces@listserver.**u2ug.org<
> u2-users-boun...@listserver.u2ug.org>
> [mailto:
> >>
> u2-users-bounces@**listserver.u2ug.org<
> u2-users-boun...@listserver.u2ug.org>
> ]
> >> On Behalf Of Israel, John R.
> >> Sent: Wednesday, July 13, 2011 9:31 AM
> >> To: 'U2 Users List'
> >> Subject: Re: [U2] Interesting Article
> >>
> >> You may have answered your own question.  Why do YOU like it?
> >>
> >> It is easy to develop, quick to code, fairly robust query language, and
> a
> >> lot cheaper than the BIG databases (Oracle, DB2, etc).
> >>
> >>
> >> John Israel
> >> Senior Programmer/Analyst
> >> Dayton Superior C

Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Rob Sobers
Let's see if I can draw a response from you, Symeon :-)...

What exactly makes you a U2 fanboy?  What features in U2 are you happy to
pay for?

-Rob

On Wed, Jul 13, 2011 at 1:56 PM, Symeon Breen  wrote:

> I am a bit of a mongo DB fanboy myself, I think regarding performance,
> because of its autosharding any large scale application will definitely
> beat
> u2.  Mongo db powers many mainstream enterprise solutions, and high profile
> websites, - bit.ly comes to mind, so it certainly has a pedigree as well.
>
> However i am also a u2 fanboy  for many many reasons.
>
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rob Sobers
> Sent: 13 July 2011 16:52
> To: U2 Users List
> Subject: Re: [U2] Why use U2, was Interesting Article
>
> Wait, why can't you add a new column to a table in MySQL or SQL Server?
>
> Putting aside the RDMS arguments, (*apart from familiarity*) why wouldn't
> you use something like MongoDB or CouchDB, which are accessible from more
> programming environments, over U2?  They offer the same schema flexibility
> and disk space benefits you cite with U2 and so much more.
>
> MongoDB, for instance, has built-in mechanisms for auto-sharding,
> replication, REST API, full-text index, and I can go on and on.  And it's
> FREE! :-)
>
> I can't speak to performance, but I'd love to benchmark MongoDB versus U2.
>  Maybe I will.
>
> I know I sound like a MongoDB fanboy, but I think it's a straight-up U2
> killer.  I challenge anyone to find an area where U2 beats it.
>
> -Rob
>
> On Wed, Jul 13, 2011 at 10:59 AM, Jeff Schasny  wrote:
>
> > It scales well. I benchmarked 20K concurrent users for a wholesale
> > distribution application on a single (HP Superdome) server and that was
> 10
> > years ago.
> >
> > The database structure can be painlessly modified which makes it much
> > easier for new applications development. Need a new field, slap it on the
> > end of the table and go on with your day, try that with your favorite
> > relational environment.
> >
> > Not so important today as it once was when disk was more expensive,but it
> > uses significantly less disk space than a relational database storing the
> > equivalent data. This also contributes to needing significantly less
> overall
> > computing power to support X number of users for a given application due
> to
> > more efficient IO, i.e. less disk reads required.
> >
> > You can use SQL, but you don't have to. This, above all, is the MY most
> > significant reason to use U2.
> >
> > Holt, Jake wrote:
> >
> >> I'm not sure being cheaper than Oracle can really be touted as an
> >> advantage, there aren't many things out there that are more expensive
> than
> >> oracle =D.  And all of those things you just mentioned are also true of
> many
> >> FREE databases, so again, why pick U2?
> >>
> >> -Original Message-
> >> From:
> u2-users-bounces@listserver.**u2ug.org<
> u2-users-boun...@listserver.u2ug.org>
> [mailto:
> >>
> u2-users-bounces@**listserver.u2ug.org<
> u2-users-boun...@listserver.u2ug.org>
> ]
> >> On Behalf Of Israel, John R.
> >> Sent: Wednesday, July 13, 2011 9:31 AM
> >> To: 'U2 Users List'
> >> Subject: Re: [U2] Interesting Article
> >>
> >> You may have answered your own question.  Why do YOU like it?
> >>
> >> It is easy to develop, quick to code, fairly robust query language, and
> a
> >> lot cheaper than the BIG databases (Oracle, DB2, etc).
> >>
> >>
> >> John Israel
> >> Senior Programmer/Analyst
> >> Dayton Superior Corporation
> >> 1125 Byers Road
> >> Miamisburg, OH  45342
> >>
> >>
> >> -Original Message-
> >> From:
> u2-users-bounces@listserver.**u2ug.org<
> u2-users-boun...@listserver.u2ug.org>
> [mailto:
> >>
> u2-users-bounces@**listserver.u2ug.org<
> u2-users-boun...@listserver.u2ug.org>
> ]
> >> On Behalf Of Holt, Jake
> >> Sent: Wednesday, July 13, 2011 10:26 AM
> >> To: U2 Users List
> >> Subject: Re: [U2] Interesting Article
> >>
> >> I have come to like U2 over the past few years but an honest question:
> >>
> >> Why would anyone ever pick U2 beyond familiarity and personal
> preference?
> >>  Can anyone think of any situation that another (and in a lot of cases a
> >> *far* cheaper) database isn't a better fit?
> >>
> >> Maybe if U2 had it's own niche like MySQL has with web hosting, there
> >> would be a market Rocket could focus on ?
> >> __**_
> >> U2-Users mailing list
> >> U2-Users@listserver.u2ug.org
> >>
> http://listserver.u2ug.org/**mailman/listinfo/u2-users<
> http://listserver.u2u
> g.org/mailman/listinfo/u2-users>
> >>
> >> __**_
> >> U2-Users mailing list
> >> U2-Users@listserver.u2ug.org
> >>
> http://listserver.u2ug.org/**mailman/listinfo/u2-users<
> http://listserver.u2u
> g.org/mailman/listinfo/u2-users>
> >> __**_
> >> U2-Users mailing list
> >> U2-Users@l

Re: [U2] Why Pick U2 ?

2011-07-13 Thread Rob Sobers
I don't think the flavor of DB is a great indicator of whether you need a
dedicated DBA role.  Scale of deployment is probably a far better indicator.

If we're talking about personnel costs -- have you ever been able to hire a
college freshman for $20 bucks an hour who already has 2 years of U2 under
his belt from building WordPress sites?  The point being that there is much
more qualified MySQL and SQL Server talent available than U2 talent.

Also, DBs like MySQL are battle tested.  You'll rarely find a core bug in
MySQL if you're using a stable version.  Why?  Because hundreds of thousands
of developers are using it and thus finding the bugs (likely) before they
hit you.  When I was working with U2 every day, we consistently found and
were affected by core bugs.  Costly ones, too.

-Rob

On Wed, Jul 13, 2011 at 1:43 PM, Bill Brutzman wrote:

> Let's focus on costs for a moment.   While of course MySQL is widely
> available... businesses that are seriously using MySQL generally buy
> maintenance for the year.  While I suppose that, pricewise,  MySQL support
> rather reasonable, it is also not "free"... and I suppose is approx. the
> same price as U2 maintenance.
>
> There other support costs to consider.  A lot of shops have say a
> programmer and a DBA.  When these shops find that there are comparable
> companies doing  U2 who have one guy who is both the programmer and the
> DBA... they wonder...  That then is (some of) the supporting reasoning.
>
> --Bill
>
> -Original Message-
>
> Sent: Wednesday, July 13, 2011 1:06 PM
> Subject: Re: [U2] Why Pick U2 ?
>
> "When comparing U2 to Oracle or Microsoft SQL, U2 wins.  When comparing U2
> to MySQL, U2 still wins."
>
> That's a pretty blanket statement with no supporting reasoning.
>
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Steve Romanow
It saves to disk, and iirc you can specify how many replicants it is written
to to be considered "written".

You may be confusing it with memcached or redis, but even they have
persistence.
On Jul 13, 2011 2:02 PM, "Bill Brutzman"  wrote:
> Is Mongo a "persistent" database? That is, does Mongo save the data to
disk, or just RAM?
>
> If it is RAM, then that is ok for tweets between high school chicks... but
not so good for bank accounts.
>
> --Bill
>
> -Original Message-
> Sent: Wednesday, July 13, 2011 1:56 PM
> Subject: Re: [U2] Why use U2, was Interesting Article
>
> I am a bit of a mongo DB fanboy myself, I think regarding performance,
because of its autosharding any large scale application will definitely beat
u2. Mongo db powers many mainstream enterprise solutions, and high profile
websites, - bit.ly comes to mind, so it certainly has a pedigree as well.
>
> However i am also a u2 fanboy for many many reasons.
>
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Bill Brutzman
Is Mongo a "persistent" database?  That is, does Mongo save the data to disk, 
or just RAM?

If it is RAM, then that is ok for tweets between high school chicks... but not 
so good for bank accounts.

--Bill

-Original Message-
Sent: Wednesday, July 13, 2011 1:56 PM
Subject: Re: [U2] Why use U2, was Interesting Article

I am a bit of a mongo DB fanboy myself, I think regarding performance, because 
of its autosharding any large scale application will definitely beat u2.  Mongo 
db powers many mainstream enterprise solutions, and high profile websites, - 
bit.ly comes to mind, so it certainly has a pedigree as well.

However i am also a u2 fanboy  for many many reasons.

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Steve Romanow
Shutterfly also has moved to mongo in production.
On Jul 13, 2011 1:56 PM, "Symeon Breen"  wrote:
> I am a bit of a mongo DB fanboy myself, I think regarding performance,
> because of its autosharding any large scale application will definitely
beat
> u2. Mongo db powers many mainstream enterprise solutions, and high profile
> websites, - bit.ly comes to mind, so it certainly has a pedigree as well.
>
> However i am also a u2 fanboy for many many reasons.
>
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rob Sobers
> Sent: 13 July 2011 16:52
> To: U2 Users List
> Subject: Re: [U2] Why use U2, was Interesting Article
>
> Wait, why can't you add a new column to a table in MySQL or SQL Server?
>
> Putting aside the RDMS arguments, (*apart from familiarity*) why wouldn't
> you use something like MongoDB or CouchDB, which are accessible from more
> programming environments, over U2? They offer the same schema flexibility
> and disk space benefits you cite with U2 and so much more.
>
> MongoDB, for instance, has built-in mechanisms for auto-sharding,
> replication, REST API, full-text index, and I can go on and on. And it's
> FREE! :-)
>
> I can't speak to performance, but I'd love to benchmark MongoDB versus U2.
> Maybe I will.
>
> I know I sound like a MongoDB fanboy, but I think it's a straight-up U2
> killer. I challenge anyone to find an area where U2 beats it.
>
> -Rob
>
> On Wed, Jul 13, 2011 at 10:59 AM, Jeff Schasny  wrote:
>
>> It scales well. I benchmarked 20K concurrent users for a wholesale
>> distribution application on a single (HP Superdome) server and that was
10
>> years ago.
>>
>> The database structure can be painlessly modified which makes it much
>> easier for new applications development. Need a new field, slap it on the
>> end of the table and go on with your day, try that with your favorite
>> relational environment.
>>
>> Not so important today as it once was when disk was more expensive,but it
>> uses significantly less disk space than a relational database storing the
>> equivalent data. This also contributes to needing significantly less
> overall
>> computing power to support X number of users for a given application due
> to
>> more efficient IO, i.e. less disk reads required.
>>
>> You can use SQL, but you don't have to. This, above all, is the MY most
>> significant reason to use U2.
>>
>> Holt, Jake wrote:
>>
>>> I'm not sure being cheaper than Oracle can really be touted as an
>>> advantage, there aren't many things out there that are more expensive
> than
>>> oracle =D. And all of those things you just mentioned are also true of
> many
>>> FREE databases, so again, why pick U2?
>>>
>>> -Original Message-
>>> From:
> u2-users-bounces@listserver.**u2ug.org<
u2-users-boun...@listserver.u2ug.org>
> [mailto:
>>>
> u2-users-bounces@**listserver.u2ug.org<
u2-users-boun...@listserver.u2ug.org>
> ]
>>> On Behalf Of Israel, John R.
>>> Sent: Wednesday, July 13, 2011 9:31 AM
>>> To: 'U2 Users List'
>>> Subject: Re: [U2] Interesting Article
>>>
>>> You may have answered your own question. Why do YOU like it?
>>>
>>> It is easy to develop, quick to code, fairly robust query language, and
a
>>> lot cheaper than the BIG databases (Oracle, DB2, etc).
>>>
>>>
>>> John Israel
>>> Senior Programmer/Analyst
>>> Dayton Superior Corporation
>>> 1125 Byers Road
>>> Miamisburg, OH 45342
>>>
>>>
>>> -Original Message-
>>> From:
> u2-users-bounces@listserver.**u2ug.org<
u2-users-boun...@listserver.u2ug.org>
> [mailto:
>>>
> u2-users-bounces@**listserver.u2ug.org<
u2-users-boun...@listserver.u2ug.org>
> ]
>>> On Behalf Of Holt, Jake
>>> Sent: Wednesday, July 13, 2011 10:26 AM
>>> To: U2 Users List
>>> Subject: Re: [U2] Interesting Article
>>>
>>> I have come to like U2 over the past few years but an honest question:
>>>
>>> Why would anyone ever pick U2 beyond familiarity and personal
preference?
>>> Can anyone think of any situation that another (and in a lot of cases a
>>> *far* cheaper) database isn't a better fit?
>>>
>>> Maybe if U2 had it's own niche like MySQL has with web hosting, there
>>> would be a market Rocket could focus on ?
>>> __**_
>>> U2-Users mailing list
>>> U2-Users@listserver.u2ug.org
>>>
> http://listserver.u2ug.org/**mailman/listinfo/u2-users<
http://listserver.u2u
> g.org/mailman/listinfo/u2-users>
>>>
>>> __**_
>>> U2-Users mailing list
>>> U2-Users@listserver.u2ug.org
>>>
> http://listserver.u2ug.org/**mailman/listinfo/u2-users<
http://listserver.u2u
> g.org/mailman/listinfo/u2-users>
>>> __**_
>>> U2-Users mailing list
>>> U2-Users@listserver.u2ug.org
>>>
> http://listserver.u2ug.org/**mailman/listinfo/u2-users<
http://listserver.u2u
> g.org/mailman/listinfo/u2-users>
>>>
>>>
>>>
>>
>> --
>> --**-

Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Symeon Breen
I am a bit of a mongo DB fanboy myself, I think regarding performance,
because of its autosharding any large scale application will definitely beat
u2.  Mongo db powers many mainstream enterprise solutions, and high profile
websites, - bit.ly comes to mind, so it certainly has a pedigree as well.

However i am also a u2 fanboy  for many many reasons.



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rob Sobers
Sent: 13 July 2011 16:52
To: U2 Users List
Subject: Re: [U2] Why use U2, was Interesting Article

Wait, why can't you add a new column to a table in MySQL or SQL Server?

Putting aside the RDMS arguments, (*apart from familiarity*) why wouldn't
you use something like MongoDB or CouchDB, which are accessible from more
programming environments, over U2?  They offer the same schema flexibility
and disk space benefits you cite with U2 and so much more.

MongoDB, for instance, has built-in mechanisms for auto-sharding,
replication, REST API, full-text index, and I can go on and on.  And it's
FREE! :-)

I can't speak to performance, but I'd love to benchmark MongoDB versus U2.
 Maybe I will.

I know I sound like a MongoDB fanboy, but I think it's a straight-up U2
killer.  I challenge anyone to find an area where U2 beats it.

-Rob

On Wed, Jul 13, 2011 at 10:59 AM, Jeff Schasny  wrote:

> It scales well. I benchmarked 20K concurrent users for a wholesale
> distribution application on a single (HP Superdome) server and that was 10
> years ago.
>
> The database structure can be painlessly modified which makes it much
> easier for new applications development. Need a new field, slap it on the
> end of the table and go on with your day, try that with your favorite
> relational environment.
>
> Not so important today as it once was when disk was more expensive,but it
> uses significantly less disk space than a relational database storing the
> equivalent data. This also contributes to needing significantly less
overall
> computing power to support X number of users for a given application due
to
> more efficient IO, i.e. less disk reads required.
>
> You can use SQL, but you don't have to. This, above all, is the MY most
> significant reason to use U2.
>
> Holt, Jake wrote:
>
>> I'm not sure being cheaper than Oracle can really be touted as an
>> advantage, there aren't many things out there that are more expensive
than
>> oracle =D.  And all of those things you just mentioned are also true of
many
>> FREE databases, so again, why pick U2?
>>
>> -Original Message-
>> From:
u2-users-bounces@listserver.**u2ug.org
[mailto:
>>
u2-users-bounces@**listserver.u2ug.org
]
>> On Behalf Of Israel, John R.
>> Sent: Wednesday, July 13, 2011 9:31 AM
>> To: 'U2 Users List'
>> Subject: Re: [U2] Interesting Article
>>
>> You may have answered your own question.  Why do YOU like it?
>>
>> It is easy to develop, quick to code, fairly robust query language, and a
>> lot cheaper than the BIG databases (Oracle, DB2, etc).
>>
>>
>> John Israel
>> Senior Programmer/Analyst
>> Dayton Superior Corporation
>> 1125 Byers Road
>> Miamisburg, OH  45342
>>
>>
>> -Original Message-
>> From:
u2-users-bounces@listserver.**u2ug.org
[mailto:
>>
u2-users-bounces@**listserver.u2ug.org
]
>> On Behalf Of Holt, Jake
>> Sent: Wednesday, July 13, 2011 10:26 AM
>> To: U2 Users List
>> Subject: Re: [U2] Interesting Article
>>
>> I have come to like U2 over the past few years but an honest question:
>>
>> Why would anyone ever pick U2 beyond familiarity and personal preference?
>>  Can anyone think of any situation that another (and in a lot of cases a
>> *far* cheaper) database isn't a better fit?
>>
>> Maybe if U2 had it's own niche like MySQL has with web hosting, there
>> would be a market Rocket could focus on ?
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>>
http://listserver.u2ug.org/**mailman/listinfo/u2-users
>>
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>>
http://listserver.u2ug.org/**mailman/listinfo/u2-users
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>>
http://listserver.u2ug.org/**mailman/listinfo/u2-users
>>
>>
>>
>
> --
> --**--**
> 
> Jeff Schasny - Denver, Co, USA
> jschasny at gmail dot com
> --**--**
> 
> __**_
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
>
http://listserver.u2ug.org/**mailman/listinfo/u2-users
>
___

Re: [U2] Why Pick U2 ?

2011-07-13 Thread Bill Brutzman
Let's focus on costs for a moment.   While of course MySQL is widely 
available... businesses that are seriously using MySQL generally buy 
maintenance for the year.  While I suppose that, pricewise,  MySQL support 
rather reasonable, it is also not "free"... and I suppose is approx. the same 
price as U2 maintenance.

There other support costs to consider.  A lot of shops have say a programmer 
and a DBA.  When these shops find that there are comparable companies doing  U2 
who have one guy who is both the programmer and the DBA... they wonder...  That 
then is (some of) the supporting reasoning.

--Bill

-Original Message-

Sent: Wednesday, July 13, 2011 1:06 PM
Subject: Re: [U2] Why Pick U2 ?

"When comparing U2 to Oracle or Microsoft SQL, U2 wins.  When comparing U2 to 
MySQL, U2 still wins."

That's a pretty blanket statement with no supporting reasoning.

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why Pick U2 ?

2011-07-13 Thread Kevin King
I'm a fan of U2 - MV in general even.  But in this case I have to agree with
Rob: We really need to quantify what it means to "win" otherwise the words
do little more than tickle an emotional response.

Having had some time with several MV systems as well as several SQL systems,
there are areas of each that in a head-to-head comparison, one would "win"
over the other based on price, performance, flexibility, scalability, and
reliability.  And it's not always U2/MV and it's not always SQL.  For
getting right to work without extensive tuning, I'd say U2 holds the upper
hand.  In terms of indexing and application of multiple indexes to queries,
I'd put PostgreSQL over MySQL and both over U2.  For clustering, Oracle.
 For the GUI, SQL Server.  For that matter, I'd rank the flexibility of
triggers in Unidata over triggers in Universe, and they're both MV.  So it's
a complex task to assign a "winner" carte blanche without looking deeply
into the eyes of specific areas of the products and their applicability to
specific problems to be solved.

My personal opinion is that there are benefits to all of it.  So in that way
picking a "winner" really doesn't do much more than polarize.  I know if I
were creating an application from scratch today, the criteria I might use to
make the decision would be different from anyone else making the same
decision even if it were the same application.  There is "better" and there
is "worse" but all of it must be considered in the larger context of the
problem to be solved to mean anything at all.

-K
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread George Gallen
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
> boun...@listserver.u2ug.org] On Behalf Of Rex Gozar
> Sent: Wednesday, July 13, 2011 1:08 PM
> To: U2 Users List
> Subject: Re: [U2] Record Locks - How long should they last for?
> (Opinion)
> 
> Why not switch to an optimistic locking approach?  Checksum the
> original data (record) when it is passed to the browser.  When
> returned from the browser, lock the record and checksum it again. If
> the checksums match proceed with the write; otherwise, send a message
> back to the browser allowing the user to cancel or resubmit their
> changes.  This way, record locks should only last a few milliseconds.
> 

I was thinking along similar lines as well as an option, instead of the
checksum token method, I was going to write the record to a holding file
with an ID that was a combination of file/record/transaction token

And do a comparison using the saved item to see if record changed, but 
only if the record lock had expired - I still wanted to keep the locks
since the system could be used by local users as well, which is easier
using the READU locally to test for locking.

> rex
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting article

2011-07-13 Thread John Thompson
Not that I'm promoting or selling anything either way... I stumbled upon
this just recently.

I've spent all of an hour tooling around with it.

This may or may not satisfy your yearning for "a distributed cloud based
MV environment"

http://devwiki.neosys.com/index.php/Main_Page

On Tue, Jul 12, 2011 at 3:46 PM, Tony Gravagno <3xk547...@sneakemail.com>wrote:

> > From: Bill Haskett
> > I wonder if this implies that those who U2 are all
> > database "gurus"?  :-)
>
> I get the humor but...
> I need to create a distributed cloud-based MV environment,
> obviously smaller than Facebook but using the same concept of
> "shards" for distributed storage and computing.  So far most of
> the Pick people I talk to have no idea what I'm talking about let
> alone how to implement it with MV.  We're not gurus if we don't
> speak the same language as the rest of the world.
>
> As to "old SQL", there is a revolution going on out there and I'm
> wondering if other MV people have seen this:  Look at the data
> storage for Android, Google App Engine, AmazonDB, etc.  All of
> these platforms and others are using name/value pairs with some
> relational functionality, but they're not using SQL.  Once again
> we're missing a whole new generation of data hungry applications.
>
> While there are still new methods of data storage and retrieval
> being created all the time, the MV market needs to define a
> consistent web service / REST API for data access and rule
> execution, accessible from any client.  (That's easy, I have done
> this many times for various projects and for most MV platforms.)
> >From there, professionals in this community can position as
> experts to provide applications, DBMS support services, rules in
> BASIC, hosting, and mentoring for a new generation of people who
> might like to use BASIC for rules rather than Java, Ruby, Go, or
> whatever else they're just starting to learn.
>
> Yeah... as if...
>
> Tony Gravagno
> Nebula Research and Development
> TG@ remove.pleaseNebula-RnD.com
> remove.pleaseNebula-RnD.com/blog
> Visit PickWiki.com! Contribute!
> http://Twitter.com/TonyGravagno
>
>
>
> > From:Symeon Breen
>
> > Some on here will be interested in this. I esp like Gigaom's
> quote
> >
> > "old SQL (as he calls it) is good for nothing" and
> > needs to be "sent to the home for retired software."
> > After all, he explained, SQL was created decades ago
> > before the web, mobile devices and sensors forever
> > changed how and how often databases are accessed.
> >
> >
>  arns-database-guru-33864>
>
>
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>



-- 
John Thompson
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread Rex Gozar
Based on your description, you are using a pessimistic locking
approach (similar to a telnet user) for a web application, so choosing
a timeout would be arbitrary.  Your "heartbeat" idea could be tied in
to avoid having to manually release records.

It seems like a bad idea to force a connectionless, stateless web
browser to act like a connected, stateful telnet session.

Why not switch to an optimistic locking approach?  Checksum the
original data (record) when it is passed to the browser.  When
returned from the browser, lock the record and checksum it again. If
the checksums match proceed with the write; otherwise, send a message
back to the browser allowing the user to cancel or resubmit their
changes.  This way, record locks should only last a few milliseconds.

rex
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why Pick U2 ?

2011-07-13 Thread Rob Sobers
"When comparing U2 to Oracle or Microsoft SQL, U2 wins.  When comparing U2
to MySQL, U2 still wins."

That's a pretty blanket statement with no supporting reasoning.

-Rob

On Wed, Jul 13, 2011 at 12:34 PM, Bill Brutzman wrote:

> In the old days (when men were men) there were computer scientists and
> engineers who would analyze technologies and make design decisions...
> sometimes choosing one technology over another.  In those days, computers
> were a lot slower.  MulitValue always had tremendous speed advantages and
> was chosen by experts who were designing things like MRP (Material
> Requirements Planning) systems that had to handle a lot of complex data or
> say do complex calculations.
>
> These days, a lot of talented computer scientists and engineers realize
> that MultiValue still has a lot to offer.  Design decisions for MultiValue
> now seems to have more to do with total costs.  When comparing U2 to Oracle
> or Microsoft SQL, U2 wins.  When comparing U2 to MySQL, U2 still wins.
> Microsoft's Azure SQL is something of a new animal with a new costing model.
>  Will U2 win?
>
> --Bill
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:
> u2-users-boun...@listserver.u2ug.org] On Behalf Of Holt, Jake
> Sent: Wednesday, July 13, 2011 10:44 AM
> To: U2 Users List
> Subject: Re: [U2] Interesting Article
>
> I'm not sure being cheaper than Oracle can really be touted as an
> advantage, there aren't many things out there that are more expensive than
> oracle =D.  And all of those things you just mentioned are also true of many
> FREE databases, so again, why pick U2?
>
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why Pick U2 ?

2011-07-13 Thread Bill Brutzman
In the old days (when men were men) there were computer scientists and 
engineers who would analyze technologies and make design decisions... sometimes 
choosing one technology over another.  In those days, computers were a lot 
slower.  MulitValue always had tremendous speed advantages and was chosen by 
experts who were designing things like MRP (Material Requirements Planning) 
systems that had to handle a lot of complex data or say do complex calculations.

These days, a lot of talented computer scientists and engineers realize that 
MultiValue still has a lot to offer.  Design decisions for MultiValue now seems 
to have more to do with total costs.  When comparing U2 to Oracle or Microsoft 
SQL, U2 wins.  When comparing U2 to MySQL, U2 still wins.   Microsoft's Azure 
SQL is something of a new animal with a new costing model.  Will U2 win?

--Bill

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Holt, Jake
Sent: Wednesday, July 13, 2011 10:44 AM
To: U2 Users List
Subject: Re: [U2] Interesting Article

I'm not sure being cheaper than Oracle can really be touted as an advantage, 
there aren't many things out there that are more expensive than oracle =D.  And 
all of those things you just mentioned are also true of many FREE databases, so 
again, why pick U2?

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


[U2] locking problem

2011-07-13 Thread Lloyd Cottrell
Active Read Waiters:  Owner   Waiter
Device  Inode Userno  Userno
  3014662102470   01101
  30146647290   01094
  3014662386511051030
  30146615667   01088
  30146647247   01137
  30146647290   01159
  30146617609   01143
  30146617544   01155
  30146646939   01105
  30146617124   01157
  30146647247   01172
  30146653310   01169
  30146623865   01052
  30146615687   01175
  30146647290   01001
  3014661568711441107
  3014661754011441092
  3014665331211441120
  3014665337211441181
  3014661568711441025
  3014662229711441189

on universe 10.3.1 and aix 5.2

I am getting a locked owned by userno 0, and causing a lot of locking
issues.  Anyone know what this might be or how to fix this?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Rob Sobers
Wait, why can't you add a new column to a table in MySQL or SQL Server?

Putting aside the RDMS arguments, (*apart from familiarity*) why wouldn't
you use something like MongoDB or CouchDB, which are accessible from more
programming environments, over U2?  They offer the same schema flexibility
and disk space benefits you cite with U2 and so much more.

MongoDB, for instance, has built-in mechanisms for auto-sharding,
replication, REST API, full-text index, and I can go on and on.  And it's
FREE! :-)

I can't speak to performance, but I'd love to benchmark MongoDB versus U2.
 Maybe I will.

I know I sound like a MongoDB fanboy, but I think it's a straight-up U2
killer.  I challenge anyone to find an area where U2 beats it.

-Rob

On Wed, Jul 13, 2011 at 10:59 AM, Jeff Schasny  wrote:

> It scales well. I benchmarked 20K concurrent users for a wholesale
> distribution application on a single (HP Superdome) server and that was 10
> years ago.
>
> The database structure can be painlessly modified which makes it much
> easier for new applications development. Need a new field, slap it on the
> end of the table and go on with your day, try that with your favorite
> relational environment.
>
> Not so important today as it once was when disk was more expensive,but it
> uses significantly less disk space than a relational database storing the
> equivalent data. This also contributes to needing significantly less overall
> computing power to support X number of users for a given application due to
> more efficient IO, i.e. less disk reads required.
>
> You can use SQL, but you don't have to. This, above all, is the MY most
> significant reason to use U2.
>
> Holt, Jake wrote:
>
>> I'm not sure being cheaper than Oracle can really be touted as an
>> advantage, there aren't many things out there that are more expensive than
>> oracle =D.  And all of those things you just mentioned are also true of many
>> FREE databases, so again, why pick U2?
>>
>> -Original Message-
>> From: 
>> u2-users-bounces@listserver.**u2ug.org[mailto:
>> u2-users-bounces@**listserver.u2ug.org]
>> On Behalf Of Israel, John R.
>> Sent: Wednesday, July 13, 2011 9:31 AM
>> To: 'U2 Users List'
>> Subject: Re: [U2] Interesting Article
>>
>> You may have answered your own question.  Why do YOU like it?
>>
>> It is easy to develop, quick to code, fairly robust query language, and a
>> lot cheaper than the BIG databases (Oracle, DB2, etc).
>>
>>
>> John Israel
>> Senior Programmer/Analyst
>> Dayton Superior Corporation
>> 1125 Byers Road
>> Miamisburg, OH  45342
>>
>>
>> -Original Message-
>> From: 
>> u2-users-bounces@listserver.**u2ug.org[mailto:
>> u2-users-bounces@**listserver.u2ug.org]
>> On Behalf Of Holt, Jake
>> Sent: Wednesday, July 13, 2011 10:26 AM
>> To: U2 Users List
>> Subject: Re: [U2] Interesting Article
>>
>> I have come to like U2 over the past few years but an honest question:
>>
>> Why would anyone ever pick U2 beyond familiarity and personal preference?
>>  Can anyone think of any situation that another (and in a lot of cases a
>> *far* cheaper) database isn't a better fit?
>>
>> Maybe if U2 had it's own niche like MySQL has with web hosting, there
>> would be a market Rocket could focus on ?
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>> http://listserver.u2ug.org/**mailman/listinfo/u2-users
>>
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>> http://listserver.u2ug.org/**mailman/listinfo/u2-users
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>> http://listserver.u2ug.org/**mailman/listinfo/u2-users
>>
>>
>>
>
> --
> --**--**
> 
> Jeff Schasny - Denver, Co, USA
> jschasny at gmail dot com
> --**--**
> 
> __**_
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/**mailman/listinfo/u2-users
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting article

2011-07-13 Thread Wols Lists
On 13/07/11 16:15, McGowan, Ian wrote:
> I respectfully disagree - through the years the few times I've been royally 
> screwed, it's always by a closed-source vendor.  I have never made a major 
> commitment to an open-source tool and been burned.  Debian, Eclipse, Tomcat, 
> Apache and Postgres have been good to me for a long time.  Not saying that 
> open-source lasts forever, but when something does get orphaned, I have more 
> options.

Add to which, if you're in that boat, so are a lot of other people. If
you rely on a piece of Open Source, you need to make sure you've got one
or two members of your staff well known to the project (even if they
don't do much). Then when you need something done, they can do it.

You only need a couple of users who aren't free-loading, and the project
is unlikely to die ...

Cheers,
Wol
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting article

2011-07-13 Thread McGowan, Ian
I respectfully disagree - through the years the few times I've been royally 
screwed, it's always by a closed-source vendor.  I have never made a major 
commitment to an open-source tool and been burned.  Debian, Eclipse, Tomcat, 
Apache and Postgres have been good to me for a long time.  Not saying that 
open-source lasts forever, but when something does get orphaned, I have more 
options.

http://blogs.computerworlduk.com/open-enterprise/2009/10/open-source-makes-big-gains-at-the-london-stock-exchange/index.htm

I think the LSE found a way to justify open-source to their board and 
regulators...


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Jordan
Sent: Tuesday, July 12, 2011 7:22 PM
To: U2 Users List
Subject: Re: [U2] Interesting article

Hi Rob
Open source has its advantages, but there is the reverse side.  I need to know 
that it has ongoing support if I commit a package on it, I have seen too many 
people get into trouble when an open source application is no longer supported. 
 Organisations have not been able to apply security patches because their free 
application cannot support the security patch.   There is also the question of 
security, is open source easier to hack, is it easier to put in back doors.  My 
clients want to know what happens if I get hit by the proverbial bus, I need to 
justify continuity to them and the open source environment does not provide 
that continuity.   I am not going to be able to put an application into the 
London Stock exchange based on open source, they could not justify to their 
board, risk managers and regulators.

The cost of supporting open source is sometimes greater than paid for 
applications.  The question to ensure, does U2 provide a value add to my 
development.

Regards

David Jordan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rob Sobers
Sent: Wednesday, 13 July 2011 11:41 AM
To: U2 Users List
Subject: Re: [U2] Interesting article

David,

You're correct that U2 users need to be vocal about what they want, but Rocket 
has to be proactive, too.  Surely they have a few analysts on staff that can 
read Techmeme or attend a few conferences and see for themselves where 
developers are headed.  It's probably not wise to only listen to *current
*U2 users anyway.

I started to make a list in my head of what I'd ask Rocket for, but then I 
stopped because everything I'd ask for I can get* *elsewhere...for free...right 
now.

If I were starting a brand new project today, I'd be hard pressed to find a 
single reason to pick a U2 database over a free, open-source alternative like 
MongoDB, PostgreSQL, or MySQL which have drivers for almost every language, 
heaps of documentation and troubleshooting resources online, fast release 
cycles, and great (free) developer tools.

Can anyone else think of one?

-Rob


The biggest thing for me is accessibility from other languages, because the

On Tue, Jul 12, 2011 at 7:02 PM, David Jordan  wrote:

> Rob your comments are not wrong.  However U2 management want to go 
> where they think the market is.  As users we don't tell them anything 
> and then complain that they are not mind readers and are not heading in the 
> direction
> we want to go.   As a user group, we give users a voice to be able to set
> direction.  Of course there are a million one views about the future, but we
> can build a business case based on the wishes of the majority.   I have sat
> down with Rocket and explained how Microsoft Azure could provide a 
> market opportunity and how U2 could work in this environment and I am 
> working with them to look at its feasibility.  Others are looking at 
> REST and a range of other APIs.  Rocket is not so much ignoring us 
> rather we as users are not talking to Rocket constructively.
>
> What is important is to turn this discussion into something constructive.
>  If Rocket asked you what you want, what would you say.
>
> David Jordan
> VP U2UG
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
-
IMPORTANT NOTICE:   This message is intended only for the addressee
and may contain confidential, privileged information.  If you are
not the intended recipient, you may not use, copy or disclose any
information contained in the message.  If you have received this
message in error, please notify the sender by reply e-mail and
delete the message.
___
U

Re: [U2] Why use U2, was Interesting Article

2011-07-13 Thread Jeff Schasny
It scales well. I benchmarked 20K concurrent users for a wholesale 
distribution application on a single (HP Superdome) server and that was 
10 years ago.


The database structure can be painlessly modified which makes it much 
easier for new applications development. Need a new field, slap it on 
the end of the table and go on with your day, try that with your 
favorite relational environment.


Not so important today as it once was when disk was more expensive,but 
it uses significantly less disk space than a relational database storing 
the equivalent data. This also contributes to needing significantly less 
overall computing power to support X number of users for a given 
application due to more efficient IO, i.e. less disk reads required.


You can use SQL, but you don't have to. This, above all, is the MY most 
significant reason to use U2.


Holt, Jake wrote:

I'm not sure being cheaper than Oracle can really be touted as an advantage, 
there aren't many things out there that are more expensive than oracle =D.  And 
all of those things you just mentioned are also true of many FREE databases, so 
again, why pick U2?

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R.
Sent: Wednesday, July 13, 2011 9:31 AM
To: 'U2 Users List'
Subject: Re: [U2] Interesting Article

You may have answered your own question.  Why do YOU like it?

It is easy to develop, quick to code, fairly robust query language, and a lot 
cheaper than the BIG databases (Oracle, DB2, etc).


John Israel
Senior Programmer/Analyst
Dayton Superior Corporation
1125 Byers Road
Miamisburg, OH  45342


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Holt, Jake
Sent: Wednesday, July 13, 2011 10:26 AM
To: U2 Users List
Subject: Re: [U2] Interesting Article

I have come to like U2 over the past few years but an honest question:

Why would anyone ever pick U2 beyond familiarity and personal preference?  Can 
anyone think of any situation that another (and in a lot of cases a *far* 
cheaper) database isn't a better fit?

Maybe if U2 had it's own niche like MySQL has with web hosting, there would be 
a market Rocket could focus on ?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

  


--

Jeff Schasny - Denver, Co, USA
jschasny at gmail dot com

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting Article

2011-07-13 Thread Holt, Jake
I'm not sure being cheaper than Oracle can really be touted as an advantage, 
there aren't many things out there that are more expensive than oracle =D.  And 
all of those things you just mentioned are also true of many FREE databases, so 
again, why pick U2?

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R.
Sent: Wednesday, July 13, 2011 9:31 AM
To: 'U2 Users List'
Subject: Re: [U2] Interesting Article

You may have answered your own question.  Why do YOU like it?

It is easy to develop, quick to code, fairly robust query language, and a lot 
cheaper than the BIG databases (Oracle, DB2, etc).


John Israel
Senior Programmer/Analyst
Dayton Superior Corporation
1125 Byers Road
Miamisburg, OH  45342


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Holt, Jake
Sent: Wednesday, July 13, 2011 10:26 AM
To: U2 Users List
Subject: Re: [U2] Interesting Article

I have come to like U2 over the past few years but an honest question:

Why would anyone ever pick U2 beyond familiarity and personal preference?  Can 
anyone think of any situation that another (and in a lot of cases a *far* 
cheaper) database isn't a better fit?

Maybe if U2 had it's own niche like MySQL has with web hosting, there would be 
a market Rocket could focus on ?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting Article

2011-07-13 Thread Israel, John R.
You may have answered your own question.  Why do YOU like it?

It is easy to develop, quick to code, fairly robust query language, and a lot 
cheaper than the BIG databases (Oracle, DB2, etc).


John Israel
Senior Programmer/Analyst
Dayton Superior Corporation
1125 Byers Road
Miamisburg, OH  45342


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Holt, Jake
Sent: Wednesday, July 13, 2011 10:26 AM
To: U2 Users List
Subject: Re: [U2] Interesting Article

I have come to like U2 over the past few years but an honest question:

Why would anyone ever pick U2 beyond familiarity and personal
preference?  Can anyone think of any situation that another (and in a
lot of cases a *far* cheaper) database isn't a better fit?

Maybe if U2 had it's own niche like MySQL has with web hosting, there
would be a market Rocket could focus on ?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting Article

2011-07-13 Thread Holt, Jake
I have come to like U2 over the past few years but an honest question:

Why would anyone ever pick U2 beyond familiarity and personal
preference?  Can anyone think of any situation that another (and in a
lot of cases a *far* cheaper) database isn't a better fit?

Maybe if U2 had it's own niche like MySQL has with web hosting, there
would be a market Rocket could focus on ?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread BobW
It would depend on what the application was on the web server.  I'd think
about the security issues a bank has and how long it was before their
sessions "timeout" and require you to re-login.  Then you have the
consideration of how long a user might take to "complete" a transaction,
such as dating sites profile entry.  Nothing worse than getting just the
right profile descriptions, hitting NEXT and finding out I didn't type fast
enough for saving the page. (Just guessing about that one.  Honest!)  If you
can break up the entry (or whatever the action) into multiple stages, the
time would obviously be able to be shorter.  As to what the exact amount of
time would be, I'd find someone who hasn't seen your process, time them,
then probably double, or even triple, the time they need to complete the
task.

Just some thoughts that come to mind.

BobW

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen
Sent: Wednesday, July 13, 2011 5:59 AM
To: U2 Users List
Subject: [U2] Record Locks - How long should they last for? (Opinion)

I had started to write a perl / uv integration modules for use with perl
(but could be anything else - php, ... ) whereas you
could OPEN files and READ / WRITE records and manipulate dynamic arrays.

Basically, I had a UV phantom (or not phantom - take your pick), which was
linked to a perl listener program via FIFOs/Seqential
READ/WRITEs

The perl (or whatever)  programs would negotiate commands via the port,
which then the perl listener would pass off to the UV program.

It was originally designed so a website that was not local (but had perl
ability for a .cgi), could OPEN and READ/WRITE data to a UV Server.

If I needed to lock a record (READU), that wasn't a problem, but I needed to
come up with a time frame to allow that
record to be locked for, I initially chose 15 minutes (after which the UV
program would release the lock).

Given the issues of web traffic, where one might pull a record, then close a
browser, which unless you have some sort of AJAX
routine in the webpage which can alert the server that browser is no longer
open (maybe hitting an API every 5 seconds - once
you go 30 seconds without the API being registered - the server can consider
the browser page to be closed?)

So what is the thought on how long should one keep a record lock?

This doesn't have anything to do with physical programs that run from telnet
or so, where the system once it senses it's disconnect
would release all locks - which is not so easy to do with a web connection,
and one that is connected via port commands (essentially
an API in itself).


George Gallen
Senior Programmer/Analyst
Accounting/Data Division, EDI Administrator
ggal...@wyanokegroup.com
ph:856.848.9005 Ext 220
The Wyanoke Group
http://www.wyanokegroup.com



___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1390 / Virus Database: 1516/3761 - Release Date: 07/12/11

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


Re: [U2] Interesting Article

2011-07-13 Thread Bill Brutzman
It would of interest to learn from Rocket about plans (or no plans) for cloud 
(hosted) U2.

--Bill
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


[U2] Record Locks - How long should they last for? (Opinion)

2011-07-13 Thread George Gallen
I had started to write a perl / uv integration modules for use with perl (but 
could be anything else - php, ... ) whereas you
could OPEN files and READ / WRITE records and manipulate dynamic arrays.

Basically, I had a UV phantom (or not phantom - take your pick), which was 
linked to a perl listener program via FIFOs/Seqential
READ/WRITEs

The perl (or whatever)  programs would negotiate commands via the port, which 
then the perl listener would pass off to the UV program.

It was originally designed so a website that was not local (but had perl 
ability for a .cgi), could OPEN and READ/WRITE data to a UV Server.

If I needed to lock a record (READU), that wasn't a problem, but I needed to 
come up with a time frame to allow that
record to be locked for, I initially chose 15 minutes (after which the UV 
program would release the lock).

Given the issues of web traffic, where one might pull a record, then close a 
browser, which unless you have some sort of AJAX
routine in the webpage which can alert the server that browser is no longer 
open (maybe hitting an API every 5 seconds - once
you go 30 seconds without the API being registered - the server can consider 
the browser page to be closed?)

So what is the thought on how long should one keep a record lock?

This doesn't have anything to do with physical programs that run from telnet or 
so, where the system once it senses it's disconnect
would release all locks - which is not so easy to do with a web connection, and 
one that is connected via port commands (essentially
an API in itself).


George Gallen
Senior Programmer/Analyst
Accounting/Data Division, EDI Administrator
ggal...@wyanokegroup.com
ph:856.848.9005 Ext 220
The Wyanoke Group
http://www.wyanokegroup.com



___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users