Comments by KP Lee - CodeProject

KP Lee 6-Feb-14 21:44pm View

Pretty much the way I would have done it. Maybe less efficient than your code. Maybe dispense with the list altogether and just list one directory and two directories in that one. And put the files in the right directory and list the files to be read. No maintenance of lists and files, just files.

KP Lee 15-Nov-11 1:23am View

Deleted

You forgot .WriteXML(filename) to write a dataset into an XML file. You may have done that on purpose because of your additional (valid) point?

KP Lee 15-Nov-11 0:52am View

Deleted

First, your "Table_Training_Detalis" alias in your example doesn't exist so it wouldn't work. Second, it is exactly the example of when to NEVER use a cursor.

UPDATE tw set WHIMIS= tc.DateExpires
FROM Table_Courses tc
JOIN Table_Workers tw
ON tw.Worker_ID=tc.Worker_ID AND tw.WHIMIS != tc.DateExpires

Would be about 800 times faster than a cursor. If this is a high volume system where IO contention is a concern, you can use another technique about 400 times faster.

KP Lee 15-Nov-11 0:18am View

Deleted

I haven't seen any evidence of a lack of awareness of the cursor command, but I've seen plenty of evidence of when to NOT use a cursor being ignored. There are cases where a cursor is very useful, but that should be the exception instead of the rule. Think SET solution first, second, and third, then cursor.

KP Lee 21-Oct-11 23:29pm View

I'm willing to learn. I ASKED if it was a bug. If you had said something about "checked" to begin with, I'd have realized that the lazy math was intentional and not a bug at all. This is a complex language, it isn't possible to know everything to begin with. "Help" is certainly NOT a mind-reader and I'm not a mind-reader knowing what keyword to use to find the information I am interested in. Even searching the checked keyword in the index required browsing to find the compiler level version: "/checked[+ | -]" vs. scoped checked/unchecked commands. (Lazy programming is not implementing something for performance reasons, but allowing the program to do what it is supposed to in special cases like applying.)

Yes, I know the hex value of the max int value. It exactly matches the binary value which is 2^31-1. Or 1 zero followed by 31 1's. I don't bother memorizing it, didn't know bit shifting was implemented. I did bother to memorize 2^10 which is 1024 decimal. On a system that checks values, 1024*1024*1024 - 1 + 1024*1024*1024 is the easiest way for me to remember how to mathematically get there. (The Maxvalue property is handy for that.)

KP Lee 21-Oct-11 3:53am View

barneyman "SQL is simply catching the overflow and asserting a fault - a feature of that language"
EXACTLY, however it should be a feature of the OS' mathematical process. Since it ISN'T, shouldn't the burden of doing mathematical processes correctly be handled by the language? If it doesn't do so, isn't that a bug in that language? Say you had a 3 bit signed 2's comp int. The valid range of numbers is 3 to -4. Do you think it is acceptable that 3 + 1 == -4? In my book, THAT is a bug.

KP Lee 21-Oct-11 2:46am View

The stack fault was a separate issue. Not a red herring, but confusing combined with the numeric problem. So adding two positive numbers together SHOULD produce a negative result? Where is that written? It violates every standard I've ever encountered. I used SQL to illistrate a system that DOES follow the mathematical standards set years ago to NOT allow invalid mathematical results.

I intentionally set up a recursive call to be called so many times the system couldn't hold all of the routines in memory. As each routine was called, it's data was added to the memory stack until finally the code blew up with a stack overflow. I was wondering when the memory overflowed that the catch should fail to interupt the process and it is properly working. Again, it had nothing to do with the mathematical problem.

KP Lee 21-Oct-11 2:30am View

It's standards says it is OK to produce invalid mathimatical results? Where is that written?

KP Lee 21-Oct-11 2:26am View

Yes I know 2's complement, I've had extensive training on both 2's and 1's complement systems because at the time 1's complement systems existed. It's easy to verify it's 2's comp by the fact that with a signed 32 bit number you can create a number equal to negative 2 to the 31'st power. The KEY word here is SIGNED!!! It is critical that the system you use UNDERSTANDS it's signed. SQL understands it is SIGNED and will not LET you get an invalid mathematical result. This is what I was trained in, so many years ago. When you reach positive 2^31-1 on a 32 bit number there is one "0" followed by 31 1's. On an unsigned int adding one, there's no problem because the result is 1 followed by 31 0's. Adding two positive numbers should NEVER result in a negative number because that is an INVALID MATHEMATICAL RESULT!!! Adding 1 in SQL at this point to a 32 bit signed integer results in an ARITHMETIC overflow error, not a Stack overflow (Yes, that was a different issue, sorry for overloading your brain by talking about 2 separate issues in the same note.)
Yes, 1 followed by 31 zeros is -2^31. Adding 1 to positive (2^31 - 1) to positive 1 shouldn't produce negative 2^31 power.

KP Lee 4-Oct-11 4:34am View

Deleted

1. I said an identity int field is a great PK, not a guid.
2. A guid is 16 bytes, not 36 characters. It is represented on output as a 36 character field.
3. If you don't have a hot-spot problem using an identity field, see comment 1.
4. Every example I've seen that shows a guid is a bad choice uses the worst set-up imaginable for a guid as proof that it is a bad choice.
5. I don't see the point of having a sequential guid, it pretty much wipes out the reason for having a guid in the first place.

KP Lee 30-Sep-11 23:55pm View

Deleted

I beg to differ. Uniqueidentifier was originally DESIGNED to be a PK. An identity int field is a great PK, only 4 bytes, part of the DB schema design. The only problem with it is that it is sequential. This is no problem if the table gets less than 40K inserts a day, a huge problem if that insert count is an average for an hour. In comes the GUID. With random placement, the hot-spot problem disappears.

KP Lee 20-Sep-11 5:21am View

Deleted

Actually, I gave DrABELL a vote of 1 on his (her?) alternative because your event processing is for winapp which has nothing to do with server/client processing. JavaScript (one word) is definitely web oriented. I don't think C# would know what to do with it in a winapp. (ASP.NET is completely different. It has its own clientside language whose name I can't remember, but it reads to me just like JavaScript, which would also run fine in that environment.)

KP Lee 20-Sep-11 5:07am View

Deleted

All numeric field types support TryParse, byte.TryParse would fail if -1 was entered, and that can be a valid check. I actually was lazy and used int.Tr... on a field whose only valid values are between 15 and 49.

KP Lee 20-Sep-11 4:45am View

Deleted

Reason for my vote of 1
Alternative 4 makes no sense. Client and server side terminology deal with network communications as reinforced by the reference article which has HTML (network) code using JavaScript (client side interpreter) which is important in networks and has nothing to do with winapp which usually completely runs on one "client" and the author said nothing about server-side processing. Probably isn't even aware of networking issues involving client-side processing.

Comments by KP Lee (Top 14 by date)