I have previously posted information about how to get local date and time happening in Azure SQL Database. Many people have been frustrated about the inability to set any date and time to work with, rather than just UTC.

I posted here about calculating it, and here about how to set it for your session.

While the workarounds were helpful, there were many situations where they just weren’t enough. One simple example is where you’re offering a Software as a Service (SaaS) application and want each tenant database to have its own date and time configuration, but many other people just wanted their database to reflect their own local time.

So, it was great to see UC’s recent post about the new options for this!

You can now set this two ways:

Database Level

First, you can set it at the database level by using a database-scoped configuration. This will be the most common.

ALTER DATABASE SCOPED CONFIGURATION SET TIME_ZONE = 'E. Australia Standard Time';

Now you might be wondering how you find the appropriate names for the time zones. That’s also easy. In my case, I’m looking for any that contain Australia.

SELECT *
FROM sys.time_zone_info
WHERE [name] LIKE '%Australia%';

You can also view the current value by querying the database scoped configurations:

SELECT *
FROM sys.database_scoped_configurations
WHERE name = 'TIME_ZONE';

There is also an option to reset it, by using the keyword LOCAL:

ALTER DATABASE SCOPED CONFIGURATION SET TIME_ZONE = LOCAL;

Session Level

Now this one is interesting as well. You might just want to set the value for your session, instead of for the whole database. That’s the option that ANSI/ISO SQL suggests. And that’s now also possible:

SET TIME ZONE 'E. Australia Standard Time';

And you can query what it’s currently set to:

SELECT time_zone
FROM sys.dm_exec_sessions
WHERE session_id = @@SPID;

What’s missing?

It strikes me that I’d want to be able to set a session time zone based upon a query or a value from elsewhere. But this doesn’t work:

DECLARE @TimeZone sysname = 'E. Australia Standard Time';

SET TIME ZONE @TimeZone;

I’m not a fan of all these SQL Server commands that can’t take variables or parameters. You might wonder if you can set it with dynamic SQL, like this:

DECLARE @TimeZone sysname = N'New Zealand Standard Time';
DECLARE @SQL nvarchar(max);

