|
| | | StrataFrame Novice
 
Group: StrataFrame Users
Last Login: 11/19/2008 3:34:49 PM
Posts: 96, Visits: 886 |
| Any help will be appreciated.
MS Windows XP SP3
AMD Athlon 64 Processor 3000+
3,2 GB RAM, Radeon X1600/x1650 Series |
| |
| | | 
Advanced StrataFrame User
Group: StrataFrame Users
Last Login: Yesterday @ 8:41:37 PM
Posts: 798, Visits: 11,595 |
| | Hi Guillermo. I haven't tried this yet, but wouldn't think it is a problem. The SF developers will certainly point you in the right direction as soon as they get back next week, I'm sure. Abraços. |
| |
| | | StrataFrame Novice
Group: StrataFrame Users
Last Login: 11/19/2008 3:34:49 PM
Posts: 96, Visits: 886 |
| Thanks Ivan
I can't wait to them to begin answering all my questions  What it is true is that I already begun to modify the module for Oracle since I don't believe it's fully supported from the test application I've working.
MS Windows XP SP3
AMD Athlon 64 Processor 3000+
3,2 GB RAM, Radeon X1600/x1650 Series |
| |
| | |
Advanced StrataFrame User
Group: StrataFrame Users
Last Login: Yesterday @ 8:41:37 PM
Posts: 798, Visits: 11,595 |
| | I see. But tell me something ... what module are you modifying? Are you making changes to the source code? If so, keep in mind that this might get you in a difficult position when they, in the future, make any changes to the source, so you would probably loose your changes once upgraded. |
| |
| | | StrataFrame Novice
Group: StrataFrame Users
Last Login: 11/19/2008 3:34:49 PM
Posts: 96, Visits: 886 |
| Yes, I'm aware of that, this is going to be like "Customers doing employee work", I will wait to see what news are coming after holidays.
MS Windows XP SP3
AMD Athlon 64 Processor 3000+
3,2 GB RAM, Radeon X1600/x1650 Series |
| |
| | | 
StrataFrame Developer
Group: StrataFrame Developers
Last Login: 10/21/2008 9:20:58 AM
Posts: 2,685, Visits: 1,887 |
| The security module is designed to work with SQL Server 2005, and once the auditing becomes available, it will be SQL Server 2005 only. So, it would probably be the easiest to have a SQL Server 2005 Express db somewhere that has your security tables and use Oracle for your application itself. However, if you have a huge aversion to SQL Server (being an Oracle guy, I'm just saying...  ), you could modify the security module to work with Oracle. You would need to create the tables and views in Oracle and then modify business objects within the SF Security source code and specify the sequences the business objects should use for their primary keys. As long as you get all of the data types matched up, you should be good to go. So, Oracle isn't technically "supported" by the security module, but if you run into any problems once you change the business objects, then let me know and I'm sure I'll be able to come up with something.
www.bungie.net |
| |
| | | StrataFrame Novice
Group: StrataFrame Users
Last Login: 11/19/2008 3:34:49 PM
Posts: 96, Visits: 886 |
| Thanks Ben
The Oracle issue came with my client constraint as this is the database they have. So I Think I will follow the first approach you gave me to handle security within the project.
MS Windows XP SP3
AMD Athlon 64 Processor 3000+
3,2 GB RAM, Radeon X1600/x1650 Series |
| |
| | |
StrataFrame Developer
Group: StrataFrame Developers
Last Login: 10/21/2008 9:20:58 AM
Posts: 2,685, Visits: 1,887 |
| Yeah, I think it would be the easiest way to implement security. You'll just have to make sure you add both data sources (one for the security connection string to SQL Server, and one for the Oracle connection string). I would recommend leaving the Oracle data source as the default data source (by specifying a data source key of an empty string [""]) and set the data source key for the security data source to something else, like "SecurityDataSourceKey". You'll then need to set the MicroFour.StrataFrame.Security.SecurityBasics.SecurityDataSourceKey property to "SecurityDataSourceKey" to tell SF that the security tables are not in the main database, but to use the other connection string to reach them.
www.bungie.net |
| |
|
|