Whew! Yes, altering the table to have a default of blank for the AnyJob column 
fixed the problem. It really does look like a bogue, if you'll pardon my 
French. (That really is the French term for bug - no kidding. I'm not sure how 
they pronounce its vowel since up to now I've only seen it written.)

Peyton

P.S. As programmers with long experience with users' reports of bugs, your 
first impulse may be to doubt my account of this, but trust me. For record 
after record (maybe about 6 of them, to be honest, yesterday, then two more 
today), I went through the drill of adding the record, then trying to change a 
column in it via the grid, and getting the grid back with the change not made, 
while at the same time having made changes to records to which I had previously 
supplied a value for AnyJob via SQL Server, and finding that those changes were 
the only ones that went through successfully when I pressed the button which 
invokes <CFGRIDUPDATE> (namely by the code below when the page posts to itself

<cfif IsDefined('Form.gridUpdated')>
   <cfgridupdate grid="ReporterGrid" datasource="PostJobReports"
           tableName="Reporters">
</cfif>.

-----Original Message-----
>From: Peyton Todd <[EMAIL PROTECTED]>
>Sent: Apr 22, 2008 9:00 PM
>To: [email protected]
>Subject: [ACFUG Discuss] Possible bug in CFGRID? Or in SQL Server?
>
>Or just maybe a mistake of my own?
>
>The CFGRID I wrote to maintain the 'reporters' table mentioned in my notes of 
>yesterday and today has a wierd problem. It turns out that a one-byte column, 
>'AnyJob' (= 'Y' if the user allowed to see any job), must have data in it for 
>any updates to the row containing it to be saved by CFGRIDUPDATE. 
>
>The column is set for NULLS allowed in my MSSQL 2005, so it ought to be okay 
>not to specify a value for it. But I have found that, once I have added a 
>record, if I did not specify a value for the AnyJob column, I cannot add a 
>value to that column later, nor make a change to any other column. There are 
>other null-okay columns in the table, and they do not behave this way. 
>
>Has anyone ever encountered a problem like this?
>
>The present situation greatly diminishes the usefulness of CFGRID. It means, 
>for example, that if any reporter without the privilege to view any job is 
>granted that privilege later, the CFGRID cannot be used to specify that to the 
>system. The only way would be to go into Enterprise Manager and do it there. 
>In fact, that's the only way I was able to confirm this description of the 
>problem: for each record, one a time, I would go into Enterprise Manager and 
>enter a space in the AnyJob column, and for all records to which I have done 
>this, it becomes possible to perform updates via CFGRID from then on.
>
>Who knows - when I install my latest work (including the CFGRID) on the 
>clients server, maybe it will turn out that his MSSQL 2000 does not have the 
>same problem. 
>
>Or maybe (probably) MSSQL 2000 lets one specify a default value, which I can 
>decree to be a space? I'll check, but I want to get this message out right 
>away to see if it rings a bell with anyone...
>
>Peyton
>
>
>
>
>-------------------------------------------------------------
>Annual Sponsor FigLeaf Software - http://www.figleaf.com
>
>To unsubscribe from this list, manage your profile @ 
>http://www.acfug.org?fa=login.edituserform
>
>For more info, see http://www.acfug.org/mailinglists
>Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>List hosted by http://www.fusionlink.com
>-------------------------------------------------------------
>
>
>



-------------------------------------------------------------
Annual Sponsor FigLeaf Software - http://www.figleaf.com

To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------



Reply via email to