healydj

Had a similar issue a few months back. Turned out 2B a problem with the firmware in the SCSI raid controller not being able to handle RAID 10. A firmware upgrade fixed the problem. Like U, we didn't get much help from the logs. Had a similar issue about eight yrs ago with an HP server on Novell 4.1. Check your HDD and controller vendor(s) for patches (and make sure your UPS is working B4 you apply them).

1) We have an old P133 (W98SE, IE6) that we use at home for browsing and EMail. Virus checker is BitDefender 9. 2) At work, we have OWA enabled for home users (W2003, Exchange 2003, Outlook 2003). Virus checker is McAfee Enterprise. 3) OWA worked fine from home until we set up a small Ethernet (3 PCs), based on a DLink G604T router. Afterwards, trying to send (or forward) anything via OWA resulted in: a) the Send button graying out; B) after a timeout, a one-word error message: Unknown. 4) We configured the DLink as a virtual SMTP server and re-booted. The problem went away. 5) Subsequently, we've had to re-configure the home network twice. The behaviour repeats; Send fails in WebMail until the P133 is configured as a virtual SMTP server. We know OWA only uses HTTP and HTTPs. We think the issue is at the home end; specifically, with the router's firewall, the A/V software or some combination of the two. Have you experienced a similar issue? If so, what was the fix? This has affected over a dozen users in our organisation since the start of the year, and we'd like to know what is going on. It is really bizarre to have to use a work-around involving SMTP, something OWA doesn't need, to fix this issue.

As you've stated the issue, there are three pieces: 1) A client will be making a set installment amount into an account each month. It appears they do this though an interface you've created. 2) From that account certain fees will be debited each month. It's unclear why this is relevant. 3) Automatically create a record for each scheduled installment amount. To achieve this: a. Use ADO in a module to create a command object whose ActiveConnection property connects to your DB. b. Attach parameters to the command object's Parameters collection. c. Assign values to these parameter objects, based on values from your user interface. d. Execute an INSERT against the relevant table in your DB, populating the relevant columns with values from the Parameters collection.

While you're waiting for your copy of Curland, here are a couple of points he makes that might be relevant: 1) On page 22 - 23, he discusses issues with arrays declared at module level. Apparently there are issues re "unwanted memory destruction". One of the work-arounds is to lob your arrays into class modules. Per Curland: "Always clear the array variable in your Class_Terminate, calling Erase to free referenced pointer types if needed." A module, by definition, does not have a Terminate event. 2) On page 149, he points out a problem that will drive you nuts if you're unaware of what's going on. "If you use a CopyMemory call declared in VB, any string parameters undergo UNICODE/ANSI translation during the API call." If you're referencing structures in your code, this one will bite you - hard! Curland's VBoost component has its own methodology for copying memory. It's unfortunate the book was published just as .NET was taking centre stage, and thus never received the accolades it surely would have garnered had VB6 remained Microsoft's flagship. The book is the magnum opus of a genius, and contains much wisdom that pertains to coders in any language.

Get a copy of Matthew Curland's Advanced Visual Basic 6. His VBoost component sounds like what you need. It's a free download from his web site for owners of the book. Getting any support from Microsoft for VB6 is a daunting task these days. Curland worked for them, and wrote quite a bit for the VB Programmers' Journal pre-.NET. If you are going to mess with CopyMemory, this book is a must-have. On pages 8-9, Curland notes: "Be incredibly wary of the IDE's Stop button and the End statement in code....An abrupt End to a program bypasses most termination code, potentially leaving VB in a bad state. You won't always crash if you hit the Stop button, but you will crash often enough that you'll stop doing it. Turning off Compile on Demand in the General tab of the Tools/Options dialog will minimize the need to push the Stop button."