Tuesday, March 27, 2012
General Network Error
we have written a vb.net program using SQL Server 2000 SP4 over OLEDB.
Our customer has a network which is sometimes quite instable. So we did
some tests in our office, because we wanted to help our customer by
redisigning some of our SQL calls.
When we start the program and disconnect the network cable then the
next SQL query will result in a General Network Error, which is
logical.
When we start the program, then disconnect the network cable for about
ten seconds, then reconnect it, then the next SQL query will also
result in the same error, which we already cannot understand.
When we do the same as above, but before the next SQL query we close
the connection and reopen it, we still get the same error, which is
strange.
When we close, dispose and then recreate and open the connection, then
assign the connection to a new command and execute the SQL command, we
still get the same error.
When we stop the program and restart it, we can reconnect to the
database.
But when starting the program, we do nothing else than creating and
opening a connection. So why does it not work to reconnect while the
program is running?
Any explanations or suggestions?
Many thanks.
Daniel.
Dear Daniel,
I got the same error with u , Did u solve the problem?
thanks
From Agnes
*** Sent via Developersdex http://www.codecomments.com ***
|||Hi Agnes,
Unfortunately I never have got an answer to this post. I also posted
similar requests to other forums, but I never have got any answer. So
our problem still persists.
Regards.
Daniel.
General Network Error
we have written a vb.net program using SQL Server 2000 SP4 over OLEDB.
Our customer has a network which is sometimes quite instable. So we did
some tests in our office, because we wanted to help our customer by
redisigning some of our SQL calls.
When we start the program and disconnect the network cable then the
next SQL query will result in a General Network Error, which is
logical.
When we start the program, then disconnect the network cable for about
ten seconds, then reconnect it, then the next SQL query will also
result in the same error, which we already cannot understand.
When we do the same as above, but before the next SQL query we close
the connection and reopen it, we still get the same error, which is
strange.
When we close, dispose and then recreate and open the connection, then
assign the connection to a new command and execute the SQL command, we
still get the same error.
When we stop the program and restart it, we can reconnect to the
database.
But when starting the program, we do nothing else than creating and
opening a connection. So why does it not work to reconnect while the
program is running?
Any explanations or suggestions?
Many thanks.
Daniel.Dear Daniel,
I got the same error with u , Did u solve the problem?
thanks
From Agnes
*** Sent via Developersdex http://www.codecomments.com ***|||Hi Agnes,
Unfortunately I never have got an answer to this post. I also posted
similar requests to other forums, but I never have got any answer. So
our problem still persists.
Regards.
Daniel.
Wednesday, March 7, 2012
function call acting odd
worked fine (since 2003 as a matter of fact). Now, if I create a view using
Enterprise Manager and call this function, I get an erroneous error message
about needing to convert a data type. If I write the same query in query
analzyer, however, it works as expected. Prior views and stored procedures
that call this function continue to work as expected. Any suggestions on
what is going on here? Is this SP4 related or something else?> create a view using Enterprise Manager
I strongly recommend sticking with Query Analyzer for this kind of task. EM
is fine for look-see and administrative type tasks, but I do not think it is
the optimal tool for script or data management.
A|||Aaron,
Query Analyzer may be the better choice but the point is that EM no longer
works as it did in the past, which tells me there is a problem somewhere.
Thanks anyway.
"Aaron Bertrand [SQL Server MVP]" wrote:
> I strongly recommend sticking with Query Analyzer for this kind of task.
EM
> is fine for look-see and administrative type tasks, but I do not think it
is
> the optimal tool for script or data management.
> A
>
>|||> Query Analyzer may be the better choice but the point is that EM no longer
> works as it did in the past, which tells me there is a problem somewhere.
And if you service your Yugo, its behavior may change also. Doesn't mean
you should have ever had a Yugo in the first place. :-)
Friday, February 24, 2012
Full-Text Search Error - Server: Msg 7635 The Microsoft Search service cannot be administered un
Hello and thank you for your assistance.
I have two instances of SQL Server 2000 Enterprise Edition (SP4) database running on Windows 2000 Enterprise server. The default instance is dev and a named instance for QA. Full-text search is enabled for dev and is functioning properly.
@.@.Version:
Microsoft SQL Server 2000 - 8.00.2040 (Intel X86) May 13 2005 18:33:17 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
I am trying to enable full text search in the QA instance with this command: "sp_fulltext_database 'enable' ", but I am receiving the error "Server: Msg 7635 The Microsoft Search service cannot be administered under the present user account.
I can find any reference to what account it needs to run under. Can you provide me with info on why I am getting this message?
This is a common error with SQL Server 2000 Full-text Search (FTS) and the MSSearch service and there can be a few root reasons for it.
1. Did this error occur after a service pack upgrade? If so - review the files and folders under \FTDATA (in the sql server installed instance folder) against what is on your SQL Server 2000 CD. If you find any difference - copy the missing or different file from the CD to the problem server.
2. Have you removed the BUILTIN\Administrators login? If so - either add it back in or execute the sp_grantlogin from the code below as the MSSearch service requires this level of access to the MSSQLServer service.
3. Check these:
317746 PRB: SQL Server Full-Text Search Does Not Populate Catalogs
http://support.microsoft.com/kb/317746
277549 PRB: Unable to Build Full-Text Catalog After You Modify MSSQLServer Logon Account Through Control Panel
http://support.microsoft.com/kb/277549
4. Can you run this script and post the results back?
use master
go
SELLECT @.@.version
go
-- many need to set on "show advanced options"
sp_configure 'default full-text language'
go
SELECT FullTextServiceProperty('ResourceUsage') as MSSearch_Resource_Usage
go
xp_logininfo 'BUILTIN\ADMINISTRATORS', 'members'
go
-- if you have removed the BUILTIN\Administrators login, run:
exec sp_grantlogin N'NT Authority\System'
exec sp_defaultdb N'NT Authority\System', N'master'
exec sp_defaultlanguage N'NT Authority\System','us_english'
exec sp_addsrvrolemember N'NT Authority\System', sysadmin
5. And just to cover all the bases, when you changed the MSSQLServer startup account, did you do it via Win2K's Component Services? If so, could you "re-change" it via the Enterprise Manager's server property security tab?
Filip Skakun
|||Filip,
Thank you so much for your response. To answer your questions; No we haven't added any service packs recently. Yes, we do have the Builtin/Administer removed and the NT Authority has all the required privileges. Keep in mind that the default instance was working just fine.
Since the MSSQL$Inst2/FTData directory didn't exist; I suspect that FullText search was not installed with the second instance. None the less, I re-installed fulltext search (see http://support.microsoft.com/kb/827449). After doing this I no longer received the "Cannot be administered under the present account" error and the FTData directory was created for the second instance. But, at this point Full text search didn't work for both instances. I wasn't receiving any errors, but the catalogs were not getting populated. We later found that the switch in the KB article was incorrect for our servers. The article had us run "ftsetup.exe SQLServer$Instance 1 0 0 0" (incorrect). After we ran "ftsetup.exe SQLServer$Instance 0 1 0 0 0" (correct) FullText search began to function correctly for both instances.
To be honest, I don't think I had to reinstall everything. I believe I could have gotten away with just running ftsetup.exe for the second instance.
|||I am glad you got it working,
Regards,
Filip
Full-Text Search Error - Server: Msg 7635 The Microsoft Search service cannot be administered un
Hello and thank you for your assistance.
I have two instances of SQL Server 2000 Enterprise Edition (SP4) database running on Windows 2000 Enterprise server. The default instance is dev and a named instance for QA. Full-text search is enabled for dev and is functioning properly.
@.@.Version:
Microsoft SQL Server 2000 - 8.00.2040 (Intel X86) May 13 2005 18:33:17 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
I am trying to enable full text search in the QA instance with this command: "sp_fulltext_database 'enable' ", but I am receiving the error "Server: Msg 7635 The Microsoft Search service cannot be administered under the present user account.
I can find any reference to what account it needs to run under. Can you provide me with info on why I am getting this message?
This is a common error with SQL Server 2000 Full-text Search (FTS) and the MSSearch service and there can be a few root reasons for it.
1. Did this error occur after a service pack upgrade? If so - review the files and folders under \FTDATA (in the sql server installed instance folder) against what is on your SQL Server 2000 CD. If you find any difference - copy the missing or different file from the CD to the problem server.
2. Have you removed the BUILTIN\Administrators login? If so - either add it back in or execute the sp_grantlogin from the code below as the MSSearch service requires this level of access to the MSSQLServer service.
3. Check these:
317746 PRB: SQL Server Full-Text Search Does Not Populate Catalogs
http://support.microsoft.com/kb/317746
277549 PRB: Unable to Build Full-Text Catalog After You Modify MSSQLServer Logon Account Through Control Panel
http://support.microsoft.com/kb/277549
4. Can you run this script and post the results back?
use master
go
SELLECT @.@.version
go
-- many need to set on "show advanced options"
sp_configure 'default full-text language'
go
SELECT FullTextServiceProperty('ResourceUsage') as MSSearch_Resource_Usage
go
xp_logininfo 'BUILTIN\ADMINISTRATORS', 'members'
go
-- if you have removed the BUILTIN\Administrators login, run:
exec sp_grantlogin N'NT Authority\System'
exec sp_defaultdb N'NT Authority\System', N'master'
exec sp_defaultlanguage N'NT Authority\System','us_english'
exec sp_addsrvrolemember N'NT Authority\System', sysadmin
5. And just to cover all the bases, when you changed the MSSQLServer startup account, did you do it via Win2K's Component Services? If so, could you "re-change" it via the Enterprise Manager's server property security tab?
Filip Skakun
|||Filip,
Thank you so much for your response. To answer your questions; No we haven't added any service packs recently. Yes, we do have the Builtin/Administer removed and the NT Authority has all the required privileges. Keep in mind that the default instance was working just fine.
Since the MSSQL$Inst2/FTData directory didn't exist; I suspect that FullText search was not installed with the second instance. None the less, I re-installed fulltext search (see http://support.microsoft.com/kb/827449). After doing this I no longer received the "Cannot be administered under the present account" error and the FTData directory was created for the second instance. But, at this point Full text search didn't work for both instances. I wasn't receiving any errors, but the catalogs were not getting populated. We later found that the switch in the KB article was incorrect for our servers. The article had us run "ftsetup.exe SQLServer$Instance 1 0 0 0" (incorrect). After we ran "ftsetup.exe SQLServer$Instance 0 1 0 0 0" (correct) FullText search began to function correctly for both instances.
To be honest, I don't think I had to reinstall everything. I believe I could have gotten away with just running ftsetup.exe for the second instance.
|||I am glad you got it working,
Regards,
Filip
Full-Text Search Error - Server: Msg 7635 The Microsoft Search service cannot be administere
Hello and thank you for your assistance.
I have two instances of SQL Server 2000 Enterprise Edition (SP4) database running on Windows 2000 Enterprise server. The default instance is dev and a named instance for QA. Full-text search is enabled for dev and is functioning properly.
@.@.Version:
Microsoft SQL Server 2000 - 8.00.2040 (Intel X86) May 13 2005 18:33:17 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
I am trying to enable full text search in the QA instance with this command: "sp_fulltext_database 'enable' ", but I am receiving the error "Server: Msg 7635 The Microsoft Search service cannot be administered under the present user account.
I can find any reference to what account it needs to run under. Can you provide me with info on why I am getting this message?
This is a common error with SQL Server 2000 Full-text Search (FTS) and the MSSearch service and there can be a few root reasons for it.
1. Did this error occur after a service pack upgrade? If so - review the files and folders under \FTDATA (in the sql server installed instance folder) against what is on your SQL Server 2000 CD. If you find any difference - copy the missing or different file from the CD to the problem server.
2. Have you removed the BUILTIN\Administrators login? If so - either add it back in or execute the sp_grantlogin from the code below as the MSSearch service requires this level of access to the MSSQLServer service.
3. Check these:
317746 PRB: SQL Server Full-Text Search Does Not Populate Catalogs
http://support.microsoft.com/kb/317746
277549 PRB: Unable to Build Full-Text Catalog After You Modify MSSQLServer Logon Account Through Control Panel
http://support.microsoft.com/kb/277549
4. Can you run this script and post the results back?
use master
go
SELLECT @.@.version
go
-- many need to set on "show advanced options"
sp_configure 'default full-text language'
go
SELECT FullTextServiceProperty('ResourceUsage') as MSSearch_Resource_Usage
go
xp_logininfo 'BUILTIN\ADMINISTRATORS', 'members'
go
-- if you have removed the BUILTIN\Administrators login, run:
exec sp_grantlogin N'NT Authority\System'
exec sp_defaultdb N'NT Authority\System', N'master'
exec sp_defaultlanguage N'NT Authority\System','us_english'
exec sp_addsrvrolemember N'NT Authority\System', sysadmin
5. And just to cover all the bases, when you changed the MSSQLServer startup account, did you do it via Win2K's Component Services? If so, could you "re-change" it via the Enterprise Manager's server property security tab?
Filip Skakun
|||Filip,
Thank you so much for your response. To answer your questions; No we haven't added any service packs recently. Yes, we do have the Builtin/Administer removed and the NT Authority has all the required privileges. Keep in mind that the default instance was working just fine.
Since the MSSQL$Inst2/FTData directory didn't exist; I suspect that FullText search was not installed with the second instance. None the less, I re-installed fulltext search (see http://support.microsoft.com/kb/827449). After doing this I no longer received the "Cannot be administered under the present account" error and the FTData directory was created for the second instance. But, at this point Full text search didn't work for both instances. I wasn't receiving any errors, but the catalogs were not getting populated. We later found that the switch in the KB article was incorrect for our servers. The article had us run "ftsetup.exe SQLServer$Instance 1 0 0 0" (incorrect). After we ran "ftsetup.exe SQLServer$Instance 0 1 0 0 0" (correct) FullText search began to function correctly for both instances.
To be honest, I don't think I had to reinstall everything. I believe I could have gotten away with just running ftsetup.exe for the second instance.
|||I am glad you got it working,
Regards,
Filip