My boss is thinking about us getting certs even though he does know perfectly our skill (I have been here for 4 years, the "most recent" colleague has been here for 2); there are two main reasons for this: 1) There's always something you can learn from anything, even from an exam :) 2) We can tell our customers we are certified in this and that; maybe, this could be the most imprtant reason. I recognize this is a psychological more than technical reason, but if it helps to gain a customer... Anyway, once you plan with your boss the time to dedicate to your training (obviously you will have to delay your normal activities in order to study and practice), I cannot see what harm can this do to you.

Marco Turrini

I mostly agree with you and still... I listen music while working! The fact is that I work in a very distracting environment (five people in a small office, phone calls, people coming in...) and music is the only practical way to isolate myself from such a mess. Of course some genres are better than others: classical and new age are way preferable over pop/rock.

Marco Turrini

Personally, I vote for Axosoft's OnTime: they sell an Express version - 5$ for 5 users - which fits almost all our needs: beside the number of users, the two main disadvantage are that there's no customer portal (this lack is a plus for me, because actually we have no filter between customers and developers) and you cannot customize the built-in reports. We've been using it for more than a year and we are very happy with it: it's not limited to bugs and incidents, but can track feature requests and task, integrates with SCM... but if you want check it at www.axosoft.com[^] . We also tried Bugzilla, but - that's my own personal opinion - they are comparable as a car and a bike can be: before someone flames me, I know Bugzilla is totally free and not users limited, while OnTime is a commercial software. Moreover, I tried Bugzilla after having tried OnTime so my expectation bar was set to a rather high value. Cheers

Marco Turrini

While I can understand your feelings about this test, I think they could have a use to cut off part of the applicants. I was once assigned a new co-worker who was supposed to help me in writing a brand new application; after I spend a week teaching him every basic skill of... VB.Net, I had to explain him how to write a simple for loop: we had to leave him, to search for someone more skilled (maybe he was a PHP or Cobol guru, but this was not helpful to us). After that experience we decided to ask applicants to write some trivial code: of course, this code is totally useless in real world applications, but we can understand if the applicant is totally new to the technology (we may still be interested in him, but at least we'll know we need to spend some time in her education) or is readily deployable in our development team. Of course, this method is not perfect and is not the only criteria to choose among candidates. Just hope it helps you to recover from your "madness" :-D :cool:A Merry Christmas to All!:cool:

Marco Turrini

If it is really very long, you can split in different articles/sections. But I generally prefer one long article with everything I need to know rather than a series of article I have to put toghther by myself to get all the informations; but that's just my opinion of course and indeed I never skipped an interesting series of articles just because it was splitted.

Marco Turrini

Yeah, another point for the importance of a good and reliable "backup"...:cool:

Marco Turrini

My experience with women is not a vast one :-O , but - as it happens in computer programming - the error is born much before the error is shown: when you see it, it's definetely too late to debug:confused:... you can only deliver a patch :sigh: , and only after that you can try to figure out what really happened:confused::confused:

Marco Turrini

Women are wonderful, my best friends are women, and I really love most of them; still I would remove that mysterious method which produces such a weird situation: Me: -Are you angry? She: -NO! [silence] Me: -Did I do something wrong? She: -NO! [silence again] Me: -Did I say something wrong? She: -NO! [guess what? silence!] Me: -Er... Did I not do something right? She: -NO! [silence] Me: -Did I not say something right? She: -NO! [silence] Me: -Did I do and/or say something which is not wrong by itself but I should have known perfectly that in this particular moment of our lifes has to be interpreted as total or partial loss of interest or respect of you?(*) She: -Maybe... (*) If you cannot understand what I'm writing here, it's not because of my English: when I reach this "level" I loose total control of my speech even in my own language!

Marco Turrini

.jpg wrote:

Besides, anyone know of any big app written in .NET?

Paint.NET Wink RSS Bandit Axosoft's OnTime Red Sql Packager (and the other programs of the suite to manage Sql Server) Apex Sql Doc (and the other programs of the suite to manage Sql Server) BiitSoft CMS Encore Idera Sql Permissions and (I wouldn't bet more than a dime, though) I remember to have seen "suspicious" *.manifets files in a PowerQuest Partition Magic installation and, above all of them, all the programs I write:cool:

Marco Turrini

jschell wrote:

I believe you are missing the point.

And I believe you are missing the point, the starting one, to be precise. I replied to Jeremy Fowler who stated that, looking at the big picture, a 'Y' or 'N' value is more understandable from the end-user point of view when printing reports. It wasn't me the one who suggested that boolean value where input and shown directly to the end-user. I just argued that one should not show directly boolean values (and someone else added enum values) to the end-user, for reasons I won't repeat. Although I appreciated your thouroghly lesson above, I can't understand what this has to do with defending the use of a char data type for boolean value: if you like it, you can use char data type in your database to express anything (date, currency, integer); then there's a layer which converts database data to the correct application data (and type). But if I have such a layer, why shouldn't I use a bit data type in the database to express boolean values? Much more than your lesson (with which - believe it or not - I agree much more than you think, but I suspect that we have seriuos communication problems), I find that using a char(1) could be preferable just in two circumstances: 1) you have to mantain the application in a database which doesn't support bit data type (someone else cited Oracle); but if you use a data access layer (call it ORM or whatever you like), this shouldn't be a real issue. 2) you want to build an index based on that value; but you may incur in a severe performance paylod.

