June 2005 Archives

Thanks to the firewall installed by the default XP SP2 installation, you'll have to remember to enable ports 1433 and 1434 (UDP) to be able to see your SQL Server from elsewhere in the domain--or turn the firewall off (at your own peril). Note that you can tell the firewall that you don't want the ports to be made visible outside of your subnet (a good idea). That way only people on your own domain can trash your server... ;)
Thanks for this. This thing happens to me all the time. I actually stopped playing around in VS 2005 because of this.

Since SQL Server 2005 now permits administrators to force (coerce?) users to set (and periodically reset) passwords, is there a way to change the Windows strong password schema to a custom design?

Sure, I don’t recommend administrators grant people login accounts—I suggest these be assigned to job roles like “AdminClerk2” or “JuniorJanitor” or “PointyHairedBoss”. In any case, studies have shown that the Microsoft-style strong passwords are tough to remember. While a young person with a high IQ can remember a random set of numbers, case-sensitive letters and punctuation, those users with average IQ or those of advancing age (like me), find it tough to remember where we put the car keys, much less a complex password. So… we write it on a piece of paper where it won’t be missed and hope for the grace of honest people.

An alternative for us challenged folks of diminishing capacities is to use another (and it turns out more/just as) secure password schema. Simply concatenating two or more words together with punctuation works just as well. For example, the password “City.Dog!” is easy to remember and virtually as secure as the Microsoft style. Add a digit or two and it's even stronger.

Is there a way to program Windows domain controllers to use this or some other custom alternative schema? It seems to me that code hackers who did not know that a company was using a non-standard (non-Microsoft) password schema would be no better off... Comments?

(Originally posted 6/23/2005)
This entry was resurected from my old blog... it's a keeper.
____________________________________________________
The Microsoft Developers have already begun the process of picking up the shards and shattered pieces of their Whidbey implementation that were sheared off as the product was being stuffed into the box. Some of these feature fragments will be retooled and redesigned to be implemented in the next version of Visual Studio dubbed “Orcas“ designed to support Longhorn (the next version of Windows based on the .NET Framework). It's time for all of us to encourage Microsoft to fix old problems, address old issues and make ADO.NET better suited to develop our applications. To get us started I propose the following...

LOL @ Outlook syncing with Exchange.

While you are at it, let me add another one -

"Full Backups of a hot & live database"

1)       Focus on getting what you have already invented working better rather than inventing more classes to do things differently—making the existing classes redundant. Developers want clear choices not a Swiss army knife with 70 blades just to open an envelope.

2)      Stop deprecating established classes like the DataAdapter Configuration Wizard. This just causes confusion and needless thrashing. You’re trying to get people to adopt the product and continue to leverage their existing skills. Ripping out or hiding familiar objects is counter-productive.

3)      Add the ability to right click in the editor IDE and “Insert SQL”. This would launch the query builder and return a properly formatted query string.

4)      Provide an ability to interactively construct (code-generate) Parameters collections from selected ad hoc or stored-procedure queries. You had this in 2003, but dropped it in Whidbey. You could drag a stored procedure from the server explorer and drop it on a form. This would generate the Parameters collection code.

5)      Make it crystal clear how to indicate that a Parameter object is to use the server-side default value (this might only require a good doc topic)

6)      Figure out how to generate these Parameter collections and get the direction correct. There are still cases where code generators use Input/Output for Output parameters.

7)      Get server-side cursors working again. Yes, this is not generally needed by the masses, but there are still many situations where this “connected” approach makes abundant sense. We’ve seen that connected architectures work fine and can be more productive (and easier to write) than disconnected in many scenarios. Forcing everyone to use disconnected or ASP architectures is not helping adoption rates. Consider that the default behavior in ADO classic was “Server-Side” cursors—not disconnected client-side cursors. Provide more means to help manage server-side state—perhaps this is just more emphasis in the docs. Also consider that server-side cursors are complex to manage but they can be efficient if implemented correctly. Using dynamic cursors is not the answer. Keyset cursors are far more scalable and perform better than dynamic cursors. Developers should have control over the cache size and refresh rate (if auto-refresh is implemented). This should be implemented in a separate DLL so developers that choose not to use client-side cursors aren’t penalized by the additional overhead.

8)      When you think about scalability and how it impacts your implementations, consider that the majority by far of applications don’t have to scale beyond a few dozen to a few hundred users. It’s only in the largest companies that these approaches break down. Forcing developers to use an architecture that scales from 50 to 50,000 clients does not make sense if all they need to support are 200 clients.

9)      Make Open, Fill and Load asynchronous-capable. Saying that this can be done with a BackgroundWorker thread is simple to say, harder for some to do.

10)   Provide progress events in Fill and Load to preclude the need to code these asynchronously.

11)    Add more documentation on performance tuning that emphasizes server-side processing. That is, moving bulk data to the client for processing and shipping it back does not make sense if the query engine can perform these functions in situ.

12)   Provide a better/smarter/more easily configurable CommandBuilder. We need to be able to set the same Update Criteria options that we could use in ADO classic.

13)   Start writing the doc so it includes Visual Basic examples, but not necessarily just translated from C#. Visual Basic’s approach to events, object disposal and other issues is different—especially for Visual Basic 6.0 developers. Yes, Visual Basic has Using, but adding Using to a Visual Basic .NET example because C# has it does not help Visual Basic 6.0 developers understand how to convert their code.

14)   Document scenarios for individual data-bound controls like the Visual Basic 6.0 MSHFlexGrid and show specifically how to convert to the DataGridView. Include similar topics for other typical custom controls and show how these can be converted on a more granular level.

15)   Get Exception handling under control. I’m not sure where you are at this point, but as it is, it’s broken—there are still too many catch-all exceptions being returned. “Stuff happened” is not a suitable exception message…

