I would first like to thank you all so very much for taking the time to help me. This was a real crisis for me, as I have put months of work into my first attempt at real software architecture and design and I am really passionate about what I have created. I was killing me to have to just watch it go down the drain like that.
The wonderful news is that thanks to all your help, I think the problem is almost solved!!! What I did was I placed all of the code onto the J: drive - a drive that is accessible to all users. I then created a setup package and asked my boss to install it and it worked!!! I then deleted the files from the J: drive and it still runs perfectly, so it is obviously not referencing anything on the J: drive. I am not really sure exactly why that solved the problem, because there were so many factors that could have influenced it. They happened to reboot the server for an unrelated reason, which was fortunate! It could have been that there was a problem with the registering of the DLL's on the server and so installing it from a new location could have solved the problem. I would like to get to the bottom of what it could have been, so if anyone has any ideas, I would be most grateful, as I need to get to the bottom of this so that we don't experience the same problem when we install the software again as this was only an interim build. I may still have to justify using 5 DLL's instead of one EXE. I am now realising how many problems can occur when you have multiple DLL's but I believe that it is still the best way to go for maintainability and scalability and of course code re-use. Do any of you have any thoughts on this? Thank you all once again! I unfortunately have no contact with other software developers and so I really appreciate being a part of this listserv. I will look for opportunities to help others on this listserv wherever I can! --- In [email protected], "Ian Brooke" <[EMAIL PROTECTED]> wrote: > Mandy, > A very common mistake is to assume that your app has access rights to app.path - it is often the case that when an app is installed on a server then the user has no write or create rights to files within that folder and you then have 2 choices.... > 1. If there are user-only files (ie non-shared) that the program uses (writes to) and/or creates, then create a folder under that user's application data folder (where they MUST have rights) - get the path to this from environ("appdata"). > 2. For shared files, have the server admin create a separate folder to which users have write access and put the files in there. Have a read-only ini file (much more convenient than the over-rated registry) in app.path which contains pointers to these files. > > I had serious problems with some virus checkers, particularly McAffee which totally screwed up an app and app.path wasn't working properly at all - eventually I had to switch it off during installation and everything went fine after. > > However, it doesn't sound like either of these would be affecting your app. You say that "the fifth class can not reference a class in the fourth DLL" but you don't seem to say what happens? When exactly does it fail and what error do you get? > > If this is a registered dll (ie an activex) then it should make no difference running in the ide or as an exe, as long as the app and each dll are using early binding to reference the dll's. If you are using late binding then I assume that you've checked each and every dll reference to ensure it is correct and applicable to the server but I'd always try to use early binding which seems much less error prone. This is especially true if you are relying on a search order to find an unregistered dll (which I don't think you are). > > Write a small application that just tries to access dll 4 and 5 separately, if necessary put an extra public function in each that will respond with a known reply - you can then check that your app is picking up each dll correctly. If it can see both 4 & 5 then the problem is in the 4-5 interface rather than the setup on the machine, this at least narrows down the investigation. > > If all else fails, combine 4 & 5 into a single dll - it's easier and perhaps less stressful than undoing all your other good design and easy to re-implement if you find a solution in the future. > > Ian > > > > ----- Original Message ----- > From: HouseDad > To: [email protected] > Sent: Friday, February 25, 2005 9:27 AM > Subject: [vbhelp] Re: DLL's - VB 6 > > > > --- In [email protected], "mandy_vb6" <[EMAIL PROTECTED]> wrote: > > > > Could I ask just one more question? Am I right in saying that > there > > can be nothing wrong with my code if the application works > perfectly > > in VB runtime and that the problem must be with the way it is > > registering DLL's on the server? Thanks again! > > Hi Mandy, > > I don't know if this will help but I have had some similar > problems with W2K on a network. For users without Admin access to > run the programs I have to jump through some hoops and even then > there's no guarantee it will work. For my particular problem, > logging on with Admin access seems to fix the problem. > > I don't know if this is in any way related to your problem, but > perhaps there's something along the sames lines that you may need to > consider. > > If your application runs ok at runtime, does that mean the > compiled program, or just in the IDE? > > Good luck! > > [C] > > > > > > > > '// ======================================================= > Rules : http://ReliableAnswers.com/List/Rules.asp > Home : http://groups.yahoo.com/group/vbHelp/ > ======================================================= > Post : [email protected] > Join : [EMAIL PROTECTED] > Leave : [EMAIL PROTECTED] > '// ======================================================= > > > > Yahoo! Groups Sponsor > ADVERTISEMENT > > > > > > -------------------------------------------------------------------- ---------- > Yahoo! Groups Links > > a.. To visit your group on the web, go to: > http://groups.yahoo.com/group/vbhelp/ > > b.. To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > > [Non-text portions of this message have been removed] '// ======================================================= Rules : http://ReliableAnswers.com/List/Rules.asp Home : http://groups.yahoo.com/group/vbHelp/ ======================================================= Post : [email protected] Join : [EMAIL PROTECTED] Leave : [EMAIL PROTECTED] '// ======================================================= Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/vbhelp/ <*> 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/
