I rebuilt the security database using the DDT, added the security user and password, made the user a dbo, successfully launched the security maintenance form, tried to add a new user and viola ... there appears to be a Japanese Beetle in the rose garden.  Did I miss a step when deploying the security database?

Charles T. Blankenship
Senior Consultant
Novant Consulting, Inc.
704.975.7152
http://www.novantconsulting.com

Finally, the (ByVal text As String) parameter contains "nothing" ... if I power past the error by pressing the continue button in the debugger I get the new user dialog ... providing the information and pressing the save button results in a successfully saved user.  Then, loggin in as that user results in a successful login.  Once the first record is added then I can enter wrong passwords all day long under the beautiful North Carolina sun in a rose garden!  (And, at the risk of rambling again, it is actually the North Carolina moon but that is a mere technicality and not very germane to the conversation I suppose)

However, trying to add the second new user results in the exact same problem.  As noted before, the database is a pristine one generated from the DDT process.

Thanks guys,

CT

Charles T. Blankenship
Senior Consultant
Novant Consulting, Inc.
704.975.7152
http://www.novantconsulting.com

Does the same problem occur with the Security Sample that comes with the framework?  This has the sound of data related...so though there may be a Japanese beetle in teh mix...I don't think it is necessary RBS code related...we may have to dig a little deeper to see where the issue is manifesting itself.  Since you have the source code, you might step through further up the call stack than the Decrypt to see if you can gather a clue as to why the data is coming is as Null.  That is obviously pretty suspicious...so that is where I would start.

Right o, I'll check that out when I get home tonight.  I'll trace through the code base as well.  The reason I jumped the gun on the report was due to the nature of my attempt to recreate the problem, which was to start with a clean installation of the security database (using DDT to deploy), add the proper user to SQL Server, make the user dbo (to prevent any permissions issues creaping in), launch the security dialog, make changes to the preferences (successful), then try and add a new user.

I'll give a more detailed report tonight.

Wow, it's getting pretty pumpkiny in this thread ...

Charles T. Blankenship
Senior Consultant
Novant Consulting, Inc.
704.975.7152
http://www.novantconsulting.com

With a sprinkle of stars

OK ... I did as instructed and was able to create a windows application from scratch, using a separate database, log into the application as the security administrator, add a new user (without error I might add), log out and log back into the application using the newly added users credentials.  Basically, something, not SF code, is wrong with my main application since this test one works like a CHAMP ... dang it.

I guess I'm now enjoying starlight in the pumpkin patch ... you know what's commin' ... since my name is Charles ... yep ... Charlie B. (me) is waiting on the Great Pumpkin!  Weird how this worked out ... from sunshine and roses to All Hallows Eve.

Notice:

Attached to this message is a 15 page word document that takes a user, step by step, through the entire process of creating a windows application that has security enabled where the security tables are located in a separate database from the application database.  I figured if I had to go through these steps to either prove or disprove the presence of a bug in StrataFrame, that others new to the framework would benefit greatly from a step by step tutorial describing how to do it.

Charles T. Blankenship
Senior Consultant
Novant Consulting, Inc.
704.975.7152
http://www.novantconsulting.com

Cool...be sure to post this on the user contributed samples as well!  Thanks!