16)   Find a way to build a “VLW” (very light weight) SQL query engine (like SQL CE) for use on the desktop for applications that need to store and retrieve information from smaller databases. While developers can persist data with XML it’s harder to use traditional SELECTs and relational approaches to the rehydrated DataTables.

17)   Think about ways to make replication foolproof. Your goal should be to make replication and database synchronization work as well and as deterministically as Outlook syncing with Exchange.

(Updates)

18) Now that the CommandBuilder has been reverted back to Everett functionality, it still needs to be fixed. I know you know what to do to fix it. At a minimum it needs to support ADO classic functionality in as far as Update Criteria goes. We’ve been asking for this for over 5 years. At this rate I suspect it will be another 5 before we see it…

UPDATE: July 4: 2005 Nope, the rather complex trigger approach did not work. It seems for one reason or another the trigger never fired. It also failed to do one simple thing: rollback the insert transaction.

I did some additional research and it seems the Captcha does not stop anybody but those wishing to post comments. After studying the inbound spam I discovered something that should stop them (for now). I'll share that with anyone that I know but I won't share it with the web--that's where the spammers live.

________________

 

 

I added some code to my .TEXT blog to prevent the spammers from adding comments. Be sure to send me mail (you know my email address) if you have trouble logging comments.

I just tested it and it seems to be working. Basically, the code uses the “trigger“ approach to filter inbound comments.

Nope, the trigger approach shut down the spammers that had many URLs in the text, but not the others. I had to add a control that capture the scrambled text in another attempt to keep out the creeps and cretins.

 

Thanks

I just got back from the DevTeach conference in Montreal. While small, (about 250 attendees) there were many great questions from the developers there trying to soak up tips and techniques. The conference was held in the downtown Sheraton—modern and clean, but their internet left much to be desired. It turns out that they had failed to attach the modem to the underside of the desk in my room which made it somewhat intermittent—it was hanging by the power cord and kept disconnecting. There were plenty of good places to eat (and the conference lunches were stellar). We were directed to the Baton Rouge restaurant across the street and over a block from the hotel. It featured a great mean of BBQ ribs. We also discovered a whole street of interesting and vaired restaurants about 5 blocks away—including a Burger King (which I can’t recommend as their service was in the French tradition—escargot slow). Montreal is definitely a French city. Every street and business sign is in French with very (very) few English hints. Fortunately, everyone speaks and understands English—whew. The conference organizer (and his family) took the speakers (about 50 of us) on a tour of the city and a (long uphill) walk through the park (and cemetery). We had a great dinner at a Greek restaurant where the service was typically French—slow, but the food was great. The conference itself had both previews of coming attractions sessions that talked about .NET futures and others that showed best practices for current technology. I hope they invite me back.

Getting to the conference was not too bad but flying back was a royal PITA. We took a wide-body flight from Montreal to Toronto on Air Canada (eh?) which was fine. However, the Air Canada flight (if you can call it that) from Montreal to Seattle was simply awful. I have flown what seems like millions of miles over the last six decades and except for the Thai “stang” buses I rode in Bangkok, I have never felt so cramped. The seats were too narrow and very close (way too close) together. Yes, I’m a tall guy (6’2”) and my knees were crammed up against the seat in front of me the whole time but my wife is far shorter and she also felt cramped. If this was a short hop, it might have been tolerable, but this was a 5 hour flight punctuated by an hour on the ground taxing (or sitting) with inane elevator music. To make matters worse, their “courteous” flight attendant abruptly told me to turn off my MPX-220 phone’s solitaire game—even after I told her I had disabled the radio. I noticed the guy up the aisle using his laptop (up on end). I expect his wireless and Bluetooth radios were still on doing untold damage to the flight navigation systems. I won’t get into the “food” they served as I’m not a fan of curried chicken—it was virtually inedible and I generally like airline food. When I suggested to the Air Canada staff that the plane’s configuration was too dense for a flight that long, they blew me off with a flippant answer. Sure, every airline has to fly the planes they own. But airlines that want to keep new customers (this was our first time on Air Canada) don’t configure their long-haul flights so passengers paying full fare have to sit in seats designed for children and midgets. I won’t be flying Air Canada again if I can help it—they join the list of banned airlines like NorthWorst.

 

Peter and I are writing a book that will cover this material in depth but it won't be available until well after Whidbey and Yukon ships. We can, however, meet with your company and provide a mentoring or training session to make sure you and your managers are up to speed on the options. We aren't in the business of selling anything but information about current and future technologies.
I'd love to learn to use them as they are meant to be used... My boss is pushing us to focus a bit on business intelligence in general (to impress customers). I'm not very familiar with BI actually.

Do you know about good tutorials or books about this in SQL 2005?
Bill - I have an iMATE Pocket PC Phone as well as the Smartphone - in love with them both.

As far as Lennie's question goes, if Sony made a car I'd buy it in a second and I'd buy ANYTHING made by Toyota other than those really ugly Scion's. Motorola is a great company in so many ways and has tremendous quality in many areas - problem is when they get out of there 6 Sigma boundary - they produce nightmares as Bill can attest to.

re: Refactoring

| No TrackBacks
Bill - I'll drop you a line tonight with a license. Glad to be of help w/ the blog ;-)
Yes, Peter and I are working quite a bit with these tools? What's your question?
Have you -occasionally- been working with the BI tools in Yukon or do you know blogs on MS BI?
I blogged the other day about the top customer issues that we have fixed based on customer feedback via...

Pages

Powered by Movable Type 4.21-en

About this Archive

This page is an archive of entries from June 2005 listed from newest to oldest.

May 2005 is the previous archive.

July 2005 is the next archive.

Find recent content on the main index or look in the archives to find all content.