> re: 5MB+ exe. What you describe is supposedly the case but > I don't believe it. Look at your app run in a memory analysis > program and you'll see a lot of memory allocated up front when > the exe loads. When you load a form, there is virtually no > change in allocated memory. I have put my db access components > on the forms that they load with in the hopes that they won't > load unless that form is loading. If that were the case, I'd > be seeing a lot more memory allocated when that form loads.. > With packages, there is no possibility of this happening. I > am hoping to see that when I start testing more fully with > a package version.
Do you know what happens when you application starts? Delphi starts reserving about one MB for it's heap immediately. Then all components just start initializing and it doesn't matter if they are in packages or not, more memory will be claimed for this initialization and Delphi does take large chunks of memory for this. You could replace the Memory Manager of course, to keep this memory usage low. But that would slow down the development time and Delphi is all about RAPID software development. If you want small Delphi applications then start looking on the Internet for the KOL objects. This is a special Delphi library that allows you to keep your whole application below 200 KB without even having to use packages or other DLL's. But it's not like the VCL and takes more time to develop software with. > It is true that packages will be a larger deployment but > the advantages for my intended app far outweigh the > disadvantages. I could not put all my functionality into > one large exe, it's just not feasible. If you want to split up functionality in your application, it is just easier to add all GUI elements in your main executable and all processing of data in separate DLL's instead. These could be simple DLL's but you could also use COM/DCOM or COM+ component DLL's instead. Those DLL's would have the logic to communicate with the database of your choice and your executable only communicates with these DLL's and all it gets are simple datasets and never a direct connection to the database. If you use COM+ then you can even let your application run over multiple systems. You would have one database system with the database, one middle-tier system that connects to this database and as many clients as you like connecting to this middle-tier. Data can be send between client and middle-tier through XML, for example. (Plenty of other options, though.) Other complex calculations that you want to keep out of your main executable? Put them in separate DLL's too. Need some email handling? Create a separate DLL that uses the Indy components to read or write those emails. The client doesn't even need to have those components installed. It just needs to be able to communicate with the DLL. > re: introducing bugs. Being an application developer, > I'd better have some faith in my abilities or what good > am I? Of course I might introduce bugs.. that is what > the debugging process is for. It doesn't just reduce > exe size but memory requirements as well. This is a > prime consideration for me as my apps are destined > for the commercial market, not in-house usage. Hey, I know I am a good developer too. My dad has been teaching me Delphi for about 6 years now and as you might have noticed, I'm certainly not an experienced Delphi user, no matter how young I am. But one thing my dad taught me too was that I would ALWAYS make mistakes, no matter how good I am. He does too. It's just normal human nature to make errors. And while debugging might allow you to find your own bugs, my dad also taught me that a developer who doesn't let his software tested by someone else is a very bad developer. Simply because some errors will completely blind you. You'll never notice them until someone else does, simply because you forget to test one step while the other person does. Debug your own code for as long as you like, but it will never be flawless. Some bugs will only occur under special circumstances and you might forget those circumstances... > My problem with Access is that it just doesn't seem very > well designed. Maintenance by the user becomes a large issue > or unreliability of the product is sure to ensue.. just my > experience with it. True. Access doesn't seem to be well-designed. But this is true for so many applications and even other components. My dad was very fond of WordPerfect in the past. And he saw it change from WordPerfect Office to Novell Office, to Borland Office and finally to Corel Office. And with every change of name, this product just got worse and worse. About two decades ago, WP ruled and Word was nothing. Now WP is history and everyone use Word. Not because it's well-designed but because it has become a well-established standard. I have the same feeling about Paradox. It used to be a very powerful database format, performing well compared to the competition back then. But Paradox tends to damage it's own indices once in a while, requiring a complete rebuilt of those indices. And Paradox didn't work well in a multi-user environment where several users would access the database at the same time. For example, a record could be blocked because it shares a table segment with another record and that other record happened to be locked. And of course Paradox has plenty of other minor quirks. Won't deny that Access also has it's flaws, though. But Paradox is a dying product while Access is still kept alive by MS. Maintaining a database will always be a problem for the user anyway. As developer you just have to provide the user the proper tools to fix the database. But if the user doesn't need to store a huge amount of data, simple databases like Access or Paradox will perform quite well. And Access does seem to be more reliable in a multi-user environment in my opinion. With kinds regards, X Katja Bergman. ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
