[U2] Unidata Error
Hi, Does anyone know what causes the error can't get to U_tosbcs. This has happened a couple of times for me now and each time I have had to re-install Unidata. Unidata for Windows version 7.2.5 installed on Windows 2003 server -- Kind Regards Paul Parkinson Ideal Business Services Ltd. Tel: +1758 721 4487 eml: pparkin...@idealnet.co.uk skype: 0161 408 2098 http://www.linkedin.com/in/paulparkinsonatideal -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 490 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Migration
Are there products out there to take a fully relational database and migrate it into a non-first-normal form database? We have products out there that migrate from MV databases to fully relational databases... How about the other way around 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Migration
I would think the migration would be application specific. That said, it certainly wouldn't be a difficult thing to write. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Migration
Why would it need to be application specific? I was just thinking that architecturally (sometimes) there are advantages to using a non first normal form databases. If you can read the schema of a fully relational database, couldn't you easily enough re-create the files embedding child elements into MV tables? This would be a great migration path to utilizing some advantages on MV applications? 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' - Original Message From: Kevin King precisonl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 1:34:40 PM Subject: Re: [U2] Migration I would think the migration would be application specific. That said, it certainly wouldn't be a difficult thing to write. ___ 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] Migration
Even though you are right that there can be distinct advantages MV vs. Relational. But you surely wouldn't want a Product Category file that holds all the product information in multi-valued fields. Or Order and invoice data as multivalued fields in the customer file. There is obviously a little bit more to mv database design than just parent-child relationships. On 22/12/2010 19:49, Shawn Hayes wrote: Why would it need to be application specific? I was just thinking that architecturally (sometimes) there are advantages to using a non first normal form databases. If you can read the schema of a fully relational database, couldn't you easily enough re-create the files embedding child elements into MV tables? This would be a great migration path to utilizing some advantages on MV applications? 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' - Original Message From: Kevin King precisonl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 1:34:40 PM Subject: Re: [U2] Migration I would think the migration would be application specific. That said, it certainly wouldn't be a difficult thing to write. ___ 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] Migration
I realize there is a bit more to MV database design then just parent-child relationships. The lack of constraints is both a curse and a blessing in the MV world. However, I don't accept that you wouldn't want a product category file that holds all the product information in MV fields or order and invoice data as MV fields in a customer file. A single read sounds intriguing in a web app?!?!?!? 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' - Original Message From: Mecki Foerthmann mec...@gmx.net To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 2:47:22 PM Subject: Re: [U2] Migration Even though you are right that there can be distinct advantages MV vs. Relational. But you surely wouldn't want a Product Category file that holds all the product information in multi-valued fields. Or Order and invoice data as multivalued fields in the customer file. There is obviously a little bit more to mv database design than just parent-child relationships. On 22/12/2010 19:49, Shawn Hayes wrote: Why would it need to be application specific? I was just thinking that architecturally (sometimes) there are advantages to using a non first normal form databases. If you can read the schema of a fully relational database, couldn't you easily enough re-create the files embedding child elements into MV tables? This would be a great migration path to utilizing some advantages on MV applications? 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' - Original Message From: Kevin King precisonl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 1:34:40 PM Subject: Re: [U2] Migration I would think the migration would be application specific. That said, it certainly wouldn't be a difficult thing to write. ___ 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 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Migration
Yeah, if you can design data objects that you can get in one read, Mazeltov! Date: Wed, 22 Dec 2010 13:04:32 -0800 From: go_mnviki...@yahoo.com To: u2-users@listserver.u2ug.org Subject: Re: [U2] Migration I realize there is a bit more to MV database design then just parent-child relationships. The lack of constraints is both a curse and a blessing in the MV world. However, I don't accept that you wouldn't want a product category file that holds all the product information in MV fields or order and invoice data as MV fields in a customer file. A single read sounds intriguing in a web app?!?!?!? 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' - Original Message From: Mecki Foerthmann mec...@gmx.net To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 2:47:22 PM Subject: Re: [U2] Migration Even though you are right that there can be distinct advantages MV vs. Relational. But you surely wouldn't want a Product Category file that holds all the product information in multi-valued fields. Or Order and invoice data as multivalued fields in the customer file. There is obviously a little bit more to mv database design than just parent-child relationships. On 22/12/2010 19:49, Shawn Hayes wrote: Why would it need to be application specific? I was just thinking that architecturally (sometimes) there are advantages to using a non first normal form databases. If you can read the schema of a fully relational database, couldn't you easily enough re-create the files embedding child elements into MV tables? This would be a great migration path to utilizing some advantages on MV applications? 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' - Original Message From: Kevin King precisonl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 1:34:40 PM Subject: Re: [U2] Migration I would think the migration would be application specific. That said, it certainly wouldn't be a difficult thing to write. ___ 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 ___ 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] Migration
Getting everything you want in one read is practical in limited circumstances. Getting what you want in one REQUEST, however... that's much more valuable. We use JSON formatted strings to pass structured data into and out of Unidata using subroutines to collect everything we need. This allows a web request to make a single request and get a response that could include any number of different data elements spanning one read, multiple reads, even multiple files. It's pretty slick. But that's beside the original question. The original question of taking information out of a SQL database and mapping it to a MV database is meaningless without a context, and that context - in my opinion of course - is an application that is creating and/or consuming that information, irrespective of the configuration of data refrigerator in use. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Migration
I was just thinking out loud... First of all, I am not talking about an Easy Button. I am talking about a migration path from a fully normalized relational database (hope that is a more accurate term) to take advantage of MV database functionality. Using U2 as a Data warehouse, serving data to web apps, use my U2 experience to get high paying jobs, increase efficiencies in the cloud and in BI reporting, insert need here. PS Will - There are actually 5 ways to normalize data, and yes, there is a second normal form. However, I have never heard of a First abnormal form. Also, If I thought you could write it better and faster then me, I might take you up on it;) 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' - Original Message From: fft2...@aol.com fft2...@aol.com To: u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 3:44:35 PM Subject: Re: [U2] Migration In a message dated 12/22/2010 9:02:52 AM Pacific Standard Time, go_mnviki...@yahoo.com writes: Are there products out there to take a fully relational database and migrate it into a non-first-normal form database? Fully relational is a slur. First normal form does that imply there is a first abnormal form ? Or a second normal form ? At any rate, first normal databases are just tables of columns and rows. The rows all share the same column-defined attributes. The rows are records, the columns are the attributes in those records. It's very simple. I'll write it for you for 20 grand. Will Johnson ___ 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] Daniel Jorgenson/GUS/SICK is out of the office.
I will be out of the office starting 12/22/2010 and will not return until 12/30/2010. I will respond to your message when I return. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Migration
Shawn, while I applaud the concept of finding a way to plug a MV database in where a SQL database might otherwise be ensconced, one problem with the attempt is that while the storage itself is a different animal, more so is the access. Most of these types of apps that rely on a SQL database do so because the data access code is a bunch of SQL queries. And while most MV platforms provide some type of SQL compatibility, that compatibility negates much of the benefits of the MV environment (i.e. nested data sets, etc.), single reads, etc. A while ago I did a proof of concept for a design that used PHP objects to provide pluggable access to Unidata, Universe, MySQL, and PostgreSQL. While I'm sure more talented others have taken the concept much farther than I, the more important problem in all this is that it's inventing a new data access method that isn't MV and it isn't SQL. Moreover, when coding something like this to be compatible with the least-common-denominator, often the end result is the very definition of least. Personally, I think the read/write/delete model of MV is head and shoulders better than the select/insert/update/remove model in SQL. So my efforts were invested on providing a simple read/write/delete model on top of a generic SQL db. But what I found was that there is no generic SQL. MySQL and PostgreSQL in particular are two completely different animals when it comes to insert/update. And all this ripples down to the issue of advisory locking and the other niceties that we tend to take for granted with MV. On the flip side, I am of the opinion that indexing and query optimization are generally much better on SQL. I do wish more SQL implementations supported virtual/derived/correlative fields. This is another of those wonderful things in MV that we tend to take for granted. I am all about finding ways to integrate MV into the larger technology landscape. But right now I believe the two worlds are so far apart that a general purpose application of one technology into the other camp is still problematic. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Migration
I will have to think more about this... I appreciate you sharing your experience and time!!! 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' - Original Message From: Kevin King precisonl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 4:45:24 PM Subject: Re: [U2] Migration Shawn, while I applaud the concept of finding a way to plug a MV database in where a SQL database might otherwise be ensconced, one problem with the attempt is that while the storage itself is a different animal, more so is the access. Most of these types of apps that rely on a SQL database do so because the data access code is a bunch of SQL queries. And while most MV platforms provide some type of SQL compatibility, that compatibility negates much of the benefits of the MV environment (i.e. nested data sets, etc.), single reads, etc. A while ago I did a proof of concept for a design that used PHP objects to provide pluggable access to Unidata, Universe, MySQL, and PostgreSQL. While I'm sure more talented others have taken the concept much farther than I, the more important problem in all this is that it's inventing a new data access method that isn't MV and it isn't SQL. Moreover, when coding something like this to be compatible with the least-common-denominator, often the end result is the very definition of least. Personally, I think the read/write/delete model of MV is head and shoulders better than the select/insert/update/remove model in SQL. So my efforts were invested on providing a simple read/write/delete model on top of a generic SQL db. But what I found was that there is no generic SQL. MySQL and PostgreSQL in particular are two completely different animals when it comes to insert/update. And all this ripples down to the issue of advisory locking and the other niceties that we tend to take for granted with MV. On the flip side, I am of the opinion that indexing and query optimization are generally much better on SQL. I do wish more SQL implementations supported virtual/derived/correlative fields. This is another of those wonderful things in MV that we tend to take for granted. I am all about finding ways to integrate MV into the larger technology landscape. But right now I believe the two worlds are so far apart that a general purpose application of one technology into the other camp is still problematic. ___ 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] Migration
On 22/12/10 19:49, Shawn Hayes wrote: Why would it need to be application specific? I was just thinking that architecturally (sometimes) there are advantages to using a non first normal form databases. If you can read the schema of a fully relational database, couldn't you easily enough re-create the files embedding child elements into MV tables? NO. (Sadly) I've read the other replies saying it's application specific. And it is. Ask yourself how you're going to *program* your migration tool to know which tables should be merged into an MV file. It can't be done. And the reason is inherent in relational theory. In theory, an attribute can exist on its own. In reality, an attribute is like an adjective, with nothing to describe it doesn't exist. How is your migration tool going to work out which adjectives describe which noun, and hence which attributes belong in the same file, and which ones don't? You can guess, but chances are you're going to make *several* mistakes, which could seriously damage all the advantages MV brings. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Need help with MV assoc/I-desc
I need insight from the U2 faithful. This is Unidata 7, if that affects the answer... I have a file which has 2 associated fields, such as: XEM.PERSON = 1737292:@VM:1818182:@VM:9187311 XEM.VALUE = 23:@VM:14:@VM:99 What I'd like is a field which sorts by XEM.VALUE for the associated person querying the records. That is, if person 1737292 is selecting records it would use 23 for purposes of sorting this record. If 1818182 is selecting, it would use 14 for sorting. I've done plenty of i-descriptors both with and without subroutines, but I don't have insight as to any method of allowing the query to know who's running it. I've dreamed about WHEN...ASD but Unidata only allow this in a LIST statement and it doesn't really do what I need, even if it were allowed in a SELECT. I need the data stored as listed above, but I am open to using a database trigger to store this in some alternative form that makes the query easier to deal with - but I can't think of how this might be accomplished. Any insight is appreciated. -- Jeff Butera, Ph.D. Manager of ERP Systems Hampshire College jbut...@hampshire.edu 413-559-5556 Dad, one [dollar bills] are good but tens are way better. Catherine Butera ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Migration
I assume you aren't talking about just ANY old BOM, but one with 10 or 15 levels of nesting, right ;-) 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 Mecki Foerthmann Sent: Thursday, 23 December 2010 8:36 AM To: U2 Users List Subject: Re: [U2] Migration Might be great for a specific web app, but just try to build a Bill Of Material with that kind of data structure. ;-( And wouldn't that just be a prime example for being application specific? On 22/12/2010 21:04, Shawn Hayes wrote: I realize there is a bit more to MV database design then just parent- child relationships. The lack of constraints is both a curse and a blessing in the MV world. However, I don't accept that you wouldn't want a product category file that holds all the product information in MV fields or order and invoice data as MV fields in a customer file. A single read sounds intriguing in a web app?!?!?!? 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' ___ 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