SET @SQL = N'SET TIME ZONE ''' + @TimeZone + N''';';
EXEC (@SQL);

SELECT time_zone
FROM sys.dm_exec_sessions
WHERE session_id = @@SPID;

But that doesn’t work either. It sets it ok, but that’s done in another scope, and your own session scope is unaffected.

I see this as the biggest limitation of how the session-scoped option has been implemented. Otherwise, I’m loving the fact that it’s appeared.

An Eventhouse-originally designed for realtime event data-can also serve as a vector database in Fabric RTI, supporting semantic/embedding-based retrieval workflows.

The key enabler is the dynamic column type, which allows you to store unstructured data such as arrays or JSON blobs. This lets your embedding vectors live alongside your ordinary event metadata.

Microsoft recommends using Vector16 encoding (i.e. 16-bit floating representation) rather than full 64-bit. This dramatically reduces storage footprint and boosts the performance of vector operations like dot product or cosine similarity.

Once embeddings are stored, you can use native KQL functions like series_dot_product() or series_cosine_similarity() to compute similarity between vectors at query time. That gives you vector-search or semantic matching capabilities right inside Eventhouse.

To scale, you should set appropriate sharding policy (limiting rows per shard) and merge policy (preventing unwanted merges) so that each cluster node can parallelize searches efficiently.

With this setup, you can support real-time retrieval applications-e.g., feed embedding vectors as part of conversational or semantic systems, do similarity lookups on the latest events, or enrich live queries with context vectors.

This design allows you to collapse what might otherwise require a separate vector database into your existing Eventhouse infrastructure-making your architecture simpler and your search truly real time.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

AI development is another really timely subject. I recently read Hands-On AI Development with Python: Build and Deploy Real-World AI, Machine Learning, Deep Learning, and NLP Applications as a review copy I received from my friends at PackT.

Author

Vivian Aranha is described as an AI educator, technology leader, and founder of School of AI. He was worked with Fortune 500 organizations including The Washington Post, Delta Air Lines, and IBM. He currently teaches globally through School of AI, Udemy, Skool, and Maven.

Hands-On AI Development with Python

There are plenty of books that promise to teach you artificial intelligence, but many of them leave you somewhere between I understand the theory and OK, but how do I actually build something? This book is aimed at closing that gap. It takes a practical approach, moving from Python fundamentals through machine learning, deep learning, natural language processing, computer vision and, eventually, deploying AI applications.

What I particularly liked about the book is that it doesn’t assume the reader already knows everything about machine learning. It starts at a fairly accessible level, covering Python basics, NumPy, pandas, data manipulation and exploratory data analysis before moving into machine learning models. That order makes sense. AI can sometimes be presented as if you can jump straight into neural networks and large language models, but the reality is that understanding data and being comfortable with the underlying programming environment are pretty important.

The practical nature of the book is its biggest strength. Rather than spending chapter after chapter explaining concepts in isolation, Aranha repeatedly follows explanations with code and projects. The early chapters cover things such as linear regression, classification, spam detection and neural networks, while later projects become considerably more ambitious. There are examples involving image classification, sentiment analysis, fake-review detection, named entity recognition, recommendation systems and even a Tic-Tac-Toe AI using the minimax algorithm.

I think that hands-on approach will appeal particularly to people who learn by doing. Vivian recommends working through the examples interactively rather than simply reading them, modifying the code and attempting the projects independently before looking at the solutions. That is good advice, and it reflects the overall philosophy of the book.

I appreciated the breadth. The book doesn’t limit itself to one particular corner of AI. After establishing the basics, it moves into TensorFlow and neural networks, NLP and pre-trained models, then into deployment with Flask and cloud platforms. Later chapters introduce CNNs, recommendation systems, collaborative filtering, AI games and a simple voice-controlled personal assistant.

For someone trying to get a feel for the AI development landscape, that makes the book quite useful. You can move from What is machine learning? to actually building something, then see how different techniques are applied to different types of problems. I also liked the fact that deployment isn’t completely ignored. Chapter 4 takes a model and turns it into a web service using Flask, which is an important step that introductory AI books sometimes gloss over.

Limitations?

The breadth does come with a downside, though. Personally, I sometimes found the book’s scope a little ambitious. There is a lot packed into these pages. The transition from basic Python programming to machine learning, neural networks, NLP, computer vision, recommendation engines and AI applications means that individual topics don’t always have the space they might receive in a specialist book. If you’re looking for a deep theoretical treatment of neural networks or a detailed exploration of modern generative AI architectures, this probably isn’t that book.

But I don’t think that is really the book’s purpose. Vivian is much more interested in giving readers a broad practical foundation and getting them comfortable with building things. The book itself describes AI as a combination of programming, mathematics, data manipulation and software engineering rather than an isolated skill, and I think that is an important point.

Intended audience

The intended audience is also fairly clear: software developers, data scientists, students, self-taught practitioners and technical professionals. A basic familiarity with Python is recommended, but previous machine learning experience isn’t required because the material builds progressively.

I came away from Hands-On AI Development with Python thinking of it less as a definitive reference book and more as a practical launchpad. Its real value is in encouraging the reader to stop just reading about AI and start experimenting with it.

If you’re already an experienced machine learning engineer, some of the introductory material will probably feel very familiar. But if you’re a developer, analyst, student or technically minded professional wanting to move from understanding AI concepts to actually building AI applications, there is plenty here to keep you busy.

Summary

What makes the book work is that it doesn’t try to make AI mysterious or unnecessarily intimidating. Instead, it breaks the subject into manageable pieces, gives you code to work with, and gradually increases the complexity. In a field that can sometimes feel overwhelmingly broad, having a book that simply says let’s build something is a pretty useful place to start.

8 out of 10

Retrieval-Augmented Generation, or RAG, is a technique where a large language model is given external context before it generates an answer. In Fabric, Eventhouse can play a central role in supporting real-time RAG solutions.

Because Eventhouse stores both structured and unstructured streaming data, it can serve as a continuously updated source of facts and events. Using built-in vectorization capabilities, recent data can be converted into embeddings and stored for semantic search.

When an AI agent or copilot receives a query, it can first retrieve the most relevant context from Eventhouse - such as recent transactions, alerts, or telemetry - and then pass that information into the model’s prompt. This makes responses contextually accurate and time-sensitive.

The result is a real-time RAG system where your AI is always reasoning with the most current data available, rather than relying solely on static knowledge or stale summaries.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

More SQL and AI love !

We’ve been working on this for a while. PostgreSQL is a great vector database that can support your AI-based applications. And HorizonDB is an awesome managed version of PostgreSQL. Better yet, we’ve just completed a course that can show you how to use it. It’s low-cost ($195 USD) and offers our lifetime access.

Check it out and enrol now here: Using AI Features in HorizonDB

Course Summary

Do you want to start working with AI-related features in Azure HorizonDB? Or are you going to be asked about using databases this way? Either way, you need to be prepared!

This course is about using Azure HorizonDB to store, retrieve, and integrate data for AI systems, in a way that is reliable, understandable, and operationally sound. We assume you already understand PostgreSQL fundamentals and are comfortable working with PostgreSQL and database design.

• Are you responsible for deciding where AI-related logic should live, and where it should not?
• Do you need to support vector search, retrieval, or AI integration without turning the database into an experimental system?
• Do you want to understand Data API Builder and configuring an MCP server for Azure HorizonDB?
• Have you been asked whether databases should be used for embeddings, RAG patterns, or AI orchestration, and wanted a clear answer that you can explain?

If any of that sounds like you, then you’re in the right place. You’ll get clear explanations, hands-on exercises, and short quizzes to make sure you not only understand the concepts but can confidently apply them in real Azure HorizonDB environments.

And while the practical exercises are optional, we strongly encourage completing them. They are designed to be straightforward and focused on realistic scenarios, rather than tooling complexity. Setup is easy. The main requirement is access to an Azure subscription where you can deploy an Azure HorizonDB resource.

Check it out and enrol now here: Using AI Features in HorizonDB

The Model Context Protocol, or MCP, provides a standard way for AI agents to interact with real-world systems and data sources.

RTI can expose real-time data and events through MCP-compatible endpoints.

When integrated with Fabric Real-Time Intelligence, MCP-based agents can consume real-time signals directly from Eventstreams, Eventhouses, or Activator outputs.

For example, an agent could subscribe to anomaly detection events and automatically create an incident ticket, adjust system parameters, or notify a human operator.

Because MCP supports structured context exchange, the agent can make decisions based not only on static data but also on live telemetry.

Common scenarios would be Automated remediation, alert routing, and adaptive scaling.

This integration opens the door for intelligent copilots and automation frameworks that understand and act on what’s happening right now-bridging the gap between real-time analytics and autonomous response.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

More SQL and AI love !

We’ve been working on this for a while. PostgreSQL is a great vector database that can support your AI-based applications. And we’ve just completed a course that can show you how to use it. It’s low-cost ($195 USD) and offers our lifetime access.

Check it out and enrol now here: Using AI Features in PostgreSQL

Course Summary

Do you want to start working with AI-related features in PostgreSQL? Or are you going to be asked about using databases this way? Either way, you need to be prepared!

This course is about using PostgreSQL to store, retrieve, and integrate data for AI systems, in a way that is reliable, understandable, and operationally sound. We assume you already understand PostgreSQL fundamentals and are comfortable working with PostgreSQL and database design.

• Are you responsible for deciding where AI-related logic should live, and where it should not?
• Do you need to support vector search, retrieval, or AI integration without turning the database into an experimental system?
• Do you want to understand Data API Builder and configuring an MCP server for PostgreSQL?
• Have you been asked whether databases should be used for embeddings, RAG patterns, or AI orchestration, and wanted a clear answer that you can explain?
• If any of that sounds like you, then you’re in the right place. You’ll get clear explanations, hands-on exercises, and short quizzes to make sure you not only understand the concepts but can confidently apply them in real PostgreSQL environments.

And while the practical exercises are optional, we strongly encourage completing them. They are designed to be straightforward and focused on realistic scenarios, rather than tooling complexity. Setup is easy. We’ve even used Ollama to host the AI models in the labs so you don’t have costs associated with that and can test everything locally.

Check it out and enrol now here: Using AI Features in PostgreSQL

As with any preview feature, there are some practical considerations.

The first is that this is still evolving. Not every scenario or data type is supported yet. Expect some limits on dataset size, refresh frequency, and concurrent analyses.

You must enable the Python plugin in the Eventhouse. This is what provides the model runtime, and enabling it isn’t instant. If you attempt analysis before it’s ready, the system will return an error.

Sufficient historical data is essential. The AI model needs context to learn what normal looks like. If you only have a day or two of data, it may not capture normal seasonality or trends. A good rule of thumb is to have at least one full pattern cycle - for example, a few weeks of hourly data or several months of daily data.

Currently, each detector supports one active model configuration. If you want to monitor multiple metrics, you’ll create multiple detectors.

Performance-wise, keep in mind that the Eventhouse allows a limited number of concurrent queries. Running several detectors or analyses at once could slow performance or trigger timeouts.

Microsoft had a standalone Azure Anomaly Detector service. They have announced that it will retire in October 2026. So this Fabric-integrated capability is the path forward.

If you’re currently using Azure’s older service, start planning a migration so you can take advantage of the unified monitoring and alerting capabilities in Fabric.

Overall, it’s a promising feature that already covers most typical scenarios, but it’s best treated as an evolving component rather than a finished product.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

I’ve done a lot of Microsoft exams over the years, mostly SQL Server ones but plenty of others too. And one thing that I really don’t like is when the questions are:

• Purely academic (ie: would never happen)
• Memory-based (ie: who cares what a particular limit is for a particular SKU today?)
• Clearly not written by someone who actually uses the product

Today, I want to mention an item in the last category.

Telltale signs

(Note: we really try to avoid using triggers in the first place, but that’s a story for another day).

In many exams, I’ve seen T-SQL code for triggers and one of the instant telltale signs of whether the author of the question really uses triggers or has just read the documentation and thinks they know about triggers, is whether or not they’ve used SET NOCOUNT ON.

The same was obvious in some blog posts and discussions that I’ve seen lately.

If you see example trigger code for SQL Server and it doesn’t include SET NOCOUNT ON, it’s unlikely to have been written by someone who regularly writes production code.

Why does it matter?

If an application updates two rows in a table, SQL Server tells it that two rows were updated.

If you then add a trigger that, for example, updates a row in another table, SQL Server will now tell the application that three rows were updated.

This is enough to break many applications.

The application that sent the update won’t want to know about other rows inserted, updated, deleted, etc. by your trigger. That will only confuse or break things.

While there are odd exceptions where you do want the default behavior, the answer to this is to use SET NOCOUNT ON. When we are teaching students to write triggers, we tell them that nearly every DML trigger should start with SET NOCOUNT ON. Check out the documentation here:

https://learn.microsoft.com/en-us/sql/t-sql/statements/set-nocount-transact-sql?view=sql-server-ver17

SET NOCOUNT ON stops the count of rows affected by the trigger being returned by the operation. The beauty of using this in a trigger is that it stops the count of rows affected by the trigger from affecting the count that the application sees.

So, when I see a whole lot of exam questions on triggers and none of them include this, that’s really disappointing in so many ways. Learn to use this in your trigger code.

Let’s look at where this feature fits in practice.

The first major category is IoT telemetry - monitoring physical equipment. Think of a manufacturing plant where each machine sends readings for vibration, current draw, and temperature. Sudden spikes or drifts in these metrics may indicate wear, imbalance, or failure. The anomaly detector can continuously flag these irregularities before they cause downtime.

Another use case is application or system performance. If you’re monitoring throughput, error rates, or latency across multiple services, anomalies may indicate deployment issues, scaling problems, or outages. Because detection runs continuously and in near real time, operations teams can be notified within seconds.

The third common area is financial data - for example, transaction volumes, payment failures, or refund patterns. Detecting anomalies early can prevent fraudulent activity or identify systemic errors in payment flows.

Finally, supply-chain and logistics data is increasingly event-based - shipment scans, location updates, delivery times. Fabric’s detector can spot anomalies such as unexpected delays or missing updates in a route, triggering alerts for intervention.

The key point across all these is that anomalies are often early warning signals. By automating their detection and integrating that into your data fabric, you shorten the time between something going wrong and someone knowing about it.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

One question that I’m asked all the time when consulting is whether reducing the size of database tables will make queries run faster or not.

The underlying question is typically about whether the client should implement some sort of archiving strategy, to reduce the amount of data in a table by moving older data off into another table.

My answer is that it might help, but if it does, you probably have another issue that would be a better one to solve instead.

When you need to read some data from a table, and you know where the data is, it doesn’t matter how much other data is in the table. The only time that the amount of data matters is if you don’t know where the data you are looking for is located.

Imagine you have walked into a physical library with a very large number of books. If you look in an index of authors to find the book by your favorite author that you want to read, and it tells you exactly where it is in the library, does it really make a difference if the library is expanded to double the number of books?

Image by J Zamora

You might have to walk a little further, but the process is still much the same, and the time taken will be much the same. But if you didn’t have that index of authors, it makes a huge difference. If that case, if you double the number of books, it would take twice as long to find the one that you need.

Having more data in a table than you need to access is only a problem if you are reading all that data.

The tell-tale signs of this sort of problem are obvious. If you have queries that get slower as the system holds more data, you probably have an issue to solve, and it’s likely an indexing problem.

Learn about indexing

And if you’d like to learn more about indexing, we have a course that’s what you need. https://sqldownunder.com/courses/idx_modules

The AI Anomaly Detector in Microsoft Fabric Real-Time Intelligence uses a combination of time-series analysis and machine learning models. You don’t need to choose the model manually-Fabric evaluates the data and automatically selects the most appropriate approach.

Behind the scenes, it can use classical models like seasonal decomposition or ARIMA for steady, predictable series, or neural network–based models for more complex and irregular data. It also supports hybrid methods that adapt to both short-term trends and cope with long-term seasonality.

An important aspect is that these models aren’t static. The system continues to retrain as new data flows in, so it adapts automatically to changing baselines and patterns over time. This helps reduce false positives and improves detection reliability in dynamic environments like IoT telemetry or financial transactions.

Full list of models here: https://learn.microsoft.com/en-us/fabric/real-time-intelligence/anomaly-detection-models

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

I’m involved in a lot of performance tuning work for SQL Server based applications. These are mostly your typical OLTP accounting, financial, or record keeping applications. One thing that constantly surprises me is that many developers and DBAs really aren’t sure about where their tuning efforts need to be focused.

In particular, what really surprises me is how much focus most people have on write/update behavior and how little on read behavior. I think there’s a perception problem.

If I ask a developer what percentage of the time they think the database will be writing (vs reading), I’m invariably told numbers like 20 or 25 percent. In fact, I remember having a discussion with a SQL Server product group member who was writing an MSDN whitepaper and I was a reviewer. He told me that he thought 40 to 60 percent was common. A database spending 40 to 60 percent of its time writing was common??? Not in my world.

Every time I measure the balance for these types of applications, and over a lengthy period, guess what write percentages I normally see?

Less than one percent is common and 1 or 2 percent is quite typical.

Even if you need to update a row, you have to find it first. I’m convinced that these applications that write 40 or 60 percent of the time are as commonplace as unicorns.

Image by Levi Saunders

Now I’m not suggesting that there aren’t applications where write performance is critical, but I can assure you that the vast majority of my tuning work is going to focus on making reads as fast as possible, because that’s what the systems are going to spend their times doing.

I’m going to focus on what the system is doing 99 percent of the time, not so much on the 1 percent, unless the writes are particularly time critical for some reason.

And the wonderful thing is that if you reduce the impact of the reads, the system has more time to work on writes anyway. Reducing the impact of reads will generally improve the performance of your writes.

The workflow is straightforward once you know the moving parts. You begin in your Eventhouse - that’s where data from your event streams is stored.

First, ensure that the Python plugin is enabled. This plugin provides the AI runtime used to train and run anomaly models. It can take up to an hour to enable for the first time, so plan that in advance.

Next, you select the dataset or table to analyse and identify the metric to monitor - for instance, CPU utilization, response time, or sensor readings. You also specify a timestamp column and any grouping keys - maybe a device ID, region, or customer.

Fabric then takes a historical sample of the data, analyses its shape, periodicity, and trends, and tests multiple models automatically. This model selection process can take anywhere from a few minutes to half an hour, depending on the amount of history.

Once it’s done, you’ll see an evaluation panel. Here, detected anomalies are plotted over time, alongside the predicted baseline. You can inspect where each anomaly occurred, compare against normal ranges, and adjust the sensitivity level if needed. You can also see which models Fabric tried and which one it chose as the best fit.

When you’re satisfied, you publish the detector. From that point on, the system runs continuously in the background, checking new incoming data against the trained model.

Detected anomalies appear instantly in the Real-Time Hub. You can subscribe to those events - for example, to trigger alerts, update dashboards, or feed downstream automations.

The setup is one-time: configure, review, publish, and then monitor results as the data continues to flow.

Learn more about Fabric RTI

If you really want to learn about RTI right now, we have an online on-demand course that you can enrol in, right now. You’ll find it at Mastering Microsoft Fabric Real-Time Intelligence

Perhaps I’m getting old and philosophical but I recall the days when the IT industry prided itself on accuracy. We worried when things didn’t work properly and kept working on them till they did work.

If a customer’s system stopped in a weird way, they actually wanted to know why. They didn’t just want to reboot it and hope for the best.

When did that change?

In a previous blog post , I’ve wrote about the evil Oops something went wrong syndrome that seems to have infected many Sofware as a Service applications.

Sony example

The screenshot above though, is the outcome after a Sony TV performed its routine software upgrade. Let me paraphrase it’s message for you: What it basically said is:

I did an upgrade for you. Nothing went wrong but I think I trashed some of the configuration settings that you’d made but I’m not going to give you any clue about which ones, and you’ll just have to suck it and see what’s changed.

What an awesome message, and one that really doesn’t match the advertising slogans:

I’m guessing they’re still quite a distance from perfection.

Apple example

But Sony is not alone on this. A little while ago, I upgraded my Apple iPhone. The recommended method at the time was to back it up to iCloud, then restore it onto the new phone, or at least that’s what the genius (Apple terminology) told me at the store.

Why they couldn’t just transfer the data directly between the old and new phones at the store immediately was far from obvious, particularly when a phone now costs so much. As phones get larger (storage-wise), sending all the data from one up to a cloud storage, and then back down to the new one seemed patently silly. (At least they’ve recently fixed this and the two phones can communicate directly with each other for the cloning).

When I did it back then via the cloud though, the backup was reasonably quick. The restore, however, took over 3 days and when it finally ended, it said:

Some files weren’t restored.

No hint, no clue about what. Just some stuff went missing and the phone thought I’d better give me a heads-up.

How did we get to a point in the industry where a 3 day restore that ends in something didn’t get restored is considered acceptable in a professional product?

Microsoft example

Mind you, I’m not sure that’s any better than Microsoft-related updates that simply ignore your previous settings and put the device, or browser, etc. back to whatever state the update wants it to be in. I’m sure it’s easier to apply updates when you don’t care about preserving the intent of previous configuration changes.

I’ve given up using Edge primarily because I feel like I have little control over what it displays. I do a lot of presentations and demonstrations, both in meetings and in online sessions. I want a blank browser to use: no adds, no widgets, no news feeds, nothing. It’s increasingly difficult to achieve this with Edge. And when you do, it happily just decides to change your settings in the next update. Something suddenly reappears on what should be a blank screen. I don’t have this issue with Chrome and so I use it or other browsers, even with all their limitations.

But I can open up Edge in a professional meeting or webinar, and suddenly I find they’ve put something like the MSN news feed back onto my browser screen. That wouldn’t be all that bad, except the MSN hope page invariably has at least one image of a scantily-clad woman. MSN might decide that’s ok but it’s just not acceptable in a professional session. Microsoft needs to do better. And MSN is a rubbish news feed anyway.