Derek,

When you were debuggin through that, which variable had a null reference?  That will help me reconstruct what's happening.  Thanks.

Ben

We tracked it down to how the variable DataSource._CanConnectDirectly is set to false with SetInternalExecuteReader and SetInternalExecuteScalar. The Enterprise DataSource sets both of these while the standard SqlDataSourceItem does not. So when we were wrapping the SqlDataSourceItem, when it got to this point:

        ''' 


        ''' Executes the given DbCommand with ExecuteReader with debugging.

        ''' 


        Protected Function InternalExecuteReader(ByVal Command As DbCommand, ByVal IsTransactional As Boolean, ByVal TransactionKey As String) As IDataReader

            If Me._InternalExecuteReader IsNot Nothing Then

                Return Me._InternalExecuteReader(Command, IsTransactional, TransactionKey)

            Else

                '-- Show the debugging window

                Me.DebugCommand(Command)



                '-- Make sure the connection is open

                If Command.Connection.State <> ConnectionState.Open Then

                    Command.Connection.Open()

                End If



                '-- Execute the command

                Return Command.ExecuteReader(CommandBehavior.CloseConnection)

            End If

        End Function

The _InternalExecuteReader was null and there was no way to set the DataSource._CanConnectDirectly property as it's only a get. We kind of have a hack to get around this, but we still need to test more. It seems that instead of having a single variable for both connections, you could just check the state of the connection.



Thanks

Derek, this should be working. So something must be out of sync someplace. There is really nothing different when querying directly or through ES with the exception of the ES data source being update to date. So the next thing I would do here is turn on debugging on the DataSource to see where it is failing. If you are update using CRUD settings (even if your are not) you should be able to see the UPDATE or INSERT statement coming across which may give a clue here.

Hmm...no, that should do it. Did you try to set the break points? This will quickly confirm that you actually have a key as and then if you actually have the data source set. Likely neither of these is the issue, but better to check 'em and know.

I did what you recommended, but according to the StrataFrame help for "Setting the SecurityDataSourceKey"

ms-its:C:\Program Files\MicroFour\StrataFrame\Documentation\SecurityHelp.chm::/SettingtheSecurityDataSourceKey.html



If the StrataFrame security tables are included within your application's database and the data source key for the database is the default of System.String.Empty (""), then the SecurityBasics.SecurityDataSourceKey does not need to be set because it defaults to an empty string ("").



This is our case. Is there another place to check?

Although you appear to be setting the key for the security data source, the error seems to indicate that the data source isn't actually setup. This might mean that the MyApp.SecurityDataSourceKey property hasn't been initialized (yet?) or that you haven't setup a data source using that key. I'd double check there first. Two break points, one were you set the security data source key and one in you click handler. Check that the MyApp.SecurityDataSourceKey property actually has a value and then make sure that the data source is actually setup (use watch window and a DataLayer.DataSources(MyApp.SecurityDataSourceKey) like call).

In our WinForms application, we are using role-based security. I can only save security changes via either the SecurityDialog or UserEditor when connected to our SQL Server 2008 database through Enterprise Server. If I connect to the same database without Enterprise Server it will result in an exception on saving:

MicroFour.StrataFrame.Business.BusinessLayerException: An error occurred while saving an the data to the server. ---> MicroFour.StrataFrame.Data.DataLayerSavingException: Object reference not set to an instance of an object. ---> System.NullReferenceException: Object reference not set to an instance of an object.

   at MicroFour.StrataFrame.Data.DbDataSourceItem.InternalExecuteReader(DbCommand Command, Boolean IsTransactional, String TransactionKey)

   at MicroFour.StrataFrame.Data.SqlDataSourceItem.UpdateRow(QueryInformation QueryInfo, DataRow RowToUpdate, ConcurrencyExceptionHandler ConcurrencyHandler, AddRowErrorHandler RowErrorHandler, Boolean RecreateCommand)

   at MicroFour.StrataFrame.Data.DbDataSourceItem.UpdateRow(QueryInformation QueryInfo, DataRow RowToUpdate, ConcurrencyExceptionHandler ConcurrencyHandler, AddRowErrorHandler RowErrorHandler)

   at MicroFour.StrataFrame.Data.DataLayer.UpdateDataTableThread(Object ThreadParams)

   --- End of inner exception stack trace ---

   at MicroFour.StrataFrame.Data.DataLayer.UpdateDataTable(DataTable TableToUpdate, Boolean Transactional, String TransactionKey)

   at MicroFour.StrataFrame.Data.DataLayer.SaveByForm(DataTable TableToSave, Boolean Transactional, String TransactionKey)

   at MicroFour.StrataFrame.Business.BusinessLayer.SaveByForm(Boolean Transactional, String TransactionKey)

   --- End of inner exception stack trace ---

   at MicroFour.StrataFrame.Business.BusinessLayer.SaveByForm(Boolean Transactional, String TransactionKey)

   at MicroFour.StrataFrame.UI.Windows.Forms.BaseForm.Save(Boolean Transactional, String TransactionKey)

   at MicroFour.StrataFrame.UI.Windows.Forms.BaseForm.Save()

   at MicroFour.StrataFrame.Security.UserEditor.cmdSave_Click(Object sender, EventArgs e)

   at System.Windows.Forms.Control.OnClick(EventArgs e)

   at System.Windows.Forms.Button.OnClick(EventArgs e)

   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)

   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

   at System.Windows.Forms.Control.WndProc(Message& m)

   at System.Windows.Forms.ButtonBase.WndProc(Message& m)

   at System.Windows.Forms.Button.WndProc(Message& m)

   at System.Windows.Forms.Control.ControlNativewindow.OnMessage(Message& m)

   at System.Windows.Forms.Control.ControlNativewindow.WndProc(Message& m)

   at System.Windows.Forms.Nativewindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)

   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)

   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)

   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)

   at System.Windows.Forms.Application.RunDialog(Form form)

   at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)

   at OHR.SYSTOC.WinForms.FileMain.MD.btnSecurity_Click(Object sender, EventArgs e) in c:\projects\SYSTOC.NET\MAIN\CODE\OHR.SYSTOC.WinForms.FileMain\Md.cs:line 45

We correctly set the key stuff here in Program.cs:

SecurityBasics.SecurityDataSourceKey = MyApp.SecurityDataSourceKey;

SFSPreferencesBO.RetrieveSecurityPreferences();

            

//-- Set the encryption key and vector for the user data

SecurityBasics.SetSecurityKeyAndVectorForUserAuthentication(MyCompany.MyApp.SecurityKey);

We also data deploy all the SFS* tables to this database in the DDT. Any ideas on why this may be happening?



Thanks,

Derek