home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.databases.paradox      To crash or not to crash, asks Borland      9,834 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 9,390 of 9,834   
   Al Breveleri to modri dirkac   
   Re: Overview of Paradox database structu   
   06 Aug 08 08:47:44   
   
   From: grinning.ducking@running.away.very.very.fast   
      
   What an application!  You are correct to be proud of it.   
      
   But when are you going to upgrade it to MS Access?   
      
   -Al.   
      
   "modri dirkac"  wrote:   
   >> I understand the idea of the INI files - but always prefer to use tables   
      
   >> for lists if possible...   
   >Hmmm, first programer, that started this application some 15 years ago,   
   >did it with INI files, and since then we got used to it. Can change reports   
      
   >and   
   >program behavior on site, with notepad, or even over phone.   
   >   
   >> You have about 500 customers (I wish!) but how do you handle the   
   >> multiplicity of customers and reports and libraries?   
   >Special customer reports are all stored in a folder with customers name,   
      
   >there   
   >is usually also a redame file, but in most cases those are just reports   
   with   
   >some logo graphic on it.   
   >> Why not just add a method to a report library (I have 3, for about 250   
      
   >> reports, some of which are really just slight rehashes of some basic   
   >> report - same data, different layout)?   
   >Because that would be changin my standard application code.   
   >And if I change any of standard objects, I have to distribute this to   
   >all my customers. So I prefer just creating/editing a library in customers   
      
   >folder   
   >and in this lib I call my standard methods, then maybe do something with   
      
   >answer   
   >and finally call customers report.   
   >   
   >> I found using the long form was a pain, in that if you change the   
   >> parameters for a method, you have to chase down all the objects that use   
      
   >> the method. Have you found some problem with the short form?   
   >1. You must have all lsl files when you compile an object with short uses   
      
   >statment.   
   >On my developement setup, I have ALL objects in ?dl files. And if I have   
   to   
   >make changes to any of them, I get ?sl version from our "archive" drive.   
   >So at the end I know exactly which objects I have changed.   
   >2. so when I change parameters of method I am forced to   
   >hunt down all objects that use this method. But usually I do not have to   
   do   
   >this,   
   >because I do not change methods that are used by other objects, I usually   
      
   >change   
   >just methods that are used inside a form/library.   
   >But when I do change some widely used method (add some funcitonality) I   
      
   >create   
   >new method with new name and new parameters and change old method so   
   >it calls new method and adds new parameters with blank value.   
   >   
   >So if the method is like:   
   >method CutToSize(s string, len smallint) string   
   >  if s.size() > len then return(s.SubStr(1,len)) else return(s) endIf   
   >endMethod   
   >   
   >and I want to add aligning to right then I would create new method   
   >method CutToSizeAndAllign(s string, len smallint, right true) string   
   >  if s.size() > len then s = s.SubStr(1,len) endIf   
   >  if right then s=fill(" ",len-s.size())+s   
   >  endIf   
   >  return(s)   
   >endMethod   
   >   
   >and change old method to call new method but still keep its original   
   >behaviour:   
   >method CutToSize(s string, len smallint) string   
   >  return(CutToSizeAndAllign(s,len,false))   
   >endMethod   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca