Not a valid Win32 application

New to SQL Server installations. I downloaded the SQL Server Express with Advanced; when I double click the Setup.exe, I get a pop-up "document path/file is not a valid Win32 application". I upgraded from XP Home to XP Pro SP2.0. Any suggestions?Seems like the downloaded exe is corrupt. Download it again.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

Not a Number Values in the Database

Our application has a table, which is populated via ADO.Net from C# with data originating from a C++ COM call. Today I encountered an entry that is C++ code for an undefined value: -1.#IND stored in the database. However, I could only discover what was stored in the table by Casting the value to a varchar -- simply selecting returned an error.

Is this expected behavior or a bug? It does not seem correct that SQL Server should store a value that cannot be displayed. In essence, either the value should not be allowed in the table because it violated the domain or SQL Server ought to have a way to display it with a Select *.

As fas as our application is concerned, we will be masking these values -- initially by ignoring them in the queries and eventually the loading program will convert to null.

What is the defined datatype for the field?|||

The column in question is a float column.

I would argue that the datatype should not be that important. The server should not allow a value to be stored which cannot be displayed.

|||

IND could be (COULD BE) referencing the unicode index control character. It looks like you had some sort of odd data transformation from the COM-C++-C#-SQL conversion process, especially considering it's a floating point variable which can lose precision through casting, it didn't surprise me to see that that was the data type in question.

Have you considered testing that single row by running it through your conversion process again by itself? Is the original float data for the column and row something... unusual?

|||

Hmm, very interesting. Try casting it to a numeric of some sort (particularly really large precision after the decimal)... That might give the clue. What datatype are you using in your C# application? And what prints out when you select from the column in Management Studio?

I can't imagine there is any value that is illegal for a float, but stranger things have happened.

|||

The specific data in the database was purged, due to some maintenance, so I'll have to see if it returns.

However, I made a simple example:

static void Main(string[] args)

{

double d = Double.NegativeInfinity;

using( SqlConnection conn = new SqlConnection( "server=(local);initial catalog=Northwind;integrated security=true" ) )

{

SqlCommand cmd = new SqlCommand( "Insert Foo(zero, one) Values( Datepart(mi, getdate() ),@.val )", conn );

cmd.Parameters.Add( "@.val", d );

conn.Open();

int rows = cmd.ExecuteNonQuery();

Console.WriteLine( rows );

}

Console.WriteLine( d );

}

with a target table:

Create Table Foo(

zero int not null,

one float null

)

Using any of Double.NegativeInfinity, Double.PositiveInfinity, or Double.NaN gives an odd result. The code succeeds and reports that a record has been added. However, the command Select * from Foo will not return records with these values. The values cannot be displayed by Casting to a numeric type, but output is produced by Casting to a varchar.

Using Select Count(*) from Foo will report the correct number of records.

|||

If you worked with MDX queries (analysis server), it is very common issue.

When you store the INDEFINITE/INFINTE value into your variable, compiler uses the special values to identify the INDEFINITE/INFINTE number/value,

1. 1.#IND (positive indefinite) or -1.#IND (negative indefinite)

2. 1.#INF (positive infinite)or -1.#INF (negative infinite)

Both are used to identify the compiler the variables hold the INDEFINITE/INFINTE, usally when you try to divide by zero it will be throw an error. But here you are forcefully stroring the infinite value. It is the compiler specific data. It can’t trusted across the compilers. So when you execute the code on your .NET framework will work fine. When try to pass this value into SQL Server it doesn’t understand, there is no specification available to identify the indefinite value in database.

Logically you can have nothing in your column (NULL/ZER0), but you are not allowed to store indefinite value in your column. Indefinite values are not comparable, these are imaginary values. But database store the masseurable values.

Solution:

Before passing the value to your database, validate the data, if it is INDEFINITE/INFINTE reset the value to NULL or other identifiable value for your future logics...

|||

I know you are a moderator, but as a general rule the thread creator should close threads. Being a moderator does not automatically make your information infallible.

As a matter of fact, on this issue you did not really add any additional information to the thread other than that you have experienced the issue as well.

I would now contend that this is, in fact, a bug in the SQL Server implementation. Either these values -- NaN, PositiveInfinity, and NegativeInfinity -- should be excluded from the domain of the Float datatype and rejected on Insert; or they are included in the domain and should be handled in a logical and consistent manner -- certainly they should have a display representation and they should have defined behavior in functions.

