Gonna need some advice for my work.
In my computer I have installed VS2010 and SQL Server 2008 Developer with a customized instance name named MYCOMPUTER. If I need to transfer the project work, that is created with ASP.NET MVC 2 and of course I also have create a database via VS2010:s interface, from my computer into another computer that has VS2010 with light version of SQL Server 2008 with a instance named SQLEXPRESS, will it be trouble?
I also heard that if you have created roles in the ASP.net via VS and it can be more error message or trouble in relation with SS 2008 Developer due to database's defined roles. Is it true?
// Fullmetalboy
It will be no troubles with moving databases if you will use backups or plain sql scripts (actually this is most painless way). As for roles - it depends on what roles are you talking about? Roles created for default SqlRoleProvider? If so all you need to do is to write appropriate connection string in your web config.
Related
Visual Studio 2010
MSSQL 2005
Windows Vista
I am creating an ASP.NET website using webforms, I want to create a members section using Web Site Administration Tool. I am following this youtube tutorial (http://www.youtube.com/watch?v=vxxFhGF-Z7E) but I am stuck at 2:58 mins into vid.
After I have created users and roles the vid says ASP.NET should automatically create a Database with tables in the APP_Data section in the Solution explorer in ASP.NET. BUT.... mine doesnt create this database. And when I go into the "Provider" tab in Web Site Administration Tool and test the connection I get an error:
Could not establish a connection to the database.
If you have not yet created the SQL Server database, exit the Web Site Administration tool, use the aspnet_regsql command-line utility to create and configure the database, and then return to this tool to set the provider.
I have looked into lots of solutions online for this but cannot find a solution. Would anyone know what I am doing wrong?
What you need to do is to run the aspnet_regsql you can find that under C:\Windows\Microsoft.NET\Framework\v4.0.30319
if you are using .net4
after running the wizard you should see some tables have been added to your database these are your membership tables
after running this you may need to check your connection string out and ensure that it is correct
if these are all correct
when running the membership you should be able to add users
Thanks Inkey
I'm upgrading an ASP.NET 4.0 app from:
Windows Server 2003 and IIS 6
to:
Windows Server 2008 and IIS 7.5
This app is based on ASP.NET Web Forms and not MVC. I currently use SQL authentication, but I would like to follow best practices in the new environment.
Both the IIS 7.5 machine and the SQL Server 2008 machine will reside in a DMZ with its own domain controller. It would be nice if we could use similar connection strings for Dev, Test and Prod environments. What's the best practice for this situation? I've read about three options.
ApplicationPoolIdentity
Create your own service account on the domain
SQL authentication
Here are links to questions that discussed related issues, but nothing seemed to answer my specific question.
User ASP.NET Runs Under
Assign Permissions to ApplicationPoolIdentity Account
I recommend AD account for running the app pool. Then, permissions can be created at SQL server for that same account. The conn string used by the app will then not have to contain account info at all (trusted connection), and you will have one less thing to worry about related to security. As additional precaution, remove that AD account from all user groups, and don't use it for anything else but for this one thing (the app pool). Give that user read access to website files, and write access only to folders that it needs to write to (e.g. to dump log files).
As far as best practices is concerned, I don't think any of the 3 options you listed is better over the other one; all of them can do the job securely and efficiently if used correctly. Your decision should be based on which of those offers advantages to you considering your particular environment, company policies, etc., but again, none of them are bad practice.
I'm trying to create a database within the app_data folder of an asp.net mvc project using the IDE, but i am getting a "Required Components Missing" message indicating "Connections to SQL Server files (*.mdf) requireSQL Express 2005 ....."
I am using
- Windows 7 Enterprise
- VS2008 Team System SP1
- SQL Server 2008 Developer Edition SP1
I have altered the database connection to use the default instance by setting to blank using
Tools -> Options -> Database Tools -> Data Connection : SQL Server Instance Name
I also note from the SQL Server Books Online that the user instance feature will be removed in the future, but for now it suits my effort in developing an application where a number of people are working on the project.
Has anyone managed to create a database in the same manner?
It appears Nerd Dinner has done so
The attached user-instance database in the App_Data will work only with a SQL Server Express edition - 2005 or 2008.
It does not work with a full SQL Server edition, like Web, Workgroup, Standard, Enterprise or Developer. It does not - no way - no trick to make it work - does not - period.
If you want to use that mechanism of attaching a user instance database in your App_Data folder, you must use SQL Server 2005/2008 Express.
My Problem is the following,
I have an ASP.Net web site hosted on IIS. This web site connects to an Access 2007 DB file on the same server. The DB file contains links to sharepoint lists on another server on the same domain. If I run the web site on the visual studio built-in server, I can Open connection to the DB file and retrieve data just fine. But whenever I try to run the web site over the IIS, the web site can't open a connection with the DB file.
What do you think the problem is?
Thanks.
It will be a permissions problem. When you run with Visual Studio's web server it is running as you, IIS on the other hand runs (by default) as Network Service. This is limited in what it can do.
To access an access database (no pun intended) the account that IIS runs under will need the ability to read, write, execute, change and delete for the directory the database is in. By default this should be granted to the APP_DATA directory, if your access database is elsewhere you will need to grant these permissions.
Connecting via Access to a remote machine is a whole other problem, it's unlikely this will work because the Network Service account is a local account and will not exist on the sharepoint server, and you cannot grant access because it does not exist.
If you were in a domain you could run IIS under a suitable locked down domain account and it might work, but frankly it's all a bit messy!
Have a look at this article:
How to connect to a remote Access database from Active Server Pages
http://support.microsoft.com/kb/253580
Yes, I know your database is on the same machine, but there are differences in permissions and authentication for files and folders when you run IIS. The chances are good that whatever is hanging you up is covered in this article.
Whether mixing Access databases and IIS is a Good Thing or not is a separate discussion...
Access 2007 makes connecting to SharePoint a breeze. After you link to a list, then ADO, and even DAO + VBA code and your sql queries work on those lists!
I seen a good number of people thus start using the JET (actually it called ACE in access 2007) as a data connector to SharePoint for this very reason. Since your are building a web based system then we not using ms-access here, but ONLY using the 2007 version of the JET data engine that ships with access 2007.
Someone does need to come out with a OLEDB provider for SharePoint lists that allows ones web site or .net code to view those lists as standard sql tables like ms-access can. Using JET as the data connector system is likely not such a good idea. I do realize that you not storing nor placing data in the access JET table, but are using the wonderful ability of the new access JET engine to view and use SharePoint lists as regular sql tables. This approach does allow your ASP.net code to execute sql updates on that data or do whatever as if this was a regular sql table. It does make this oh so easy.
The security permissions on the SharePoint site are thus going to view this connection as not as a end user, but always see the USER as the actual web site connecting (or at least the user you were in ms-access when you linked the table to SharePoint). I don’t believe the SharePoint user authentication process can work reliable when you do this. What will happen is you change a few things on the SharePoint site, and next thing you know the JET connection will be trying to prompt you for new logon credentials. You can’t provide nor control those logon credentials at that point in time.
So, as others pointed out, this is going to be problematic and not reliable.
Using Access as a fudge to access SharePoint from an ASP.net site is going to give you lots of pain in the long run.
A much better way would be to use SharePoint's web services to access that data - removing Access from the equation altogether.
http://www.scribd.com/doc/8634090/Accessing-SharePoint-Data-Using-C-Without-Running-Code-On-the-SharePoint-Server-Part-1
MSDN - Using ASP.NET web services
Creating and Consuming a Web Service
I tried to set-up the SQL tables for ASP .net 2.0 membership provider by clicking on ASP.net Configuration under Project.
I have completely uninstalled SQL 2005 Express and installed SQL 2008 Express instead.
It seems like that it can not connect to the database.
Does anybody know how to get this fixed so I can use 2008 instead ?
Try to configuring the database typing "aspnet_regsql" on the VS command prompt.
Then setup the database and finally change de connection string on the web.config file.
ASP.NET SQL Server Registration Tool (Aspnet_regsql.exe)
What is your SQL 2008 installation instance called? What does your connection string for the membership provider look like?
As far as I know, there is (or was) a glitch in the SQL Server 2008 Express installation that even if you chose to install as "default" instance, it would still make it a "named instance" called ".\SQLExpress" instead. Could that be the problem?
Marc
As Marc already has pointed out, it could be the problem with the instance name. This is fixed in service pack 1 for SQL Server 2008 Express. For more information and a workaround, see this Microsoft KB article.
SQL 2005 and 2008 are both configured in a fairly locked down state by default - and this means that SQL won't accept access the database other than through Shared Memory, even with Integrated Security.
You need to enable TCP/IP or Named Pipes for the Client Protocols for the server (as this is how ASP.NET talks to SQL if you've not configured a DSN to use Shared Memory.
I can't remember the exact steps in 2k8, as I've only had to do it once, but in 2k5 you had to open the SQL Server Configuration Manager, select SQL Native Client Configuration, Client Protocols, and enable TCP/IP and Named Pipes - it's a similar process for 2k8 as I recall.
The connectionStringName used in the membership Tag should be changed to the present connection string where you have the membership tables created.
If the connectionStringName is not pointing to a valid connection String name in the connectionStrings tag, the membership tables can not be used by the application.