Marco Turrini

jschell wrote:

Interesting analogy which is really a bad one. Unless you are suggesting that true and false is going to "grow" in to a tri-state value.

Stretching too much it's meaning, a tri-state could be handled by allowing null values; but I actually would never do that. The analogy referred to the fact that "it's always been like this" isn't a really string argument, IN MY PERSONAL AND HUMBLE OPINION, of course. But anyone is free to act as he likes, unless he hurts someone [else?]. There are lot of applications happily using char representation of data, some store directly the entire description of the enumeration or foreign keys (I've also seen date stored as char in the ISO format for sorting reason).

jschell wrote:

First if you are talking about display values, such as in a GUI, then there is something wrong with your design.

You can take for granted, but maybe for other reasons, since I think I didn't express properly: 1) If I need to display "custom" values, I use a foreign key on another table; what I call enumerations are values which are invariant, regardless of the culture: just as a very quick example I may have an enumeration which tells me if it's an invoice or a refund to guide the flow of the program; then I have a separate table to store descriptive values for documents: I may have several types of invoices with different description, all of type 0=Invoice, refunds of type 1, and so on (it's just a quick example, not a full analysis). In the terminology we use in our company enumerations are NOT stored anywhere - but we use this terminology just to clearly tell them from foreign table; they are usually shown - if they really are - just in applications accessed only to higly trained staff, usually ourselves (trained on our application, I mean, not generally, of course) . 2) I'm not claiming that every single value in my database is written in such a way that it is appropriate for other languages; my attempt is to avoid to be tied to a particular language/culture in the database

jschell wrote:

Is the Italian version of the MS SQL Server going to display the 'bit' in French?

Mais ouis, with a very naive accent:-D Of course, not, it shows just 0 and 1. But what happens in Italy when someone from France uses a char(1) in Italy, to see her O(uis) refused by the Italian constraint applied by the dba

Jeremy Fowler wrote:

However, from the customer's point a view a 0 or 1 does not look nice in a report. You have to take a step back and look at the big picture.

Please, don't misunderstand me but, just looking at the big picture, I can assure you that a char field is not necesseraly clearer to an end user than a bit one. I'm working with Italian, French, German and Arabic speaking end user and to very little of them a 'Y' would be a readable representation of a True value: you can't assume they studied English at school (e.g., in Italy a stident can study English or French) and anyway you can't bet they really know English (maybe it was centuries ago...); some of them would also be offended that my db doesn't allow them to store their national True value, but that's - partially - another story; a 0 or 1 field is much more ... neutral and doesn't leave room for misunderstanding or errors (once you have trained them, of course). As someone else stated, even enum values are stored as integer... or are you going to store their description? I don't think so...

Marco Turrini

jschell wrote:

Yet oddly enough many implementations use it quite successfully.

They used to say the same for years expressed with two digits. Of course the problem is the user: the fact is you can't be assured your user (and I mean either the developer and the end user) are educated enough. Using a [var]char lets doors open for a end user or a developer to write "dirty" values: who said that the only two chars are to be 'Y'es and 'N'o; in Italy we say 'S'i and 'N'o, in France they say 'O'ui and 'N'on, in Germany 'J'a and 'N'ein, in Russia 'D'a and 'N'iet (I think) Why only 'Y' should be used for the True value? If you think this is irrilevant, I'm writing right now an application which is already shipped in Italian/Italy and will be in German/Italy and French/Algeria

jschell wrote:

Given that the OP already mentioned that constraints are in use I can't see how there are going to be many problems introduced in the SQL code itself.

Because you can't assume that nobody will ever access data with something else than your application (the Business Logic you implemented in your OP application). Besides Microsoft ones, at least two free tools come to my mind which let you access directly data. To avoid this, you have to implement several procedures; among these is the correct use of the proper data type. That said, of course there are lot of applications which use char to store boolean value. As far as I am concerned, they can store everything as [var]char: boolean, dates, enums, timestamps and currency values... it's someone else's database and application, and I will not have to mantain it, nor wish to.

Marco Turrini

dokmanov wrote:

One consideration may be indexability of the bit vs. char field

That's correct; Sql Server can't index bit fields. I don't know if this is a real issue: I guess most of the time it shouldn't be, but "most of the time" doesn't mean "always" (if my English is not getting worse than ever). In my experience, bit fields are more useful to "filter" data rather than "sort" it (I'm sure that, no more than one hour from now, my boss will ask me a "little" modification which will really need a sorting on a bit field).

