Back in 2008 I remember running into a 3rd party tool that did 99.9% of the work of implementing task/role security. From what I recall it was simply an extension of what was built into .Net. You ran a script to add all the needed tables to your SQL Server then used the UI to go in and define all the tasks and then grouped the tasks into roles. The assigned users to a role. The power was that different roles could have the same task and it was all configured by the UI tool that came with this system. I also thought it was on CodePlex, but I don't recall the name. All I recall it was Microsoft's name with like Sql or something added to the name of it.
At the time, 2008 (VS2008 days), I was told by co-workers that Microsoft was slowing consuming the whole system into .net.
Anyone have any idea what the name of the thing was I am thinking of? Is it part of Microsoft .Net now?
Are you perhaps thinking of NetSqlAzMan, which uses a similar authorization model to Microsoft AzMan? Or perhaps you're thinking of AzMan itself, which has a UI and allows storage in SQL Server?
Related
I am creating a application which is mainly used inside a office for data maintenance. It will be used to store data like work list, future works, reminders etc .All data will be presented to user in the form of grids. So it's all about data stored in SQL server database. There will be number of users accessing it and they modify data frequently. Also there will be so many options like an ERP program.There is no connection to internet is required for this program.
So in this case which programming language is better? Should I choose WinForms or ASP.NET? The main concentration to choose between this will be performance, ease of use, also it should support more function for grid controls etc. So which one should I choose? And what will be the advantage and disadvantage of both?
Some pointers:
WinForms
Good
No webserver to install, setup and secure
Bad
Installation of some kind required on each machine e.g .NET framwork, exe, assemblies, etc.
More difficult to rollout updates to the application
ASP.NET
Good
No installation on clients required
Can run on machines other than windows including mobile devices
Updates to the application can be published instantly to all clients
Bad
Have to use IIS or UltiDev Web Server to serve up pages
File system is more secure so reading and writing to files can be time consuming to configure
Unless you want to use jQuery and Javascript to add additional functionality to the Standard ASP.NET GridView I would say a Windows Form would be more suited, depending on the size of the data it will most likely offer better performance and you have much more control over the actual functionality of the program, rather than dealing with browser related restraints.
Not really a question for this forum... VB.Net is a Language and ASP.Net is a Framework. Do you mean should I create a client windows app or a web (intranet) app then this would depend on your strengths as the intranet option would also require HTML and possibly CSS/Javascript.
I am looking for a way to have ColdFusion and ASP.NET share session variables. I have seen posts in the past saying that you cannot do this directly with out calling some sort of ColdFusion function to return some sort of string representation of the session. I have recently learned about something called ehcache that is a third party session storage tool. That got me wondering is there a third party session tool that will allow ASP.NET and ColdFusion to share a session.
Some details about our systems:
They are running Windows Server 2008
We are using IIS
We are using ColdFusion 9
ColdFusion/Railo and asp.net can use EHCache, but they're very unlikely to share sessions out of the box. Each will have their own session key, which they'll use to put the data in/out. They'll all have their own way of storing the data. I may be wrong, but from memory, ColdFusion uses WDDX, Railo uses something like JSON and I've no idea what the .Net platform uses.
The point is that each hides the complexity of dealing directly with ehcache, but they each do it in their own way. If you want to interoperate, you may need to have each read/write directly to ehcache (or the database). You'll also have to work out a way of sharing a common key between .Net and ColdFusion.
If you're rolling your own version of this, then using JSON proably makes sense as the common format.
What would be the pros and cons of taking a large (16000 LOC) existing Access 2007/Forms application and porting it to SQL Server 2005, while keeping the Access forms on the front end, versus porting the front end to a .NET technology, say ASP.NET 4.0 or MVC3? The backend is definitely getting ported to SQL Server, with large schema modifications, so this question is about whether to use the existing Access Forms front end or not. I don't take throwing away existing working code lightly! On the other hand, the schema will be changing a lot.
If you had a lot of experience with ASP.NET/Oracle but not with Access or SQL Server, how might this change your answer?
Thanks,
Mike
There is nothing wrong with Access as a front-end to an RDBMS whether SQL Server or another
Porting the front-end but leaving an Access back-end would seem a bit weird: why bother? Access is a good presentation tool but mediocre DBMS. Why keep the mediocre?
Also, only change one component at once no matter what you do: data, then front end. Don't do a big bang approach and change the lot
Actually, comparing going with web application (ASP.NET) and stand-alone (Access) is not truly "apples-to-apples" comparison. It highly depends on your requirements.
Sure, going with web application will require much more developer's efforts comparing to building forms/reports in Access. But, the pay-off will be felt in the mid to long term.
You should also consider scalability, deployment, and availability issues when deciding to go/stay with Access.
Ok, so here's the thing.
I'm developing an existing (it started being an ASP classic app, so you can imagine :P) web application under ASP.NET 4.0 and SQLServer 2005. We are 4 developers using local instances of SQL Server 2005 Express, having the source-code and the Visual Studio database project
This webapp has several "universes" (that's how we call it). Every universe has its own database (currently on the same server) but they all share the same schema (tables, sprocs, etc) and the same source/site code.
So manually deploying is really annoying, because I have to deploy the source code and then run the sql scripts manually on each database. I know that manual deploying can cause problems, so I'm looking for a way of automating it.
We've recently created a Visual Studio Database Project to manage the schema and generate the diff-schema scripts with different targets.
I don't have idea how to put the pieces together
I would like to:
Have a way to make a "sync" deploy to a target server (thanksfully I have full RDC access to the servers so I can install things if required). With "sync" deploy I mean that I don't want to fully deploy the whole application, because it has lots of files and I just want to deploy those new or changed.
Generate diff-sql update scripts for every database target and combine it to just 1 script. For this I should have some list of the databases names somewhere.
Copy the site files and executing the generated sql script in an easy and automated way.
I've read about MSBuild, MS WebDeploy, NAnt, etc. But I don't really know where to start and I really want to get rid of this manual deploy.
If there is a better and easier way of doing it than what I enumerated, I'll be pleased to read your option.
I know this is not a very specific question but I've googled a lot about it and it seems I cannot figure out how to do it. I've never used any automation tool to deploy.
Any help will be really appreciated,
Thank you all,
Regards
Have you heard of the term Multi-Tenancy? It might be worth look that up to see if that applied to your "Multiverse" especially if one universe is never accessed by another...
See:
http://en.wikipedia.org/wiki/Multitenancy
http://msdn.microsoft.com/en-us/library/aa479086.aspx
UPDATE:
If the application and database is the same for each client (or Tenant) I believe there are applications that may help in providing the same code/db as an SaaS application? ie another application/configuration layer on top that can handle the deployments etc?
I think these are called Platform as a Service (PaaS) applications:
see: http://en.wikipedia.org/wiki/Platform_as_a_service
Multi-Tenancy in your case may be possible, depending on client security requirements, with a bit of work (or a lot of work):
Option 1:
You could use the one instance of the application, ie deploy the site once and connect to a different database for each client. You would need to differentiate each client by URL to isolate content/data byt setting a connection string for each etc. (This would reduce your site deployments to one deployment)
Option 2:
You could create both a single instance of the application and use a single database. You would need to add a "TenantID" to each table and adjust all your code to accept a TenantID to ensure data security/isolation. Again you wold need to detect/differentiate the Tenant based on the URL to set the TenantID for the session used for every database call. (This would reduce your site and database deployment to one of each)
The current application is a kind of CRM application built upon MS Access. The application is for internal use. My job is to migrate it to ASP.NET web-based application. Now boss requires to keep Access as database and develop ASP.NET code against it.
My question is, is there any disadvantages of using Access as database in ASP.NET application? (e.g. optimistic concurrency issue?) Should I persuade boss to upgrade Access to MS-SQL?
Many thanks!
We've used Access as a backend for web sites with good success. It's cheap, can be used effectively by moderately skilled programmers, and you can store the MDB on a document server so it gets backed up.
Most IT people dislike Access, but from a business perspective, Access can be very valuable.
MS Access is notoriously unstable in multiuser environments. A WEB app is by definition heavily multi-user.
So IMHO leaving MS Access as underlying DB is a call for trouble. At least use SQL Express (it is free)
The problem you are going to face in upgrading from Access to MS-SQL is that there is a major cost investment for the application. If your company already has the infrastructure in place(licensing, hardware...) then you won't have such a hard fight to pursuade your boss.
As for a technical answer:
I'd say you need to let you boss know that access databases aren't ideal for concurrent usage which a web application suggests is the intended goal of the application. My view is that Access is for database information that a SMALL set of users will be simply using for small data entry and querying. NEVER use Access to build an enterprise-level solution.
If you are planning to upgrade a Microsoft Access database to SQL Server 2008, use the SQL Server Migration Assistant (SSMA) rather than the upsizing wizard built into MS
10+ tips for upsizing an Access database to SQL ServerAccess.
Your boss probably likes to do ad-hoc stuff with access / excel. If you move the DB to SQL Server Express you can use Access and it's linked table feature to let your boss keep doing his ad-hoc needs through Access while keeping the data in SQL Server Express. If you keep the linked tables named the same as the old physical ones all his reports and queries will should keep working.
I'm an Access promoter, but not for use on websites because Jet/ACE is not threadsafe (though Michael Kaplan once said that is is threadsafe if you access it via ADO/OLEDB; I don't quite understand how a database abstraction layer can wash away a characteristic of the underlying database engine it's calling, but if MichKa said, it's 99% likely to be true).
Now, the exceptions would be if you're using it for prototyping something that will use a different database, or if it's read-only, or is read-write but will only ever have a very small number of users.
Michael Kaplan's website, trigeminal.com, used to use a Jet database as the back end (it may still -- I don't know that MichKa ever changed it), and when that was his main website he reported getting 100K hits a day. But it's a read-only site, so fits my restrictions.
There are so many different alternatives and they are mostly easy to use that I just don't see the point of trying to use Jet/ACE as back end for a website. I'd never do it myself (all the websites I'm responsible for use MySQL).
Simply put, go with MSSQL. Express edition is free, and will give you everything you need to migrate away from Access. These articles are talking about Access applications specifically, but the same issues will plague you.
http://resources.zdnet.co.uk/articles/features/0,1000002000,39285074,00.htm
https://web.archive.org/web/1/http://techrepublic%2ecom%2ecom/5208-6230-0.html?forumID=102&threadID=205509&messageID=2136367