ASP/ASP.net: Web-based JET database management tool? - asp.net

I need to manipulate some tables in a JET database housed on a web-server:
check existing indexes
change table cluster/primary key
see what tables exist
rename tables
add tables
drop tables
browse data
etc
I don't have the option of installing PlaneDisaster or Access (even if i had it) on the local machine.
I've already written a generic web-based query tool. I'd rather not have to get into writing a whole web-based database maintenance GUI. Someone must have done this already, and probably many times over.

A partial answer might be Compare'Em
http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEMscreens/CompareEM-About.htm The Pro version allows you to create SQL statements to update the Access database file. This will allow you to generate the differences between one version and a newer version.
His website isn't very clear but as I recall the price for the Pro version was $10.

As you say you have already done a generic web based query tool. The problem with JET is that you cannot connect with it as database server like you can do with one SQL server in order to process changes to tables and other maintenance procedures. Jet is is not a client/server RDBMS. You need to have an application in the server to do that for you as you already have done with your generic web based tool, or download the database to your machine. That's why you have done some procedures and locate them in the server as asp pages.
Anyway you can use JetSQLConsole, if you don't want to use Planedisaster or Access, but remember that you need always an application on the server to to the job for you
You can also use access "in your machine" and connect to a database located in a URL (http://myserver/mydatabase.mdb) but remember when you are doing this you are downloading all the database and when you save it you are uploading it again.

Related

Move a remote development database to local usage

I have been using a central MS SQL database located in the cloud to develop a web site project. I have recently found myself in situations, when I need to develop without the internet connection. I want to begin to use a locally available copy of the existing database, put it in App_Data folder.
What is the correct set of steps I need to undertake to get the project to work with local DB?
For example:
Detach a db from an existing SQL instance.
Copy to a development machine.
etc.
Moving a SQL-Server DB is not that hard. Look here for some methods to do it.
http://support.microsoft.com/kb/314546
I usually find the sp_detach + sp_attach method really easy.
I would create an empty shell database locally, then use one of the many schema comparison solutions available to make the local database look exactly like the cloud database.
Correct way is to create and regularly update your standalone copy of database using import/export. In particular MS SQL Server provides Import/Export Wizard tool for such purpose.
Make a backup
Copy backup file
Restore on your server
Restore/organise users

SQL CE 4 vs Files on a website

I am looking at moving all data loaded from files into drop downs, variable calculations, user state, Session Memory(hardcoded..),etc to be all loaded rather from SQL CE. Plus would be have it running in a MemCache or App Fabric layer but we don't have that luxury so we stuck with using Session or file loads to read the temp storage data. The data's too small to be kept in SQL Server as well as it's on a different machine on the network so compact edition seems to be a good option. It sounds like it's a viable option as you get a trimmed down db on your site versus files/session memory.
You should use Session for temporary storage, but replace all code that uses filesystem for storage with SQL CE, with files on filesystem you have to have some sort of thread isolation for different users of your ASP.NET application and with SQL CE you got that out of the box.
If you have to have some sort of search on that data, searching bunch of files is not very feasible.
In general I would sure preferred SQL Server Compact than files.

Should I go with attaching MDF file to SQL Express or a real deployment script to SQL Server?

I am building a blog-like publishing system on ASP.NET 4.0 (with EF 4.0) that I want to be very easily deployable/backupable in the first place. I am at a decision point of whether making the system to create a database in an SQL Server and use that (traditionally), or have a App_Data MDF file in the site and just attach to that one with SQL Express. I know the memory/size limitations of Express editions, and I won't be hitting the limits as this is not a performance-critical business application or any serious stuff. Just a simple CMS with blogs/writings/photos (actual photos are NOT saved in database, just their paths are saved in MDF) and that's it. I see no problem using MDF, but I'm not an expert on the topic too as I've never worked/created a website using MDF file. I always deployed on the SQL Server, but I don't want to deal with users/roles/permissions and the last thing that I want to have a user having installation problems due to database settings.
What should I go with? Any problems that I would face with MDF? Recommendations?
IF you use SQL Server Express - which is a server - I would always opt for a "real" database approach: attach your database to the server, access it by its database name, deploy SQL scripts to update it.
That "attach DB from file path" always seemed like a half-baked and rather messy kludge to me.....
If you don't need that kind of power - investigate SQL Server Compact Edition which is a one-file only, in-process database. It has its limitations - no stored procedures, doesn't support certain data types like VARCHAR(MAX) or XML - but for easier scenarios, it's perfect and easy to use - just deploy it along your app. It's single-user, e.g. you don't share the data between several clients, it's a local store for each user/app on its own

Updating SQL Server database with SQL scripts

I have a number of manually written scripts (.sql) for tables, views and stored procedures that are used from an ASP.NET application. These scripts drop the object and recreates them. I need a way to update the database when the scripts change without deleting the object. For example, when a column is added to an existing table that has rows in it, I would need to update this table with this extra column without losing the rows.
I need a way to "update" the database on a single click (I can hook up the changes using a batch file). Does Visual Studio support this kind of functionality?
If you get Visual Studio Team System - Database Edition 2008 - which is now bundled with "Developer Edition" for free - it handles that. Visual Studio database projects without that edition really just store the static SQL that you want to track. The Database Edition is capable of determining the 'deltas' between your SQL and what's in a target database, generating that script, and executing against your database. You do get the option of reviewing that generated SQL, but by default it is very safe [it won't run if it thinks that there will be any data lost].
Yes - it's called Database Projects.
You can define a Visual Studio Database Projects, have create and change SQL scripts inside it, and then execute those against a database connection of your choice when you need to.
See this blog post here for a great explanation, or read the whole series that the 4 guys from Rolla wrote.

Where to find state.sql for sqlserver mode sessionsates?

I am looking for the state.sql file provided by the .NET framework to run sessionstates in sqlserver mode. Where can I find the sql file to create the required tables and stored procs. I tried in the FRAMEWORKS/VERSION2.0 folder but I am unable to find it.
It's not state.sql anymore, but InstallSqlState.sql or InstallPersistSqlSate.sql.
Choose InstallSqlState.sql, if you would like to store your session data into tempdb (and thus to lose all sessions on every SQL Server restart). Or choose InstallPersistSqlState.sql if you would like to store them persistently.
This article has a great overview of both modes (temporary and persistent db), and the script is linked to from there also...

Resources