Right, I have often used recursive iteration - some of the older apps where I have to impliment in a hurry I get lazy with ::i or ::j fields. I also understand the need for a panel sheerly for processing transaction logs - that then become the source for other data / reports. Right at the part where it starts becoming work, I start thinking - gee. I could be doing this with mysql, and it really puts a damper on my enthusiasm...... Best to you Brian...
From: [email protected] To: [email protected] Date: Thu, 16 Sep 2010 09:49:00 +1000 Subject: Re: [Dataperf] DataPerfect limitations/suggestions Hi Chris One thing that I find really attractive, is using DP as a hybrid application, with some users using “normal” DP and other accessing it through a web browser or other application such as Word or Excel or a evan a VoIP PBX application. An existing DP application is a great candidate for refactoring into a hybrid application because with generally no change in the way the majority of users have been using the application you can gradually add the additional functionality. The main hurdle with converting existing application is that ::I incrementing number fields are problematic. The issue is solved with Ralph Alvy’s algorithm for using a recursive link for incremental numbering. The main disadvantage with DP is that the program code (ie the STR) also is the repository for the next number to use for incrementing with an ::I field. Therefore if you take the STR away for maintenance, eg adding a new report, when you copy it back you bring back the old next incrementing number. Using Ralph Alvy’s algorithm solves this. It is actually a good practice to implement this for any DP application with incrementing numbers as it means you can do some tasks on the STR, which can be made offline, eg reports, calculation fields, lookup field lists, tab order etc etc, without having to take the database offline. But note, you cannot take an STR offline if you make any changes to a panel’s field or indexes, as they restructure other files. Therefore I suggest that even if you are not yet web enabling an application that you should write it using the Ralph Alvy Recursive link method. (Actually this method for incrementing numbers is far more versatlile, as you arr not limited to incrementing by 1, with adaptation you can use incrementing alpha, but the trick I like best is that you can embody a check digit into number which might be used as an identifier) The other thing I do in preparation for web enabling when I start an application, is to create a panel which is populated with one record and one record only (easy to enforce with a One field, id a field with an Intial value of 1, used as the only field in an index). This panel is not going to be used for real application data. This panel is used as the basis of ALL web enabled reports, or infact any report can be handled this way, so this is another good practice for new databases and reports. Regards Brian From: [email protected] [mailto:[email protected]] On Behalf Of Chris Pedersen Sent: Thursday, 16 September 2010 1:01 AM To: [email protected] Subject: Re: [Dataperf] DataPerfect limitations/suggestions Well I think the last time I did this was before the kit Brian. I remember getting the appache server running - and perl/php...Got a few form/dp interactions to work.... But I am looking at this for a plant floor application - and its interesting again. Chris From: [email protected] To: [email protected] Date: Wed, 15 Sep 2010 16:03:02 +1000 Subject: Re: [Dataperf] DataPerfect limitations/suggestions Hi Chris, I hope that if you installed the kit I suggested and ran the example that the mountain would be more of a mole hill. Good luck Brian From: [email protected] [mailto:[email protected]] On Behalf Of Chris Pedersen Sent: Wednesday, 15 September 2010 12:56 PM To: [email protected] Subject: Re: [Dataperf] DataPerfect limitations/suggestions I keep meaning to do this.... I get about half way.. .. never get over the mountain.. still thank you again.... Once again it looks *real* cool. Thank you again Brian. Chris From: [email protected] To: [email protected] Date: Wed, 15 Sep 2010 11:09:18 +1000 Subject: Re: [Dataperf] DataPerfect limitations/suggestions Hi Chris, If you web enable DP, you can create queries from Excel. Either as HTML tables or as XML documents. You can readily web enable DP on a local machine, it is the easiest way. Excel can be arranged to poll DP either on opening or through timers, to get near real time data. DP not being event driven cannot “push” data back to a client, you cannot make a persistent connection. The sample tutorial at http://www.brileigh.com/dpweb/tutorial/ includes everything you need to get started on a Windows machine, showing installs, sample databases, script libraries, and details on how it all hangs together. If you do not want the Apache server to be running on the same machine you can map a drive and access the data. It really is not such a big deal, once you get your head around the basics. Web enabling DP really does unshackle you from many of its limitations, but still keeping the ease and reliability. I have had web applications now running for 5 years without a glitch, and zero unplanned downtime. Planned downtime has been the few minutes needed to upload new functionality, changes to reports, new and changed panels, etc. In fact probably less downtime is needed than say most “normal” DP applications, because you write it differently so that the STR for small mods such as reports be made offline, and the STR can be quickly copied over. My last web application was populating a PDF enrolment form, with dynamic data to and from DP. The DP part took negligible time, and it served thousands of users over a few days, again without a glitch. Bye Brian From: [email protected] [mailto:[email protected]] On Behalf Of Chris Pedersen Sent: Wednesday, 15 September 2010 8:02 AM To: [email protected] Subject: [Dataperf] DataPerfect limitations/suggestions 1. DP has a txx file limitation call it of 500Mb (not exactly right, but close). Can this be increased - I've got a couple of apps sitting at 300M+ 2. DP doesn't work if you print records that are too wide. Something like 255 characters is the limit. And it doesn't fail gracefully.. 3. I'm not at all up to speed on this question: DP used to be able to exchange information via the DP shell. Could a wrapper be written to allow dp to think it was working inside the dp shell, while to the outside world appearing as a dCOM object (or whatever microsoft is calling it today.). Basically, have dp drive real time updates to an excell spread sheet for example, or an acad dwg. Date: Tue, 7 Sep 2010 09:50:43 +0200 From: [email protected] To: [email protected] Subject: Re: [Dataperf] Christchurch Earthquake Charles . . . Colin is in the door business. Buildings needing to be rebuilt, repaired and etc. can only be good for business assuming his factory wasnt badly hurt which it doesnt sound like it was. Don 2010/9/7 Charles G. Wolf <[email protected]> Hi Colin, Good to hear from you. How is your home and business? Charlie Colin Roberts wrote: Hi Charlie, Don, Brian and All, Thanks for your concern - Annaleys and I just got back late last night from a relaxing cruise and a few days in Singapore - so missed all the action - but all family is safe and sound here. Brian and Don summed it up pretty well, its infrastructure and services that is going to take sometime to get sorted. Our earthquake building code is pretty stringent but there are still many buildings which were built before those requirements were brought in. We spent over $80,000 just on the foundations of our beach property north of Auckland to meet the current requirements three years ago. A lot of money to pour into the ground for a once in a lifetime event, but in times like this, one does re-assess the value of doing so. I think the buildings suffering major structural damage would have not been a surprise to the engineers currently accessing the damage in the Christchurch area. Those ones built to the new codes, I believe, have little if any damage. Still it is remarkable that there wasn't loss of life. Timing is everything. At 4.30am the streets were pretty much deserted but there were a few close calls with falling chimneys and roofs etc collapsing inward into bedroom and living areas of homes. Regards Colin RobertsAucklandNZ ----- Original Message ----- From: "Charles G. Wolf" <[email protected]>To: "DataPerfect Users Discussion Group" <[email protected]>Sent: Sunday, September 05, 2010 4:10 AMSubject: [Dataperf] Colin Roberts Hi Everyone, Has anyone heard from or about Colin Roberts? He lives in New Zealand, and I think it may be Christchurch. As you may have heard, yesterday, they had a 7.0 earthquake. The news says no one has died, which is encouraging. Colin organized our last DP conference in 2004. Charlie Wolf __________ Information from ESET NOD32 Antivirus, version of virus signature database 5414 (20100901) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------------------------------------------------------------------------- _______________________________________________Dataperf mailing [email protected]http://lists.dataperfect.nl/mailman/listinfo/dataperf __________ Information from ESET NOD32 Antivirus, version of virus signature database 5414 (20100901) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _______________________________________________Dataperf mailing [email protected]http://lists.dataperfect.nl/mailman/listinfo/dataperf _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf -- Don Friedman ProfessionalRecords.Com LLC PRS Data Systems 205 S Main Street Pittsburgh, PA 15215 412-784-1600 - 1-800-PRS-FILE 412-784-1615 Fax _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf
