All --

Please help.

Why does DeleteEntity return Boolean instead of Integer?

I would think that it should return Integer, like DeleteEntitiesDirectly.

I am just curious about this.

Thoughts?

(FYI, we are using LLBLGen, ASP.NET, VS.NET 2003, VB.NET, .NET 1.1, the Adapter templates, SQL Server 2000, web services, SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll Version 1.0.20051.60516, SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll Version 1.0.20051.60628, Windows XP Pro, IIS 5.1, and so on.)

Thank you.

-- Mark Kamoski

because if it would return an int, it would always return either 0 or 1, as deleteentity deletes just 1 entity.

the routines which return an int delete 1 or more entities.

Otis wrote:

because if it would return an int, it would always return either 0 or 1, as deleteentity deletes just 1 entity.

the routines which return an int delete 1 or more entities.

I have been thinking about this a lot and that's what I thought your response would be.

However...

I think both should be uniform, returning a count/integer.

Why?

Yes, I understand that you are mapping integer to boolean; but, I don't think that mapping is necessary and I think that it confuses numeric-data with boolean-data.

As is well-known, the actual mapping of boolean to numeric can vary. In VB.NET, zero maps to False but everything else maps to True-- that is True does not just map to 1. In SQL Server, there is no actual boolean, rather we have bit, which is actually tri-state-- 1, 0, or NULL, which is not so good because it confuses matters even more.

In the current case, if BooleanFalse is meant to be zero and BooleanTrue is meant to mean 1, why not simply return an actual zero or a one?

The point is, as noted in MSDN (and probably elsewhere, and certainly as far as I am concerned), Boolean should not be used to hold a numeric value.

I don't expect you to change this; it is, perhaps, a minor point.

Regardless, I want to suggest, in a friendly way, that it should be changed.

Just a thought.

Thank you.

Reference...

I expect that most might all of this; but, I will post it for my own reference (and perhaps for others).

For SQL Server... bit Integer data type 1, 0, or NULL. http://msdn2.microsoft.com/en-us/library/ms177603.aspx

For .NET... Visual Basic Language Reference
Boolean Data Type (Visual Basic)
Holds values that can be only True or False. The keywords True and False correspond to the two states of Boolean variables. Remarks Use the Boolean data type to contain two-state values such as true/false, yes/no, or on/off. The default value of Boolean is False. Type Conversions When Visual Basic converts numeric data type values to Boolean, 0 becomes False and all other values become True. When Visual Basic converts Boolean values to numeric types, False becomes 0 and True becomes -1. When you convert between Boolean values and numeric data types, keep in mind that the .NET Framework conversion methods do not always produce the same results as the Visual Basic conversion keywords. This is because the Visual Basic conversion retains behavior compatible with previous versions. For more information, see Troubleshooting Data Types. Programming Tips Negative Numbers. Boolean is not a numeric type and cannot represent a negative value. In any case, you should not use Boolean to hold numeric values. Type Characters. Boolean has no literal type character or identifier type character. Framework Type. The corresponding type in the .NET Framework is the System.Boolean structure. http://msdn2.microsoft.com/en-us/library/wts33hb3.aspx

-- Mark Kamoski

I'm afraid I don't agree with you.

I don't see a reason good enough to use a larger dataType to return a limited set of results that a smaller dataType can do. When it comes to dataTypes, I think size does matter.

Walaa wrote:

I'm afraid I don't agree with you.

I don't see a reason good enough to use a larger dataType to return a limited set of results that a smaller dataType can do. When it comes to dataTypes, I think size does matter.

...OK, that makes some sense, in a frugal manner, but...

...SQL Server 2K BOL says @@ROWCOUNT is a Integer...

...so where is the guarantee that one is not losing resolution when casting an Integer to a Boolean?

...the fact is, with such a cast, one is using a potentially lossy cast based on an assumption... but, what assumption? ...that SQL Server will never return anything but a 0 or a 1? ...but SQL Server does not guarantee that... AFAIK... all that SQL Server 2000 guarantees, for instance, is that the return will be an Integer.

...and so on...

When DeleteEntity() is called - that entity must have a primary key - that primary key must be provided and is used for the delete, guaranteeing that either a 1 or a 0 will be in @@rowcount.

returning an int from DeleteEntity would be silly, it would return 0 or 1, i.e. a boolean

mkamoski wrote:

Yes, I understand that you are mapping integer to boolean; but, I don't think that mapping is necessary and I think that it confuses numeric-data with boolean-data. -- Mark Kamoski

If you think "Did the requested deletion succeed?" rather than "When I asked for a single row to be deleted, how many were actually deleted?" then it makes more sense for a boolean result rather than an int. And if you agree with that then the fact there is an internal conversion from an int to a bool is a private implementation detail. It could just as easily been done with an if statement.

Cheers Simon

Otis wrote:

returning an int from DeleteEntity would be silly, it would return 0 or 1, i.e. a boolean

Ah, but my point is-- a Boolean is NOT a number.

WayneBrantley wrote:

When DeleteEntity() is called - that entity must have a primary key - that primary key must be provided and is used for the delete, guaranteeing that either a 1 or a 0 will be in @@rowcount.

I think that is close, but not quite it.

The SQL Server 2000 API reads that @@rowcount will return a Integer.

It does not guarantee 0 or 1.

(If it does, please quote the source because that would be very interesting.)

it's not about sqlserver, it's about if the METHOD succeeded or not. Succeeded or not: boolean flag. True or false.

I don't know how else I have to put it. Feel free to continue this discussion though, however it won't change.

When DeleteEntity() is called - that entity must have a primary key - that primary key must be provided and is used for the delete, guaranteeing that either a 1 or a 0 will be in @@rowcount.

I think that is close, but not quite it.

The SQL Server 2000 API reads that @@rowcount will return a Integer.

It does not guarantee 0 or 1.

(If it does, please quote the source because that would be very interesting.)

What I was saying is that @@rowcount is guaranteed to return a 1 or a 0 in this case. Why?

SQL Server guarantees that if you have a primary key it will not be duplicated in that table. The delete query for a single entity uses the primary key - so at MOST it will delete 1 and the LEAST is 0, therefore it will always return a 1 or 0. This is not a 'direct' rule in SQL Server, but an inferred rule based on existing rules.

I think Frans is trying to say that we are not passing the SQL Server return of the delete operation. But true or false are the return values of our implemented method, irrelevant of the what the database server is returning.

In other ways if they (SQL Server people) decided to return 1000 for a success operation and -1000 for a failed operation. We would be checking these values and return true or false instead as the return of our method.

I think it's the best way for our function users, instead of figuring out what 1 means if returned from SQL vs as returned from Oracle, and what 1000 means....etc. We say our delete method will return true or false as simple as that. Rather than any other numeric representation that may take several forms.