Background:
In my windows phone project. I use local SQL CE database to store date. The create the database tables using LINQ to SQL programmatically.
This database is accessed through various datacontext instances in couple of threads.
Here's the issue:
I give an option to the user of my app to erase all the data and logout. When the user selects this, I delete the database using the datacontext's DeleteDatabase method. But, I always receive the error that the database is being used by another process, hence cannot delete.
Any nudges in the right direction will make my day.
Andy as mentioned above (to be honest they beat me) the problem was accessing the database when another process still had the connection opened. Basically it can be easily fixed by placing any code you run against the database inside of a using block like so:
using (MyDataContext db = new MyDataContext("isostore:/MyData.sdf"))
{
//Run database logic here
}
I guess in a sense it makes perfect sense for the error. Same thing happens with open files in WP7.
For more information and an example check out this page.
Related
I am trying to build a WinForms app that allows the user to fill out a form for our company while keeping it clean and standardized. As part of this project, I have created a replication from our production Db with only the tables for clients and client contacts. I need those tables available to the App so it can pull current client information for this form. I wanted to add another table to the replication that is not from the original Db that will take all the information added for the form. I guess I don't need it, but I was wondering if it was possible and, if so, will it break anything.
I can already hear some of you guys reading this saying, why don't you just add another table to the production Db. Well, I thought of that but, the App that is bound by that Db is very strict and runs a check every time the app is launched to make sure the Db hasn't been corrupted. If it finds a new table has been added, I'm sure it wouldn't work. Also, I hear some of you shouting at your monitors, "Why do you want this table as part of the Replication, Why not just house it on a different Db that won't affect your precious app?" And to those people I would say, I just thought of that. But, I am trying to make something lightweight that can be put on a lot of computers without much over head or back end. Thank you in advance for considering this problem.
I inherited a SQL Server database used with a C# client application. I know enough to be dangerous but I'm not a programmer. I know the previous programmer liked to play around in the live database and as a result I have a number of what I think are orphaned tables.
The application itself isn't super high-usage and can withstand the exceptions of tables not being there for a small time frame. I'd like to start turning off or disabling these tables to see they're being used anymore through trial and error.
Is there a way to turn them off without completely removing the data so that I can re-enable them quickly if needed? Or is there a more transparent way to discover whether those tables are needed?
There is no easy way. The tables can be accessed through both stored procedures and direct SQL calls from your client application. A comprehensive approach would mean that you'd have to have some way of making each table unavailable (renaming has been suggested in comments) and then perform a full regression test on your client application; you might have to do this with each table in the database. The client application might access the tables conditionally, subject to external things like the logged-in user (and related privileges), the date, configuration, and so forth.
The SQL Server Profiler is a good tool to use, but it's not going to solve your problem all by itself because you still have to analyze what it captures.
You could create a new db schema and transfer the tables to that schema
ALTER SCHEMA new schema TRANSFER dbo.your table
Then transfer them back again after testing.
https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-schema-transact-sql
You can change the permissions so that no one except you and the dbos have select permission on the table. You cannot prevent a dbo or sa from having all permissions on a table.
You can also encrypt the table see- Encrypting database tables in SQL Server 2008 in which case it is really locked down.
You can also used SQL Server Audit to see if anyone reads the data. Audit is a very low impact product (comes with SQL Server 2008) and is very easy to set up and can audit selects unlike a trigger.
I have a C# application which uses sql database on sqlexpress. My client will use on his/her computer, so I am concerned about database security. So I have following questions:
1- Should I use Windows Authorization on SQLEXPRESS or SQL Authorization? If I use WA, what if someone (who has a reach Windows Applications accidently, the computer will be in a school campus) reaches the data file and manipulate data (using SSMS maybe?)
2- I also tried to write a trigger on tables which stores sensitive data. My concern is not data reading, but manipulating is; such as insert, update and delete. I tried to use temporary tables (defined by c# application that has some hashed data), the trigger had to check if table exists and hashed data was correct. But c# application cannot reach temporary table even created by itself.
I tried EFS on Windows, but anyone can reach Windows grants, can deactivate EFS on database file. TDE is out of question also, because of SQL version.
The question is how can I check (or trigger check) whether database connection was made by .net applicaton? Is there any better efficient way to do it?
Yes, I solved it.
1- I realized that, I can use Windows Authorization but, to prevent data manipulaton beyond the application; giving minimal permissions to Windows user is better way to protect data.
2- Also realized that, I can use tempdb database to create permanent temporary tables. This solves my problem about temporary tables.http://jayeshsorathia.blogspot.com.tr/2012/03/beginning-sql-difference-between-local.html
Thanks for reading.
I ran into real brick wall trying to connect to dynamic databases. And I don't know how to achieve this,
Here is my process, I have an application where it needs to be adaptable to changes in the work environment, say If the work places server crashes and they create a new database with the name db_new the application would connect to that instead of the old database name.
I already have a window that displays the databases from the server on a listbox where the user can specify which database to use for the application. But the issue is, how can I save the selected database name so that it can run after the new database is selected? ..
as in the administrator should be able to change the database the application uses if necessary and the application should keep on using that selected database till the administrator changes it back to a new one.
Please forgive if the question a bit vague, I just put it together in the best way I could, any help on this would be really great :)
EDIT:
And I cannot use text files or xml s as the database name the application uses should be stored in a secure manner. :)
First of all, you can very easily use a text or XML file: If you store the information in a file, that can't be downloaded by the user (as I assume you would), this is as safe as it can be: If somebody manages to break into the server and read the file, it's game over anyway.
That said, I would recommend you use MySQL proxy or a similar mechanism and point your WebApp at it - failing over to another database or changing the underlying database could then be handled at the proxy layer without the WebApp even knowing about it: The functionality need not be part of your application and in my book it shouldn't.
You haven't told us the language you are using. Therefore we cannot offer very good suggestions.
My first thoughts:
If this was PHP you could have the general app use something along the lines of,
$db->execute('sql statement here');
and then just have the administrator change the current $db when needed. That way $db->execute() will always be executed on the "current" database.
Edit: This should still work in C#. If you have the functions using the database call a variable that is the current db connection then you should be able to change the db connection to the proper database whenever you need while the rest of it continues running since it's just the same variable.
I have a client who has a product-based website with hundreds of static product pages that are generated by Microsoft Access reports and pushed up to the ISP via FTP (it is an old design). We are thinking about getting a little more sophisticated and creating a data-driven website, probably using ASP.NET MVC.
Here's my question. Since this is a very small business (a handful of employees), I'd like to avoid enterprise patterns like web services if I can. How does one push updated product information to the website, batch-style? In a SQL Server environment, you can't just push up a new copy of the database, can you?
Clarification: The client already has a system at his facility where he keeps all of his product information and specifications. I would like to refresh the database at the ISP with this information.
You don't mention what exactly the data source is, but the implication is that it's not already in SQL Server. If that's the case, have a look at SSIS.
If the source data is in SQL Server, then I think you'd want to be looking at either transactional replication or log shipping to sync the two databases.
If you are modernizing, and it is a handful of employees, why would you push the product info out batch style?
I don't know exactly what you mean by "data driven", but why not allow the ASP.NET app to query the SQL Server product catalog database directly? Why generate static pages at all?
UPDATE: ok, I see, the real question is, how to update the SQL database running at the ISP.
You create an admin panel so the client can edit the data directly on the server. It is perfectly reasonable to have the client keep all their records on the server as long as the server is backed up nightly. Many cloud and virtual services offer easy ways to do replicated backups.
The additional benefit of this model is that more than one user can be adding or updating records at a time, making the workforce a lot more scalable. Likewise, the users can log in from anywhere they have a web browser to add new records, fix mistakes made in old records, etc.
EDIT: This approach assumes you can convince the client to abandon their current data entry system in favor of a centralized web-based management panel. Even if this isn't the case, the SQL database can be hosted on the server and the client's application could be made to talk to that so you're only ever using one database. From the sounds of it, it's a set of Access forms and macros which you should have source access to.
Assuming that there is no way to sync the data directly between your legacy system DB (is it in Access, or is Access just running the reports) and the SQL Server DB on the website (I'm not aware of any):
The problem with "pushing" the data directly into the SQL server will be that "old" (already in the DB) records won't be updated, but instead removed and then recreated. This is a big problem with foreign keys. Plus, I really don't like the idea of giving the client any access to the db at all.
So considering that, I find that the best is to write a relatively simple page that takes an uploaded file and updates the database. The file will likely be CSV, possibly XML. After a few iterations of writing these pages over the years, here's what I've come up with:
Show file upload box.
On next page load, save file to temp location
Loop through each line (element in XML) and validate all the data. Foreign keys, especially, but also business validations. You can also validate that the header row exists, etc. Don't update the database.
3a. If invalid data exists, save an error message to an array
At the end of the looping, show the view.
4a. If there were errors, show the list of error messages and tell them to re-upload the file.
4b. If there were no errors, create a link that has the file location from #2 and a confirmation flag
After the file location and confirm flag have been submitted run the loop in #3 again, but there's an if (confirmed) {} statement that actually makes the updates to the db.
EDIT: I saw your other post. One of the assumptions I made is that the databases won't be the same. ie, the legacy app will have a table or two. Maybe just products. But the new app will have orders, products, categories, etc, etc. This will complicate "just uploading the file".
Why do you need to push anything?
You just need to create a product management portion of the webpage and a secondly a public facing portion of the webpage. Both portions would touch the same SqlServer database.
.Net has the ability to monitor a database and check for updates. then you can run a query to [push] the data elsewhere.
or use sql to push the data with a trigger on the table(s) in question.
Is this what you were looking for?
You can try Dynamic Data Web Application.
You should have a service that regularly updates the data in the target DB. It will probably run on your source data machine (where the Access-DB is)
The service can use SSIS or ADO.NET to write the data. You can do this over the web, because you have access via TCP/IP to the server I assume.
Please check when the updates are done and how long it takes. If you can do the updates during the night you are fine. If not you should check, if you can still access the web during the import. That is sometimes not the case.
Use wget to push the new data file to the mvc app and once the data is received by the action, the mvc app invokes the processing/importing of the data (maybe in a worker process if you dont want long requests).