The current implementation is just a landmine waiting to go off at inopportune times.

|||

I marked the thread as 'answered'. As a 'general rule', we all take responsibitly to close a thread when there doesn't seem to be anymore 'interest' and/or it appears to be adequately 'answered'. And anyone can choose to 're-open' that thread by 'unmarking' the marked 'answer'. It's just a 'housekeeping' matter to help focus limited resources (the time and energy of volunteers) to the active and unanswered threads.

It appeared that Mani provided an adequate explanition for the behavior, and it seemed to me to be doubtful if there could be a 'solution' posted for your question. It appears that there to be a 'anomoly' involved in this situation -concerning a C++ interaction with the datastore, but I haven't been able to locate a declared 'bug' about the issue. (Doens't mean it's not there, just that I haven't devoted enough time to find it if it exists.) Mani's response satisfied the need to provide information to subsequent readers of the thread.

My mistake was in not encouraging you to post a 'potential' bug. I'll correct that now.

Please go to: http://connect.microsoft.com/sqlserver and post your observations and concerns. With everyone's keen interest and help to provide feedback and critique, the SQL Server will only continue to get better.

If you want this thread to stay 'open' to see if additional comments are forthcoming, that is perfectly fine.

As a postscript, let me add that there is often an issue of 'the' answer. We work on the concept of helping the questioner find a way to solve his/her problem. At some point, one has to say, ok, maybe there is a 'better' answer, but what is here now works, so lets move on.

|||

I have found more information on the issue:

First to clarify, the issue is not restricted to C++ interaction. The code I show above is C# and can be used to demonstrate the behavior when NaN or Infinity is stored in the database. Furthermore, I was surprised to find out that the data can be read out with a query from a C# program. My code and example were run against Sql Server 2000.

Looking on Microsoft Connections, I found an interesting item. It appears that MS has chosen to no longer support NaN and Infinity in the database in SQL Server 2005. In fact, a request had been made to restore the 2000 functionality. There is, at least, one organization which is using SQL Server to store engineering data and who has the need to occassionally store Infinities in the database. Evidently they are not performing any ad hoc queries or calculation within the database.

I plan to post a recommendation that MS embrace full support for the IEEE floating point numbers rather than simply disallowing them. It seems like the best, long term, behavior for the database and would be keeping in line with industry trends. Ideally, some form of patch would be made available for SQL 2000 to more gracefully handle NaN or Infinity when it is entered in the database.

|||Yes, this is a behavior change from SQL Server 2000. We now validate float values and Unicode data when you pass them via RPC calls or Bulk Copy APIs. So for float even though values like NaN and Infinity is allowed in the IEEE 754 spec (floating point implementation) we do not allow it now. Upon upgrade to SQL Server 2005 from older versions you need to modify the data in your tables to use them within TSQL. TSQL does not support any way to query these type of data or manipulate it explicitly - older SQL Server versions used to just allow them to be stored but you can only manipulate it on the client-side.|||

Is there a strong reason to not implement full support for the IEEE 754 spec? It specifies the rules for all operations involving the extra values. Some external representation of the values would be needed, but that has been solved for C# already.

It is a little surprising that it is not easier to support them than to prevent them. I assume that much of the Server software is written in a high level language that supports IEEE floats.

With competing products already supporting IEEE floats, the change seem inevitable.

Thanks for your input.

|||

I agree with your assessment. It is really unfortunate that we do not support it yet. Did you vote on the connect bug at https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=239674? I would also encourage anyone reading this thread to vote on this bug. The issue today is that several built-ins in SQL Server (those that work with floating point data) and other facilities cannot handle these values. I will follow-up with the owner of this bug and see if we can do anything about it in SQL Server 2008.

sql

Normalize multivalue field?

