|
Check the DB security, I don't have a SQL Server on hand right now to check where, but in the management console go to the database, then security and see who has access to it, also at server level check the DB assignments to each security group.
The problem is not related to your app, is in the database security for sure
I want to die like my grandfather- asleep, not like the passengers in his car, screaming!
|
|
|
|
|
I'll do that. It makes sense, in a twisty, Microsoftian way. Since all the DBs were created with the same tool, using the same settings, they should behave identically. But prior to this last one there was an automatic Windows Update. That may have changed some of the default settings in SQL Server. If not, I'm bolluxed; nothing else has changed.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
At least a partial solution...
When creating the database in Management Studio, I used the user name RAWRIGHT\Administrator as the owner. But while reviewing the error logs I found many entries corresponding to my attempts to connect locally reporting a logon failure for RAWRIGHT\rawright. Apparently it considered me connecting from the client PC to be a different user than the local one, which makes sense. What doesn't make sense is that the other DBs on the server don't care what login I use. I still haven't solved that mystery.
But for now, I added the RAWRIGHT\rawright user name to the list of LOGIN objects on the server and I can now connect using the Add Database wizard in Visual Studio. I'm still mystified about why the other DBs work fine, while this one has been a nightmare, but at least I can get on with the project.
If anyone has an explanation I'd appreciate hearing it. MSDN and Microsoft Support have apparently never heard that there's a problem, based on the results from Bing. 
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: MSDN and Microsoft Support have apparently never heard that there's a problem, based on the results from Bing.
Did you ever consider the possibility of Bing being a bit subjective when looking for MS problems?
|
|
|
|
|
That thought had crossed my mind. I also considered the possibility that Bing is just as useless as the old MSDN Search, but of course discarded that train of thought as unworthy. 
And I posted too soon. Having spent an hour recreating the database, all the tables, and a diagram with a username that works, I returned to Visual Studio and added the connection successfully. Unfortunately, the wizard connects nicely, but reports that the database contains no tables (nor anything else). Thanks a bunch Microsoft, for a week of fun-filled long evenings... 
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Then it is time to modify your subject line again.
|
|
|
|
|
It gets better. I had to go back to the server and click on Properties for each table, then individually select every Permission I want to have associated with my username. Talk about tedious! There's about a dozen permissions associated with each table. Surely there must be a simpler way!
But now I can at least see the tables and their columns in Visual Studio; I have yet to discover whether I can actually access them in code. I've never had much luck making the drag and drop method of creating data bindings before - I'm obviously missing something there, since no one else seems to bitch about it as much as I do. But that task is better left for another day...
Progress, however miniscule, is not to be scoffed at, nor pushed too far. It's late, and time for a nap before I really mess something up.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Go back to the server in SSMS, create another SQL ID in the server security, don't assign anything to the id.
Go the the database security and add the user, in the users permissions (where is has public checked) check dbo.
Now test the id by making another connection in SSMS using the new ids creds, make sure you can sees all the tables in the DB etc
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I'm only 300 miles away... 
|
|
|
|
|
I used Temp Table in my procedure, If I like to get values from temp table
in a procedure it shows error.
|
|
|
|
|
I believe no one can help without seeing the error message or the stored procedure you have. Would you mind posting that?
|
|
|
|
|
HI Guys need ur advise here
I am facing this issue that when i use the sp_executesql to execute my statement, the query time is way longer then normal.
Previously i am using this methed in stored procedure
simpely coding the statement
SELECT * FROM Bla Bla
but when i change to using
DECLARE @SQL AS NVARCHAR(MAX)
SET @SQL = 'SELECT * FROM bla bla Table'
EXECUTE sp_executesql @SQL
the query time slow down greatly
i change to using sp_executesql because i need to create the STATEMENT base on some condition checking
will be gald if u guys have any advise
Thanks a million
KaKaShi HaTaKe
|
|
|
|
|
This might be because SQL is not choosing the best execution plan. Check the execution plan which is followed to execute that dynamic query. Although, I am not aware that there is much you can do about this (except for getting rid of dynamic queries if possible), you can check out parameter sniffing if it can help. Here[^] is an article that tells about it.
|
|
|
|
|
Everyone keeps telling me that there is little or no difference between a stored proc and dynamic SQL, then I come across a post like this one and I think they are full of bullshit.
Change your var from nvarchar(max) to varchar(8000), it may help and cannot hurt.
REALLY make sure that you must use dynamic sql, there is often a way to get around using it if you construct your query correctly. Using case, conditional where and even if clauses to avoid dynamic sql.
As danish suggested, take a look at the execution plan of the dynamic and a normal version of the proc and see where you are paying the penalty.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Everyone keeps telling me that there is little or no difference between a stored proc and dynamic SQL, then I come across a post like this one and I think they are full of bullsh*t.
They obviously are. Just ask a simple question:
What takes more time - cooking and eating or just eating?
They should understand.
|
|
|
|
|
I could connect the database to different server thro' network, but last few days it fails to connect. It populates the Error message Failed to retrieve data for this request (Microsoft.SqlServer.Management.Sdk.Sfc.EnumeratorCore)
To my suprises I could connect the SQL Profiler. If there is network problem it wouldn't connect profiler. I think there is no problem in Network. Could anyone help me out.
Regards,
John.L.Ponratnam
|
|
|
|
|
Quick Google found this: http://forums.asp.net/t/1381599.aspx[^
me, me, me
"The dinosaurs became extinct because they didn't have a space program. And if we become extinct because we don't have a space program, it'll serve us right!"
Larry Niven
|
|
|
|
|
Hi all,
I have a legacy database system which was developed with the old MS Basic PDS ISAM. Does anyone know of a way to import the data into Access?
Thanks
|
|
|
|
|
I don't, but it sounds interesting (at least mildly).
The first step would be to find documentation of the file structure.
Or maybe the Jet Engine can read them? Did you search online?
Edit: Or an ODBC driver?
modified on Wednesday, March 31, 2010 9:44 PM
|
|
|
|
|
I haven't been able to find any documentation of the file structure, and I'd rather not go that route if possible.
An ODBC driver is exactly what I'm looking for. I have had no luck reading them with any of the Jet drivers.
I have searched online, and information on this seems to be fairly rare.
There has to be a simple solution, I'm just not seeing it!
|
|
|
|
|
I did some searching as well.
Out of curiosity... Is this a one-time copy of the data to a "better" database system? Or something you'll need to continue to do?
The best I can think of is to use that version of BASIC (I found a place from where it can be downloaded) to write a DLL with the required interface and call it from whatever language you want to use. Or maybe in the package there's a DLL you could call.
I also just took a quick look at an old (1999) ODBC book I have and nothing jumped out at me.
I'll give it some more thought after I have a nap... my brain hurts.
|
|
|
|
|
Thanks for the replies
It will probably be an ongoing thing until I can convert the program that creates it to a more modern language.
I thought about doing that, too, and tried to download it yesterday, but I got an error!! What site did you find it on?
|
|
|
|
|
|
|
Maybe try:http://www.easysoft.com/products/data_access/odbc_isam_driver
Is this free?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
