> The first experiments we ran in the migration to SQL Server 2005 were quite
> successful. .NET written applications all worked pretty much flawlessly.
>
> However, when testing our most important internal application, we quickly
> discovered it did not do nearly so well. This is what we had done.
>
> - Made a copy of a SQL 2000 production server
> - Upgraded it in place, all services included, to SQL 2005.
> - Modified the connection strings to the new server.
>
> As I said, the .NET apps and asp.net apps are fine. But they are a bit less
> sophisticated. The line of business app, written in vb6 and using ADO 2.7,
> at first choked on the way the application started up - a call to a fully
> qualified table name barfed up a message about "the security principle *
> cannot access the database under the current security context" (the
> connection string uses a SQL account..) Removing the fully qualified name
> gets us past this.
>
> However, then the application trips up on something almost unimaginable to
> me - it makes a "select *" to a table - and the ADODB.Recordset that gets
> filled by that statement returns EOF!! Now, the table in question is not
> empty, and we have verified that. And using the debugger, it is quite
> apparent the right connection string is hitting the right database - its
> just not returning any records.
>
> Is it my imagination, or should something like that just never happen in a
> database? I'd be really nervous about taking this migration past the testing
> phase, if we can expect much of this sort of thing...
>
>

> "Richard K Bethell" <softdev@spammingisevil.bad> wrote in message
> news:OLA7Ny39FHA.3808@TK2MSFTNGP10.phx.gbl...
>
>>"Trey Walpole" <treypole@newsgroups.nospam> wrote in message
>>news:ug8ymo39FHA.3340@TK2MSFTNGP12.phx.gbl...
>>
>>>were there errors on the select?
>>
>>That's the sort of behaviour you would expect. An error would be a lot
>>safer from an app perspective - but no, the result is for the Recordset
>>object to return without error, but as though the table is empty. There
>>are no "WHERE" clauses or qualifications of any sort, so it isn't as
>>though the data is being narrowed in some way. I've just never heard of a
>>result like this...
>
>
> It gets weirder - a colleague went to access this database using the Query
> Analyzer tool (from 2000.) Using Windows authentication, the application
> behaves as expected. But using the username and password of the SQL account,
> the Query Engine sort of lets you run queries against the tables.... but
> queries that return no records, even when you know they have records. So its
> not just this one application.
>
> What's going on here? The word on the street was SQL 2005 was ready for
> prime time... had been tested thoroughly.
>
> R.
>
>

"Richard K Bethell" <softdev@spammingisevil.bad> wrote in message
news:OLA7Ny39FHA.3808@TK2MSFTNGP10.phx.gbl...
> "Trey Walpole" <treypole@newsgroups.nospam> wrote in message
> news:ug8ymo39FHA.3340@TK2MSFTNGP12.phx.gbl...
>> were there errors on the select?
>
> That's the sort of behaviour you would expect. An error would be a lot
> safer from an app perspective - but no, the result is for the Recordset
> object to return without error, but as though the table is empty. There
> are no "WHERE" clauses or qualifications of any sort, so it isn't as
> though the data is being narrowed in some way. I've just never heard of a
> result like this...
>
>> could you post the connection string used? (minus proprietary info, of
>> course).
>> i tried duplicating using different settings, but couldn't reproduce; i'd
>> like to see if it's due to certain settings.
>
> "Driver={SQL Server};Server=****;db=****;uid=****;pwd=****"  is the style
> used.