RE: Re: [U2] Where Will the .NET Apps Live ?
Part of the reason you may be enamoured with OI is BECAUSE of the integration with the backend DB this is true of any tool worth it's weight - once you have the data structures in place the applications tend to write themselves, with just a few tweaks. Hey, that give me a great idea for a book title Algorithms + Data Structures = - classic ideas stand the test of time, and I think that Multi-value IS a classic idea ! Ross Ferris Stamina Software Visage an Evolution in Software Development -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of David Tod Sigafoos Sent: Tuesday, 28 December 2004 5:20 AM To: [EMAIL PROTECTED] Subject: Re: Re: [U2] Where Will the .NET Apps Live ? brian, Monday, December 27, 2004, 3:44:01 AM, you wrote: snip bbcu But you are absolutely right that it all begins and ends with the server bbcu logic. Get that right, and the choice of front end become pretty much bbcu irrelevant. I always tell my clients to build the server first: it is bbcu so much easier to verify and QA before the front end is assembled. bbcu Unfortunately too many sites still seem to approach it from the other bbcu end and end up with garbage and high QA costs. Have to disagree a bit with this. Although the backend is very important so is the front end. Knowing your market .. the way users actually do their work for the specific market and tying the two together. That is the challenge. The choice of front ends is just a critical for this portion of the environment. Although Delphi is a brilliant product, OpenInsight is much better for any MV environment. With a native bond to U2 it is just about the perfect tool for MV front end development. Front end does matter. Although you can set a screw with a hammer a screw driver would be the preferred tool g -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ Whenever you are in doubt...apply the first test. Recall the face of the poorest and the weakest man whom you may have seen, and ask yourself if the step you contemplate is going to be any use to him...True development puts first those that society puts last.-Mahatma Gandhi --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.5 - Release Date: 26/12/2004 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.5 - Release Date: 26/12/2004 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
=?iso-8859-1?Q?RE:_[U2]_Where_Will_the_=2ENET_Apps_Live_??=
- Related to separating rules from UI, how about separating the rules from the database? None of the MV providers have shown interest in extracting the BASIC run-time (sans DB) to run in a compact form on the client. Tony, I did exactly that for uvCase: a windows based development tool sold in the UK to UniVerse developers. This took the concept a step forward by encapsulating a BASIC run machine as a COM component - the component handled the interpretation and all of the regular syntax/internal functions etc. and could be fitted into any environment as it simply raised events for any action that it needed to perform outside of its own machine e.g. open/read/write/execute/select/print etc. I also extended it to handle a final syntax that was a mixture of mv Basic and VB designed to provide a gentle learning curve for existing uv developers to migrate their knowledge into the Windows world. uvCase was tool and event oriented, so the syntax looked something like this: Open CUSTOMER to CUSTOMER Else Msgbox Cannot open customers STOP End Read CustRec From CUSTOMER, OrderScreen.CustomerID Then OrderScreen.Forename.Text = CustRec3 End (etc) Of all the aspects of uvCase, this mixed language was one that proved very popular with developers. Sadly, uvCase was never released outside the UK for various sales/political reasons, and I am no longer able to work on or support it :-( Until I write my own equivalent, that is. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
=?iso-8859-1?Q?Re:_[U2]_Where_Will_the_=2ENET_Apps_Live_??=
Have to disagree a bit with this. Although the backend is very important so is the front end. Knowing your market .. the way users actually do their work for the specific market and tying the two together. That is the challenge. The choice of front ends is just a critical for this portion of the environment. David, My point was not that the front end is not important - of course it is - just as sticking a few text boxes and buttons together does not a GUI make. My point was that many of the front end technologies have converged to such an extent that the choice of a specific technology for implementing the front end has become less important than understanding the design (front and back), so long as the back end can be designed in an open and stable way. And the best way to achieve that is to build and QA the back end first and to hold the logic on the server or in a centralized location (which is best on the server) interpreted by the client. I prefer interpreted, as it means that you can guarantee that all changes are rolled out immediately to the accessing clients: no issues with installing changes, cached logic, people not updating or any of that jazz. I've developed a good number of complex C/S applications both ways and been bitten by writing hard coded VB and Delphi before I learned the hard way: development issues pale in comparison with the overheads of deployment and support. And in practice the overheads involved in running an interpreter reading server definitions are insignificant. And QAing server based business rules is so much easier before you add the front end - otherwise with any failures you end up debugging across the client/server divide (never good, black box scenario) and with potential slagging matches between those developing the client and server code regarding where the failures are occurring. Simply, the advantage of a TELNET session is that you can SEE and TRAP any errors so much more clearly. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
I tend to put basic syntactical validation in the client and application-specific data integrity type validation in the back-end. Sure that creates more client-specific code, but with standard routines it's not such a bother. The reason I do this is that I'm concerned about traffic. Connectivity tools change pricing models from time to time, and people deal with various ISP's and hosting providers. I don't want to assume that voluminous bandwidth is always going to be a free ride. Not only that, but when used indiscriminately, even non-persistent connections to the back end will take their toll on licenses for the DBMS and some connectivity products. Brian's comment about intepreted code wasn't lost on me and I need to consider it - I confess I've never done that. Putting some logic at a middle tier, not necessarily at the DBMS server, also has advantages. At the risk of yet more bandwidth, but not consuming licenses, many basic validation rules can be exposed as client-independent web services. That approximates that interpreted layer, makes changes virtually instantaneous, and eliminates deployment issues. Tony TG at removethis Nebula dash RnD dotster com brian-at-brianleach.co.uk |U2UG| wrote: ... And the best way to achieve that is to build and QA the back end first and to hold the logic on the server or in a centralized location (which is best on the server) interpreted by the client. I prefer interpreted, as it means that you can guarantee that all changes are rolled out immediately to the accessing clients: no issues with installing changes, cached logic, people not updating or any of that jazz. ... And QAing server based business rules is so much easier before you add the front end... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] XML extraction file
Could someone please help me with the XPath syntax for extracting an element from an xml file with a particular attribute value? The xml data file has several different comments elements in it and I would like to extract each one into the dynamic array that the rest of the xml file is extracted into using UniVerse basic. My basic program is able to extract all of the other data from the xml file. Extraction file data: U2xml:field_extraction path=[EMAIL PROTECTED]'SHIPPING']/text() / Xml file data: comments type=SHIPPINGSome shipping comments/comments Ross Craig Alaska Diesel Electric --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Tony: [stuff snipped] Brian's comment about intepreted code wasn't lost on me and I need to consider it - I confess I've never done that. Putting some logic at a middle tier, not necessarily at the DBMS server, also has advantages. At the risk of yet more bandwidth, but not consuming licenses, many basic validation rules can be exposed as client-independent web services. That approximates that interpreted layer, makes changes virtually instantaneous, and eliminates deployment issues. Goes to show you what we'll do for cost considerations. Introducing another tier seems like madness, unless it's cheaper. :-) That's why it sometimes looks like the main MV providers aren't really interested in exposing the dbms model to the mainstream. In IBM's case, they probably just want to kill the product, eventually, because growing the product competes with their other product(s). In RDUS's case, they probably just want to squeeze it for what they can because they believe it'll die by itself. Not sure about jBase though. Maybe if they can sell it to China they'll reach a critical mass that'll support a migration from D3 and U2. What a bizarre thought. :-) Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] LOOP or GOTO on READNEXT
While quibbling over nanoseconds, some of may have missed a little flaw in your tests that would have nothing to do with caching or memory allocation. The elapsed time of each test could have been different enough that the differences in the counts would fall within that margin of error. This is particularly noticeable in Tom's test below. Using 'TIME() + some.number' to determine the stopping point could make the first iteration up to .999 seconds shorter than the second. When you're processing hundreds of thousands or millions of iterations per second, that fraction of a second could account for the differences. Using Tom's example below, if the system time was 1.999 at the start, then ETIME for the first pass would be 10005, resulting in 4.001 seconds of processing. The second pass would start around 10005.001 and ETIME would be 10010, resulting in 4.999 seconds of processing. When processing 600,000 iterations, that means a margin of error of 120,000. Hence the results are skewed toward the second loop. To get around this, you could: A) Use SYSTEM(12)(on UD) to get milliseconds or other function to get a more exact measurement of time to make margin of error smaller. B) Add some code at the beginning to ensure TIME() had just incremented to the next number before starting a loop. C) Loop for more than a few seconds to make the partial second a smaller part of the total. D) Loop for a fixed number of times, logging starting and ending times (preferably in milliseconds or smaller). Dean P.S. I apologize for the late post. I'm once again way behind but couldn't resist this one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, December 13, 2004 2:32 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] LOOP or GOTO on READNEXT Allen E. Elwood [EMAIL PROTECTED] wrote on 13 Dec 2004 09:36:42 -0800 I didn't include the delete statement because what you really wanted to test was the LOOP/REPEAT vs. the GO construct. Guess what? After doing four consecutive runs and picking the fastest of each four, LOOP/REPEAT wins!! ... So does this end the GOTO holy war? Less Filling, Tastes Better, Goes Faster??? ;-) Ummm... no. Using UniData 6.0 on AIX 5.1 I tested a similar program with a tighter GOTO loop: 01: * Test Loop Speeds 02: * 03:CTR = 0 04:ETIME = TIME() + 5 05:LOOP WHILE TIME() ETIME DO 06: CTR += 1 07:REPEAT 08:PRINT While :CTR 09: * 10:CTR = 0 11:ETIME = TIME() + 5 12: 10 CTR += 1 13:IF TIME() ETIME THEN GOTO 10 14:PRINT Go To :CTR I also wrote a separate program with lines 2-9 above after line 14, so I could test if the order of execution made a difference. I ran each program four times, with the following results (W indicates Winner :-) -- Go To First - -- While First - Go To Count While Count Go To Count While Count --- --- --- --- 769730 W 752380667050 W 458545 655809 734709 W 747373 W 592827 576565 688953 W 785676 W 611628 629807 748265 W 714679 W 564908 The second loop for whatever reason seems to have an advantage. Overall, I suspect there isn't a lot of difference. --Tom Pellitieri Century Equipment --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] LOOP or GOTO on READNEXT
It is a silly argument... I just think about utilizing a goto or its facsmile within C++. C, C# (not that I ever did) and it would quickly garner a big red F in school... I don't know of any other language where it would even get beyond a snicker at the unpolished newbie... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, December 28, 2004 5:27 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] LOOP or GOTO on READNEXT While quibbling over nanoseconds, some of may have missed a little flaw in your tests that would have nothing to do with caching or memory allocation. The elapsed time of each test could have been different enough that the differences in the counts would fall within that margin of error. This is particularly noticeable in Tom's test below. Using 'TIME() + some.number' to determine the stopping point could make the first iteration up to .999 seconds shorter than the second. When you're processing hundreds of thousands or millions of iterations per second, that fraction of a second could account for the differences. Using Tom's example below, if the system time was 1.999 at the start, then ETIME for the first pass would be 10005, resulting in 4.001 seconds of processing. The second pass would start around 10005.001 and ETIME would be 10010, resulting in 4.999 seconds of processing. When processing 600,000 iterations, that means a margin of error of 120,000. Hence the results are skewed toward the second loop. To get around this, you could: A) Use SYSTEM(12)(on UD) to get milliseconds or other function to get a more exact measurement of time to make margin of error smaller. B) Add some code at the beginning to ensure TIME() had just incremented to the next number before starting a loop. C) Loop for more than a few seconds to make the partial second a smaller part of the total. D) Loop for a fixed number of times, logging starting and ending times (preferably in milliseconds or smaller). Dean P.S. I apologize for the late post. I'm once again way behind but couldn't resist this one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, December 13, 2004 2:32 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] LOOP or GOTO on READNEXT Allen E. Elwood [EMAIL PROTECTED] wrote on 13 Dec 2004 09:36:42 -0800 I didn't include the delete statement because what you really wanted to test was the LOOP/REPEAT vs. the GO construct. Guess what? After doing four consecutive runs and picking the fastest of each four, LOOP/REPEAT wins!! ... So does this end the GOTO holy war? Less Filling, Tastes Better, Goes Faster??? ;-) Ummm... no. Using UniData 6.0 on AIX 5.1 I tested a similar program with a tighter GOTO loop: 01: * Test Loop Speeds 02: * 03:CTR = 0 04:ETIME = TIME() + 5 05:LOOP WHILE TIME() ETIME DO 06: CTR += 1 07:REPEAT 08:PRINT While :CTR 09: * 10:CTR = 0 11:ETIME = TIME() + 5 12: 10 CTR += 1 13:IF TIME() ETIME THEN GOTO 10 14:PRINT Go To :CTR I also wrote a separate program with lines 2-9 above after line 14, so I could test if the order of execution made a difference. I ran each program four times, with the following results (W indicates Winner :-) -- Go To First - -- While First - Go To Count While Count Go To Count While Count --- --- --- --- 769730 W 752380667050 W 458545 655809 734709 W 747373 W 592827 576565 688953 W 785676 W 611628 629807 748265 W 714679 W 564908 The second loop for whatever reason seems to have an advantage. Overall, I suspect there isn't a lot of difference. --Tom Pellitieri Century Equipment --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] LOOP or GOTO on READNEXT
Hi Dean, While quibbling over nanoseconds, some of may have missed a little flaw in your tests that would have nothing to do with caching or memory allocation. Didn't actually miss that one. It is the reason why I ran my tests 4 times, figuring that the average of the four would be close enough to determine which is fastest (on a stand alone system with me as the only user, and not actually doing any file access, so that catching wouldn't be an issue either, and I ran my tests for 10 seconds to also minimize any fractional seconds impact) And I just did it for the fun of it. I *really* don't care if LOOP/REPEAT or GOTO is faster, I'll always still use loop constructs when the language supports it. btw, you missed a word between of and may. Don't you just hate it when that happens?!!? ;-) Allen --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] LOOP or GOTO on READNEXT
On Tue, 28 Dec 2004 19:30:37 -0500, you wrote: It is a silly argument... I just think about utilizing a goto or its facsmile within C++. C, C# (not that I ever did) and it would quickly garner a big red F in school... I don't know of any other language where it would even get beyond a snicker at the unpolished newbie... SNIP That's because the languages you refer to have a higher level of abstraction from the run machine than the ones that you're laughing at. Ever done any FTN, PL1, SPL or assembler programming? -- Allen Egerton [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] LOOP or GOTO on READNEXT
Goo'day, At 19:30 28/12/04 -0500, you wrote: It is a silly argument... I just think about utilizing a goto or its facsmile within C++. C, C# (not that I ever did) and it would quickly garner a big red F in school... Ah! But some of us were programming top down with GO's, JUMP's, what-have-you - quite productively and successfully - long before structured programming was foisted upon an unsuspecting public, and long before schools of any ilk, primary, secondary or tertiary, even knew a skerrick about programming per se. Most of the programming profession in those days, and it's well and truly within my lifetime, were taught their trade by hardware manufacturers. As a matter of small fact, top down programming was preached at me in my early Pick days (late 70's) to overcome frame faulting/ response time problems in MDD boxes with only 32K of memory and up to 8 users Be kind to your elders. I don't know of any other language where it would even get beyond a snicker at the unpolished newbie... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, December 28, 2004 5:27 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] LOOP or GOTO on READNEXT While quibbling over nanoseconds, some of may have missed a little flaw in your tests that would have nothing to do with caching or memory allocation. The elapsed time of each test could have been different enough that the differences in the counts would fall within that margin of error. This is particularly noticeable in Tom's test below. Using 'TIME() + some.number' to determine the stopping point could make the first iteration up to .999 seconds shorter than the second. When you're processing hundreds of thousands or millions of iterations per second, that fraction of a second could account for the differences. Using Tom's example below, if the system time was 1.999 at the start, then ETIME for the first pass would be 10005, resulting in 4.001 seconds of processing. The second pass would start around 10005.001 and ETIME would be 10010, resulting in 4.999 seconds of processing. When processing 600,000 iterations, that means a margin of error of 120,000. Hence the results are skewed toward the second loop. To get around this, you could: A) Use SYSTEM(12)(on UD) to get milliseconds or other function to get a more exact measurement of time to make margin of error smaller. B) Add some code at the beginning to ensure TIME() had just incremented to the next number before starting a loop. C) Loop for more than a few seconds to make the partial second a smaller part of the total. D) Loop for a fixed number of times, logging starting and ending times (preferably in milliseconds or smaller). Dean P.S. I apologize for the late post. I'm once again way behind but couldn't resist this one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, December 13, 2004 2:32 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] LOOP or GOTO on READNEXT Allen E. Elwood [EMAIL PROTECTED] wrote on 13 Dec 2004 09:36:42 -0800 I didn't include the delete statement because what you really wanted to test was the LOOP/REPEAT vs. the GO construct. Guess what? After doing four consecutive runs and picking the fastest of each four, LOOP/REPEAT wins!! ... So does this end the GOTO holy war? Less Filling, Tastes Better, Goes Faster??? ;-) Ummm... no. Using UniData 6.0 on AIX 5.1 I tested a similar program with a tighter GOTO loop: 01: * Test Loop Speeds 02: * 03:CTR = 0 04:ETIME = TIME() + 5 05:LOOP WHILE TIME() ETIME DO 06: CTR += 1 07:REPEAT 08:PRINT While :CTR 09: * 10:CTR = 0 11:ETIME = TIME() + 5 12: 10 CTR += 1 13:IF TIME() ETIME THEN GOTO 10 14:PRINT Go To :CTR I also wrote a separate program with lines 2-9 above after line 14, so I could test if the order of execution made a difference. I ran each program four times, with the following results (W indicates Winner :-) -- Go To First - -- While First - Go To Count While Count Go To Count While Count --- --- --- --- 769730 W 752380667050 W 458545 655809 734709 W 747373 W 592827 576565 688953 W 785676 W 611628 629807 748265 W 714679 W 564908 The second loop for whatever reason seems to have an advantage. Overall, I suspect there isn't a lot of difference. --Tom Pellitieri Century Equipment --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG
