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
-~----------~----~----~----~------~----~------~--~---

Reply via email to