dokmanov wrote:

we want to indetifiy the small percentage of active records

Well, a simple WHERE clause should be enough. Surely is better than having a referenced table, unless you want to use arbitrary values (and these values can be edited, added and removed - with all the risks related to this) By the way, the other side of the small percentage of active records is a huge percentage of inactive ones (i.e., with the same index value).

dokmanov wrote:

Personally, my experience tells me that the highest cost occurs from the database getting invalid data put into it.

I couldn't agree more with you!

dokmanov wrote:

I also like to use FKs, but our DBAs reject them for performnce reasons, too.

Yes, but they exists and if used properly can do a great work for you. Usually they are preferable when values are not known by the programmers, but by the user (I don't know how people will categorize books, for instance) rather than to narrow the possible values, because a table can be edited and therefore there's the possibility that someone adds a '@' or a '^' to your 'Y' and 'N' table.

Marco Turrini

Believe it or not, I do agree with you;) Just a little thing: in my extremely humble opinion (well, if I were actually so humble, I would not express my opinion) building an application requires both the skills of the programmer and of a dba (a better dba would be welcome) balancing each other: if an application were totally led by a dba, or a programmer, problems would be just around the corner. (By the way, I'm playing both roles in my company:cool: I always have another "side of me" to point the finger to when something goes wrong:))

Marco Turrini

malharone wrote:

Furthermore, the "varchar" for boolean strangely made into the "SQL Standards" document in the company

1. Leave that company as soon as possible 2) Using char(1) for a boolean is stupid enough, but using varchar is even worse: varchars are introduced by two bytes used to specify the actual length of the data in the row, so a varchar(1) is actually consuming 3 bytes, not 1 as you would probably expect; on the other hand, bit fields use just 1 bit (and, if memory doesn't fail me, Sql Server can group them in bytes) 3) Using [var]char introduce wide possibilities for unnecessary errors and runtime exceptions.

Marco Turrini

May I post my resumé? :) I use bit for booleans, tinyint for enums and smalldatetime for datetime when seconds are irrilevant. Oh, and I use to unlock the office in the morning and lock it at night (but no, I don't clean it):-D

Marco Turrini

I do totally agree your anti-Symantec bias. I uninstalled it three years ago: it took several steps, trials and errors, I had to download a bunch of uninstalling appls from Symantec then decided it was safer (even though longer) to re-format my system disk and reinstall everything, but NAV. I installed a free version of another antivirus and I never had to worry : it also seemed to find viruses in the coming mail, the same messages NAV was not able to detect a week before. But, just as a curiosity... did you notice the sponsor in the top area of the site? -- modified at 3:46 Friday 31st August, 2007

Marco Turrini

Thanks a lot, anyway. At least, now I know someone has actually read the message (I'm starting to cry:)...)

Marco Turrini

Woah, I'm nearly fainting... I'm correct:-D (yes, about such a little issue, of course) I do agree that Cobol has been developed for specific purposes; after all, there were some reasons if it was named COmmon Business Oriented Language. And in some previous message, I said that a good Cobol programmer will sure do a better job (a program working better and easier to read and mantain, even by other people) than a bad (or even average) OO programmer: it's the human factor, not the tool which makes the difference. Things always have another side: the copy statement is either an asset and a liability, and it's up to you (the human factor) to take advantage of the asset and reduce the payload of the liability. In my previous experience this has been a big liability because whenever I was told to update module XXX, they always forgot to tell me the complete list of the module using (say) the invoices data: I know, an human error was the definitive guilty of my pain. At least, OO reduces (not to zero, of course) this possibility of error just by considering objects like black boxes: you aren't allowed to look inside of them, you aren't allowed to damage them, you know what you can expect: of course, it's up to the human factor to make this an asset or a liability. Again, I remember writing (including or copying) then same lines of code to skip one record ahead of the table: I had to write a READ-NEXT-xxx for each table the program used (READ-NEXT-CUSTOMER, READ-NEXT-INVOICE, READ-NEXT-ITEM, READ-NEXT-CURRENCY...),a READ-FIRST-xxx, a READ-PREVIOUS, and this was repeating code: the asset is that if you (ok, I, didn't mean to offend) write a bug in a READ-NEXT routine this bug would not affect any other READ-NEXT routine; the liability is that a bug could be very hard to find (the worst scenario is when you have several different bugs in rarely used routines: I spent half of my salary in medicines). On the other hands, OO helps you writing a base class to access data a minimal set of common properties and methods and then deriving from that class for the proper behaviour tipical of that object (data table, roughly): the liability is that if you write a bug in a general routine, you corrupt every table in your application; the asset is that it's generally easier to write tests, find and debug things. I'm not interested too in discussing each fine detailed: I just mean that Procedural Programming and Object Oriented Programming use two slightly different point of views. To put in just few words, the former