I think it might have something to do with the locking of the cfmail file when it gets sent and then cf tried to delete the file but cant and ends up with an empty file sitting in the que
-----Original Message----- From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of Barry Beattie Sent: Monday, 12 January 2009 5:03 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: CF5 Cfmail locking up Steve I've seen that happen (to other ppl, thankfully)... ... any clue how/why it happens? On Mon, Jan 12, 2009 at 3:52 PM, Steve Onnis <st...@cfcentral.com.au> wrote: > > Check for zero byte files in the mail spool. CFMAIL seems to get stuck if > there are files with nothing in them in the spool directory > > -----Original Message----- > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf > Of Claude Raiola > Sent: Monday, 12 January 2009 4:50 PM > To: cfaussie@googlegroups.com > Subject: [cfaussie] CF5 Cfmail locking up > > > My client is running CF5 (yes I know upgrade is needed) and since 1-1-09 the > cfmail server has been locking up > > Their application has many many functions that generate email notifications > to nominated email addresses. > The scripts run as normal without crashing however the email are not > received by the recipients often the recipients are other staff in the same > office. > > When the all the CF services are restarted on the server all the mail that > have been processed by cfmail yet not received is then received all at once, > staff receiving 5-10 emails that they were expecting to have received during > the previous several hours all at once. > > Note that all I do to have the emails sent ti re start the cf services on > the server I do not reboot the entire server and exchange server is running > and sending receiving emails without an issue. > > Does CF5 admin have a activity error log I can view to try and determine > what is causing the emails to lock up as described above. > > > > Regards > > Claude Raiola > B.Econ (Acc), B.Hot.Mngt. > > Websites: > www.AustralianAccommodation.com > www.SAMARIS.NET > www.WebSiteSolutions.com.au > Mobile: 0414 228 948 > > -----Original Message----- > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf > Of Barry Beattie > Sent: Monday, 12 January 2009 11:29 AM > To: cfaussie@googlegroups.com > Subject: [cfaussie] Re: Using stored procedure exclusively to control > database access > > > I know ppl sometimes use databases for just basic data storage but > business logic in a database is a very valid process, especially if > inserts, updates and deletes involve triggers of related data. > > having said that, it's something I don't need to do all that often, > and usually reserve for specialist uses. One problem is that (esp with > triggers) the logic is somewhat hidden. > > but to be honest, the process should be abstracted anyway. something > should "doSomething(data)" and how it's implemented shouldn't be cared > by the calling code. Whether it's descrete SQL, a sproc or writing to > a file. > > what that means is that you really need a data access layer and get > away with SQL littered all through your code. _ALL_ SQL should be a > specific layer of your code and everything calls what they need. > > : KISS - keep it simple > : DRY - don't repeat yourself (ie: write code once and call it many times) > two things to follow to make your life easier > > just my 2c. > barry.b > > > > > > > > On Mon, Jan 12, 2009 at 11:19 AM, felixt <cem...@gmail.com> wrote: >> >> Hi all, >> >> It has been suggested by someone at work that we should only allow >> access to database via stored procedures. >> >> This was proposed to fix the current situation where we have hundreds >> of similar SQL statements scattered >> around the system. For example if the business logic has changed in >> one place that affects a table, one needs to do a keyword search on >> all files to make sure all the related files are updated. >> >> I am aware of the benefits of going the stored procs way, like: >> 1. Centralized place for logic >> 2. Faster execution >> 3. It's very unlikely that we will go with different database system >> other than MSSQL so portability is not an issue for us. >> >> But I feel a bit uneasy about this, I don't feel business logic should >> be in the database also I think debugging stored procedure will be >> more difficult (adding one more place to check). >> But this is just my feel, I might be wrong. >> >> Any thoughts, is this a normal/recommended practice? Also what are the >> best practices that you guys use to combat this scattered SQL >> statements? >> I thought of using CFCs (gateways and/or DAOs) should be sufficient: >> CFM -> CFC -> query >> rather than: >> CFM -> CFC -> stored proc >> >> Cheers, >> >> Felix >> > >> > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
