SELECT * FROM tblXXX Returns Only One Result - sql-server-2008

I have a SQL 2008 R2 Express database that Im running an ASP.NET MVC 2 application on.
It always seems to be first thing in the morning when this problem arises - application login will fail. So I run a query against the database like SELECT * FROM tblUser and it returns only 1 result (always some random user and none of the others), making me think the records have been truncated.
So I try to recreate the admin user for example, which fails, and suddenly all users are back in the database (as reflected by a SELECT * FROM tblUser query)
Restarting the database service resolves the issue, but I need to find out why its happening. Does anyone have an idea?

SOLVED
I have a bad habit of simply copying my user instance databases and using them again in other projects that require a similar schema.
Knowing that, a friend of mine suggested scripting my entire database (including data, using SQL Management Studio) and recreating it from that.
Another friend suggested attaching the database to SQL Server 2008 full version, not Express, so I thought I'd combine the two ideas and script the database and data onto the SQL Server 2008 - which has worked :)
N.B. It also reminded me of how blisteringly fast SQL Server full version is!

Related

Data in SQL Server 2008 Express edition does not show up after insert?

I have a SQL Server 2008 Express edition database and I am inserting data to it via a windows application, using Linq-to-SQL. I know the data exists in database because when I query the database I get some data but in SQL Server Management Studio when I right click on a table and click even : 'Edit top 200 rows' or 'Select top 1000 rows' I can not view any data ! any helps ?
Assuming you're using the User Instance and AttachDbFileName= approach - I would argue this approach is severely flawed. Visual Studio will be copying around the .mdf file and most likely, your INSERT works just fine - but you're just looking at the wrong .mdf file in the end!
If you want to stick with this approach, then try putting a breakpoint on the myConnection.Close() call - and then inspect the .mdf file with SQL Server Mgmt Studio Express - I'm almost certain your data is there.
The real solution in my opinion would be to
install SQL Server Express (and you've already done that anyway)
install SQL Server Management Studio Express
create your database in SSMS Express, give it a logical name (e.g. VictoryDatabase)
connect to it using its logical database name (given when you create it on the server) - and don't mess around with physical database files and user instances. In that case, your connection string would be something like:
Data Source=.\\SQLEXPRESS;Database=VictoryDatabase;Integrated Security=True
and everything else is exactly the same as before...
I believe LinqToSql has a "Save" command that actually writes the data to the database. Until that happens you are merely holding it in memory.
ETA: see this question and its answers

Pulling information from multiple servers with one query

I am trying to run a query that will pull information from multiple servers. Let me explain a little bit. The machine that makes a certain product stores that information on a server. So when we do reports we have to run a query on the accounting side and then run a query on the first server. I was just wondering if anyone could point me in the right direction, or help me out a little with constructing this query.
Since you didn't technically specify, I'm assuming you're running the query in MS SQL Server and the other databases are either MSSQL or MySQL, guessing based on your tags.
If that's the case you have a couple options. If you're going to be running these queries frequently you can use a linked server or if you're only wanting to do them sparingly you can use OPENROWSET.
Other options would be to create a SQL Server Integration Services (SSIS) package to extract the data from various sources and compile it into a single report or alternatively SQL Server Reporting Services (SSRS).

One table in my SQL Server 2008 Express r2 database is timing out

I have been using a SQL Server 2008 Express R2 database for a few months now. Recently, one of my tables started timing out if I try to make an UPDATE through code or through Management Studio. I have tried making changes via the designer in management studio as well, and the same thing.
What can cause a single table to time out like this? My other tables are instant response to my changes, but this one just refuses to let me make any changes.
It sounds like your bad table has some kind of trigger attached to it. I suggest firing up SQL Profiler to see exactly what queries are being sent to the table.

How can I open a SQL Server 2000 database in SQL Server 2008 Express?

A friend recently asked me to help him to change an application to allow multiple instances connecting to the same back end database. However, he has very limited understanding toward the inner work of the application or CS in general, and the guy who had developed the application for him has left.
My guess is that it is possible to get it done by making some simple changes to the application's database connection properties. The problem is that I have no idea how the database was set up. A note left by the previous developer mentioned that the database was created in SQL Server 2000. I do not have SQL Server 2000 around though. Is it possible at all to open/migrate the SQL Server 2000 database to SQL Server 2008 Express, and if so, how can I do it? If not, what the reasonable approach for the DB migration?
Thanks a lot for your help!
--Angler Y.
Yes, you can migrate the database using simple detach-attach method or backup-restore method
BUT
if the database size exceeds 4 Gb it woun't work on Sql Express 2008

Is it possible to programmatically set the ProviderManifestToken for a code-first EF model?

We have an environment where each of our clients has their own database instance (with identical schemas, for all intents and purposes). We have a dashboard application where clients can login to perform CRUD operations on data in their specific database. We use a single code-first EF model for interacting with the databases. (For whatever client is being viewed, we simply pass that client's database's connection string when instantiating the DbContext.)
However, the database instances are a mix of SQL Server 2005 and 2008. (I'm pretty sure this is the root of the problem we're seeing.)
On a particular page, we've begun to see the following error occur:
The version of SQL Server in use does not support datatype 'datetime2'.
From Googling and StackOverflowing, I've come to the conclusion that it's probably due to a misconfigured ProviderManifestToken on the DbContext.
However, the error is sporadic. Based on production error logs, I can view the same client for which the error occurred and perform the same CRUD operations without getting the error.
I'm at a loss.
Is it even possible to programmatically set the ProviderManifestToken? Or maybe the default connection factory isn't properly setting it (and there's something I can do to help it along)? Or am I way off base? Any ideas?
By the way...
The entity that the error is occurring on has 2 datetime columns, both of which are nullable (and the most recent error had null and Jan 13, 2012 as its values for those fields, so I'm pretty sure that this answer about ensuring that the values are within datetime's range doesn't apply.
Well, no solution yet. But we figured out a workaround for now.
If we restart the app pool, then immediately visit the client dashboard for a 2008-backed client, EF will generate and cache a mapping based on SQL Server 2008 constraints and all 2008-backed dashboards work just fine but 2005-backed dashboards fail on writes with the datetime2 error.
However, if we restart the app pool, then immediately visit a 2005-backed client dashboard, EF will generate and cache a mapping based on SQL Server 2005 constraints (which allows the model to work with both 2005 and 2008 database instances).
So, basically, our publish process now has the extra step of immediately visiting a 2005-backed dashboard.
Thank you for posting this. I had the same problem with a console app that visited a SQL2008 DB than a SQL2005 DB and had the same problem. I switched it so it went SQL2005 first, than SQL2008 and the problem went away. I am also using EF code first.