I've seen that before too Steve 2009/1/12 Steve Onnis <[email protected]>
> > 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: [email protected] [mailto:[email protected]] On > Behalf > Of Barry Beattie > Sent: Monday, 12 January 2009 5:03 PM > To: [email protected] > 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 <[email protected]> > 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: [email protected] [mailto:[email protected]] On > Behalf > > Of Claude Raiola > > Sent: Monday, 12 January 2009 4:50 PM > > To: [email protected] > > 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: [email protected] [mailto:[email protected]] On > Behalf > > Of Barry Beattie > > Sent: Monday, 12 January 2009 11:29 AM > > To: [email protected] > > 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