Hi,
I have a table I'm importing from access; the application that used
the table has some fields that are multivalued, separated by either
a ; or the sequence /* Ugly.
I can write a C# app to take the columns and stuff the data into my
normalized schema, but I was wondering if there was any good way to do
it in sql.
Thanks,
AndyOn Sep 7, 12:57 pm, Andy <an...@.med-associates.com> wrote:
> Hi,
> I have a table I'm importing from access; the application that used
> the table has some fields that are multivalued, separated by either
> a ; or the sequence /* Ugly.
> I can write a C# app to take the columns and stuff the data into my
> normalized schema, but I was wondering if there was any good way to do
> it in sql.
> Thanks,
> Andy
Look up Erland Sommarskog's article "arrays and Lists in SQL"|||The best approach is to clean up the data to represent one value per column.
If, by any chance, you are forced to deal with such designs, you'll have to
resort to one of the string parsing approaches. Some of them can be found
at:
www.projectdmx.com/tsql/sqlarrays.aspx
www.projectdmx.com/tsql/rowconcatenate.aspx
--
Anith

Normalization question

Hello,

I'm building an OLTP employee roster application, and I have the data model normalized, but I'm finding it challenging to update the data in all of the underlying tables via a web form and stored procedures. I'm getting the direction to keep things normalized, but I'm struggling with table updates.

Is it sound OLTP database practice to write records to a "roster_data" table that is a foreign key repository for all of the underlying tables (almost like a view without the update restrictions)? It would be much easier to manage this table of foreign keys (fact table) instead of writing several stored procedures to keep all of the related tables (dimensions) updated. (almost like a star schema in OLAP)

I know I'm being vague, but I would like to bounce off some OLTP experts.

Thanks,

Jim

What type of data is being changed?

Is it key data?

Would CASCADE UPDATE work?

More information, table DDL, etc., would be useful.

|||

Not that you are a beginner in normalization topic, but the following links should get you the idea in thsi regard:

http://www.informit.com/articles/article.asp?p=27785&rl=1 & http://www.sqlmag.com/Articles/Index.cfm?ArticleID=4887

|||

Everyone,

My basic issue was keeping my underlying normalized data model updated via one VIEW, and I was running into the "can't updated more than one base table issue." After some research, I found the INSTEAD OF triggers -- this functionality will enable me to update all of my underyling tables using one VIEW.

Thanks everyone and have a great holiday!

Jim

Non-Unicode to Unicode Data conversion

Hi all, we are now planning to upgrade our application from a
non-unicode version to a unicode version. The application's backend is
a SQL Server 2000 SP3.

The concern is, existing business data are stored using collation
"Chinese_PRC_CI_AS", i.e. Simplified Chinese. So I thought we need to
extract these data out to the new SQL Server which is using Unicode (I
assume it means converting them to nchar, nvarchar type of fields for I
don't enough information from the application side, or is there a
general unicode collation that will make even char and varchar types to
store data as Unicode?).

The problem is what's the best and most efficient way to do this data
conversion?
bcp? DTS? or others?

thanks a lotNew MSSQL DBA (boscong88@.gmail.com) writes:
> Hi all, we are now planning to upgrade our application from a
> non-unicode version to a unicode version. The application's backend is
> a SQL Server 2000 SP3.
> The concern is, existing business data are stored using collation
> "Chinese_PRC_CI_AS", i.e. Simplified Chinese. So I thought we need to
> extract these data out to the new SQL Server which is using Unicode (I
> assume it means converting them to nchar, nvarchar type of fields for I
> don't enough information from the application side, or is there a
> general unicode collation that will make even char and varchar types to
> store data as Unicode?).

You will have to move to nchar/nvarchar.

> The problem is what's the best and most efficient way to do this data
> conversion?
> bcp? DTS? or others?

One idea would be to create a new database on the same server, with
the (var)char columns changed to n(var)char columns, and then insert
data over. In this case you will get a conversion from the multi-byte
character set you use today. You would then move that database to the
new server with detach/attach or backup/restore.

You would not create indexes, constraints and triggers in the new
database, until you have copied the data.

Using BCP meand that you have to bounce over disk. Then again, bulk-
load is faster so it could still be faster. Here I cannot really say
that you will get a conversion, although I believe that you would.
(I have never converted Chinese text from double-byte to Unicode, so
I don't really know what works and what does not.)

As for DTS, I don't know DTS at all, so I can't say whether it's good or
not.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||New MSSQL DBA (boscong88@.gmail.com) writes:
> Hi all, we are now planning to upgrade our application from a
> non-unicode version to a unicode version. The application's backend is
> a SQL Server 2000 SP3.
> The concern is, existing business data are stored using collation
> "Chinese_PRC_CI_AS", i.e. Simplified Chinese. So I thought we need to
> extract these data out to the new SQL Server which is using Unicode (I
> assume it means converting them to nchar, nvarchar type of fields for I
> don't enough information from the application side, or is there a
> general unicode collation that will make even char and varchar types to
> store data as Unicode?).

You will have to move to nchar/nvarchar.

> The problem is what's the best and most efficient way to do this data
> conversion?
> bcp? DTS? or others?

One idea would be to create a new database on the same server, with
the (var)char columns changed to n(var)char columns, and then insert
data over. In this case you will get a conversion from the multi-byte
character set you use today. You would then move that database to the
new server with detach/attach or backup/restore.

You would not create indexes, constraints and triggers in the new
database, until you have copied the data.

Using BCP meand that you have to bounce over disk. Then again, bulk-
load is faster so it could still be faster. Here I cannot really say
that you will get a conversion, although I believe that you would.
(I have never converted Chinese text from double-byte to Unicode, so
I don't really know what works and what does not.)

As for DTS, I don't know DTS at all, so I can't say whether it's good or
not.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thanks for your help.

I am wondering I can do an in-place conversion by altering the char,
varchar, text columns of the original non-unicode DB to nchar, nvarchar
and ntext columns using the ALTER TABLE ... ALTER COLUMN commands.

I've done a bit of testing and it seems working. Just wondering
whether there are any catch of doing so. (of couse, will backup
everything before changes).|||Thanks for your help.

I am wondering I can do an in-place conversion by altering the char,
varchar, text columns of the original non-unicode DB to nchar, nvarchar
and ntext columns using the ALTER TABLE ... ALTER COLUMN commands.

I've done a bit of testing and it seems working. Just wondering
whether there are any catch of doing so. (of couse, will backup
everything before changes).|||New MSSQL DBA (boscong88@.gmail.com) writes:
> I am wondering I can do an in-place conversion by altering the char,
> varchar, text columns of the original non-unicode DB to nchar, nvarchar
> and ntext columns using the ALTER TABLE ... ALTER COLUMN commands.
> I've done a bit of testing and it seems working. Just wondering
> whether there are any catch of doing so. (of couse, will backup
> everything before changes).

I can't see any problems with this.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||New MSSQL DBA (boscong88@.gmail.com) writes:
> I am wondering I can do an in-place conversion by altering the char,
> varchar, text columns of the original non-unicode DB to nchar, nvarchar
> and ntext columns using the ALTER TABLE ... ALTER COLUMN commands.
> I've done a bit of testing and it seems working. Just wondering
> whether there are any catch of doing so. (of couse, will backup
> everything before changes).

I can't see any problems with this.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Non-Paged Memory leak

One of our application which uses ODBC to access SQL2000
Sp3 database (on the same machine) is leaking Non-paged
Pool memory (continuously). Can this be due to ODBC driver
problem as reported in article "814410 FIX"?
THis is happening only on few machines (SQL2000 Sp3 on
Win2K advanced Server Sp4).
Will SQL2000 Sp3a solve this problem?
I am not able to consistantly see the problem.
We observed NonPaged leak on Task Monitor after we saw
error with Event id 2019 in an event log of a machine
earlier.Dinesh
SP3a does contain a fix for 814410. See:
http://support.microsoft.com/?kbid=306908
Hope this helps.
Sal Terillo
"Dinesh" <dineshks@.infosys.com> wrote in message
news:0ac301c3617b$25682600$a501280a@.phx.gbl...
> One of our application which uses ODBC to access SQL2000
> Sp3 database (on the same machine) is leaking Non-paged
> Pool memory (continuously). Can this be due to ODBC driver
> problem as reported in article "814410 FIX"?
> THis is happening only on few machines (SQL2000 Sp3 on
> Win2K advanced Server Sp4).
> Will SQL2000 Sp3a solve this problem?
> I am not able to consistantly see the problem.
> We observed NonPaged leak on Task Monitor after we saw
> error with Event id 2019 in an event log of a machine
> earlier.
>sql

Non-admin Citrix users cannot connect to SQL Server

We have an application that accesses a SQL 2000 server that is running on
several Citrix servers. Recently users started getting a message from the
application that there was a catastrophic failure when connecting to SQL
server. This was only happening if the user was not an administrator on the
Citrix server.
I tried connecting to SQL server from Enterprise Manager and Query Analyzer.
If I was logged on as an admin it worked, but if not, it did not work. In
Query Analyzer if I tried to log on to SQL server using a bad password, I got
back a message about bad user or password. When I put in the correct
password (or if using integrated security) the screen briefly acts like it is
connecting but then the entire isqlw program shuts down. Enterprise manager
shuts down when I try to connect to a server. As a non-admin user I am able
to connect using ISQL.exe.
We've checked on rights to the SQL files and everything looks OK. Is there
anything else to check?
Thanks
LehrSJ
Hello there,
I would like to suggest you applied the SQL 2000 SP4 first.
And please let me know the error log in the SQL Server.
This issue may related with some permission of folder. If you use the SQL
Authentication to connect the SQL server, did this issue occur?
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Non standard port - non default instance

Hi all,
I'm trying to create a subscription for a merge replication on a sql
server mobile 2005 based application.
The publisher is on a intranet, listening on port 9091 and with a named
instance.
The merge agent is in a DMZ with port 9091 open for inbound/outbound TCP
traffic to the intranet.
Problem:
when I try to synchronize I receive the "SQL Server does not exists" error.
My subscription has the following setup:
Publisher = "ServerName\InstanceName";
PublisherNetwork = NetworkType.TcpIpSockets;
PublisherAddress = "10.xxx.xxx.xxx,9091";
PublisherDatabase = "DatabaseName";
PublisherSecurityMode = SecurityType.DBAuthentication;
PublisherLogin = "name";
PublisherPassword = "pwd";
name/pwd user has correct priviledges non publisher database.
I can connect via SQL Client to the database from the machine in DMZ.
In my (many) tries, I also created an alias on the DMZ client and used
that for the Publisher property at the subscriber.
Nothing worked.
I'm finishing options...
Cl@. ha scritto:

> Problem:
> when I try to synchronize I receive the "SQL Server does not exists" error.
I solved opening 1434 udp port.
Question is: why sql client can connect without 1434 port open and the
merge agent can't?

Noise words issue in full text seach Sql server 2000

Hi All,

I have been using full text search in my application for search purpose.
But on certain words i.e Noise Words such as And,After,About etc.
I am receiving the following error:

Execution of a full-text operation failed. A clause of the query contained only ignored words.

I tried a lot to sort out this issue,but this is going to be out of my scope.
If anybody can help me then it would be really appreciable.

Thanks in Advance,
Vivek RathoreFull-text maintains a list of noise words in different files which are language specific. When you receive the Msg 7619 The query contained only ignored words" SQL server has eliminated all words in the query. If you would like to search on those words you can try utilizing FREETEXT or editing the files maintaining the list of noise words.

These noise-word lists should be sufficient for most normal operations, but can be modified for specific environments with a text editor. For more information, see the Indexing Service 2.0 documentation in the Windows NT 4.0 Option Pack.

No Transaction is Active

Hi,
I have a COM+ Application written by somebody else, and when I am calling
one function, it is returning an "No Transaction Is Active". I have looked a
t
the code, and cannot see why. I have the same version of the dll running
perfectly fine on other servers, so I cannot see that it is the code that is
at fault, so I am left to believe that it is being returned by SQL Server
(SQL Server 2000, SP4).
Can anyone help explain what the error message means and why it is coming up
?
Regards
SamHi
Are you getting error numbers 3902/3903? In which case you are trying to
ROLLBACK/COMMIT without a BEGIN TRANSACTION. You may want to use SQL Profile
r
to see where this is occuring.
e.g. instances such as
http://support.microsoft.com/defaul...kb;en-us;231987
http://support.microsoft.com/defaul...kb;en-us;223213
John
"Sam Coleman" wrote:

> Hi,
> I have a COM+ Application written by somebody else, and when I am calling
> one function, it is returning an "No Transaction Is Active". I have looked
at
> the code, and cannot see why. I have the same version of the dll running
> perfectly fine on other servers, so I cannot see that it is the code that
is
> at fault, so I am left to believe that it is being returned by SQL Server
> (SQL Server 2000, SP4).
> Can anyone help explain what the error message means and why it is coming
up?
> Regards
> Sam