Windward Wrocks

Datasource Map variables carried across datasources

Under extremely unusual circumstances this could break your report templates. If you find yourself facing this issue contact us and we can give you a work-around.

We now carry all variables in a datasource across to the next datasource when generating a report. So, when applying the first datasource, if any variables are added or changed (through the set tag, etc), those new variables/values will be set in the next datasource. However, this will only be done if the next datasource does not have that variable set. Variables set in a datasource will not be replaced by variables carried across.

The advantage of this new feature is you can carry running totals, etc across datasources. This carry across occurs only for generating a given template, it does not carry across between different reports.

To implement this we added a getMap call to the datasource API. You may also use this to get the value of all variables after a datasource is applied.

Storing Datasource Credentials

I signed up for a subscription that emails me my favorite comics every day. When creating the login I entered my standard credentials for sites where it's no big deal if someone can log in as me. And it wasn't acceptable. The login required a password of 12 characters that had to have alpha, numbers, & punctuation. Guys – this isn't Fort Knox – it's a list of cartoons.

On the flip side, at one of my banks I called up to find out how to change my password. The standard way is I tell the person on the phone my new password and she enters it. And this then is full access to my bank account including transferring money. (They did have a way to change it myself – but I had to insist.)

The trick is finding the best balance between convenience (no security) and security (no access possible). And that requires weighing out the trade-offs. I've also found that any approach to security can generally be improved by discussing it and seeing what was missed. Hence this post. Any comments, suggestions, etc are greatly appreciated.

With AutoTag we have a wide variety of use cases. First off, in all cases the user only needs read (select for SQL) access. This means that even if the credentials are broadcast to the world, if they are set to only allow a select, the data cannot be changed in any way.

So if the datasource is test data, scrubbed of any real info, then security is essentially unnecessary. For example, we have a test database that has the Northwind and AdventureWorks databases on it – and that's all. If the world has the read-only credentials to that, there is no downside. In this case any security efforts that get in the way of the user are an inconvenience for no reason.

On the flip side, a programmer may need to test against an exact copy of the corporate payroll database. While they have read-only access and cannot change anyone's pay, they can easily read the monthly salary of every employee. These credentials you want to keep very safe.

We are implementing four options for handling the login credentials to each datasource tied to a report template.

1. If the datasource can be opened using integrated security (i.e. it uses your login to Windows), we use this. This is the best approach as we store nothing and the user does not need to enter anything.
2. We store the credentials in the template in plaintext (it, and other information, is uuencoded – but that is not any real protection). These credentials travel with the template so anyone that has the template can pretty easily get the credentials. But this is very easy to use as it logs in anyone using the template in to the datasource automatically.
3. We use the .NET ProtectedData class to encrypt and decrypt the credentials. This uses the currently logged in user credentials to encrypt the info and as such requires no action on the part of the user. The info is then decrypted with no user interaction, but only if logged in as that same user. On a system logged in to any other user the info cannot be decrypted.
   We store the encrypted data in the template, not on the local computer. We considered storing this info in the registry but there are some complexities in then matching a given registry entry to a given template and there is no way to know when entries are no longer used so the registry just grows over time. The downside of this is to get the credentials, someone merely needs the template and your Windows login – but they do not need to be on your computer.
4. We require the user to enter the username & password when opening the template. In this case we never write the credentials to any file or other repository. This requires the user to enter it each time, but provides a very safe approach.

There are two other decisions of note we took in our approach:

1. The choice of approaches 2 – 4 above are set on a system basis. (For any given datasource you can select integrated security). So you cannot mix and match based on the datasource. We did this to keep the datasource UI simpler as we believe 99.99% of our users will always be using a single approach.
2. We do retain the credentials, in plaintext, in memory while the program is running. We do this even for approach (4). We do this because we need to pass those credentials every time we open a connection and that is occurring a lot in the wizards. So the credentials can be pulled from the memory of the app while running – which includes the disk if it is paged out by the memory manager.

What do you think?

A better GetCookie()

Ok, lets say you have 3 cookies source, id, and sourceid. In this case every GetCookie I have seen will fail if the sourceid cookie comes first. Here is a GetCookie that will not. And for those that say no one will ever do this, I've tripped across this on web sites at three different places.

function GetCookie(name) {
var cookies = document.cookie;
var startIndex = 0;

while(cookies.length > 0) {
startIndex = cookies.indexOf(name + "=");
if (startIndex == -1)
return null;

if (startIndex == 0)
break;

if ((cookies.charAt(startIndex-1) == ' ') || (cookies.charAt(startIndex-1) == ';'))
break;

cookies = cookies.substring(startIndex + name.length + 1);
}

if (cookies.length == 0)
return null;

var endIndex = cookies.indexOf(";", startIndex);
if (endIndex == -1)
endIndex = cookies.length;
return unescape(cookies.substring(startIndex+name.length+1, endIndex));
}

The Best C++ Interview Question – Ever!

There is no one magical question that can determine if someone is the right candidate. There isn't even one that will determine if their technical knowledge is up to par. But there are those occasional questions that provide a lot of bang for the buck – simple questions that give you a lot of feedback about the candidate.

If I could ask a C++ programmer just one technical question, this would be it. Why? Because the correct answer feels wrong and the initial answer is generally wrong. So seeing how they work through the explanation is very illustrative of not just their knowledge of C++, but their willingness to not get locked in to their initial answer.

Q: Can you call "delete this;" inside a member function?

The instinctual answer of almost everyone is No. Not only no but there is a visceral emotional response from most that doing so would be like crossing the beams in Ghostbusters – very bad news. Ok, so next step, regardless of if they answer Yes or No is to ask "Why?"

This is where you really learn a lot. Even people who answer Yes (and they are few and far between), most of them have trouble explaining what is going on. I have seen many, over 5 – 10 very painful minutes, sketch out most of what is going on, and yet still say that you cannot do it. These are people you do not want to hire under any circumstances because they cannot think outside their initial preconceptions.

I have also had many with some of the most outlandish understandings of what is actually going on in the computer. Many people think when you call the delete that the memory the code is running on is garbage collected. Not the data – the code! Some think the v-table disappears on calling a delete (it doesn't as it's tied to the class) – and they think the v-table is needed for the return from the method.

Ok, so you then have one of the few who has worked through the above, got it figured out, and you're feeling good. We then have a follow-up question that will drop out half of the remaining candidates – "What can you do after calling delete this?"

And you will get answers that are all over the board from "anything" to "nothing." I've had many ask me if local variables are consider part of the object memory – so at least those people are thinking it through even if they don't fully understand what belongs to an object.

So there you go – a great interview question until it is over-used enough that everyone knows about it (like the manhole cover question).

Update: This has received a large number of comments (especially on reddit). I want to stress one key point - I don't ask this because I expect most people to get the initial answer right. If they did it would not be that useful a question. I ask to see if they can work their way to the correct answer and how they do so. As to the question of why would you ever do this - it is very useful in message based systems and when threads are exiting.

PS – If you have a great "just one question" – please post it in a comment below.

And if you need a great C++ reporting system, please check out Windward.

Our new ribbon UI

I owe Xpertdoc a big thank you. Reviewing their Word AddOn made me realize that we had done a lousy job of using the Office ribbon. We had merely moved all menu items in our Office 2000/XP/2003 version to buttons to the ribbon. To sum up our initial effort – yuck.

Ok, well once again we can hold our head up high. I think we now make full effective use of the ribbon, doing so as well as Office does. (And, in my biased opinion, better than any of our competitors.) Competition is good because it causes each of us to step up to challenges from our competitors and to not just equal, but surpass what they offer.

So here's how it works. As you move through the template at anytime you can click the tags button and then select the type of tag to insert there. At all times you can validate tags as well as move to the next or previous tags. So you have a quick way to get to any tag and insert tags without ever leaving the ribbon.

Once you have inserted a tag you then get the main properties for the tag in the ribbon. This is different from the Office approach where the specific items would be in a 2^nd tab. We tried that approach also and got a 100% thumbs down from the users trying both approaches. So this is different from the Office UI, but we think it is an improvement.

For the properties that are rarely used, you click on the group button to bring up the tag builder. But for 98% of the time, everything you need is right in the ribbon. You can even get the full data tree right off the ribbon – click on the selected item to put it in the select. Same for the evaluate where clicking on it will drop down a window showing the results.

Please give it a spin and let me know what you think. You can download 8.1.3.0 here.

The forgotten methods in the ADO.NET API

In our projects we consistently found that we needed some slight additional functionality from that provided. And we needed the same thing in project after project. So we added this in a library that provides it for the top 5 databases as well as ODBC/OleDb.

We are now releasing it as open source (The Kailua Project). Not GPL or anything like that - just it's free to use however you wish.

This library is intended to be as lightweight as possible while providing a consistent API for ADO.NET connectors. I myself call it the forgotten methods in the ADO.NET API. If you want something more than this take a look at Hibernate.

Every bit of functionality in here we need for our products. Some of our products need more than others but we were very careful to only add what is absolutely needed. We do not use all the DbType columns in databases but we did try to add testing for all types.

What this adds is the following:

• Return all metadata for the DB
  • table/view/column names, descriptions
  • column data type
  • tables PK:FK relationships
  • stored procedures – parameter info
• Return the primary key on an insert for auto-generated primary keys.
• Have a standard syntax to select the "top N" rows.
• A timestamp construct to match the TIMESTAMP in Sql Server and adding a GetTimestamp() method to handle it.
• Create connection strings from a server, database, username, and password.
• Run a DDL script on the database.
• Launch the program used to administer the database.
• A DataReader wrapper to work around bugs in the DB2 DataReader.

We use the IDb... interfaces as the basis instead of the Db... classes. There are good arguments either way but we found it easier to do this working off the interfaces. We created the WRVendor class instead of extending DbProviderFactory because we are returning IDb... interfaces rather than Db... classes. I am curious as to why Microsoft had DbProviderFactory return Db... instead of IDb... - but they did.

For Sql Server, ODBC, and OleDb it statically links to the connectors as those are part of .NET. For all others (DB2, MySql, Oracle, & PostgreSQL as of this time), it gets it's classes from DbProviderFactories so that it builds and runs fine if those connectors are not installed (although obviously cannot call them if they are not installed).

For other vendors, it has the WrUnknown classes which by definition cannot provide full functionality. They do as best as they can but if they could do all of this, this library would not be needed.

Roadmap

Time for another roadmap update. This one is on the engine & AutoTag. There will be another on the Arrow shortly.

Version 8:

The final release of version 8 will be out shortly and it will include:

1. Support for gauges.
2. A better implementation of how we use the Ribbon.

Version 9:

Over the next 6 months or so we will be implementing the following. Please keep in mind that priorities can change and so the below items are not guaranteed, nor is the order locked in. But the below is the present plan and the numbering is the order in which we presently have them scheduled:

1. Use setParam() for variables in a SQL select. This is discussed in more detail here.
2. Read SSRS RDL files for both data sources and report elements. We are converting our UDTs to use the RDL files, but we have to add a number of additional properties when we save our UDTs as the RDL format is pretty limited (which I think means SSRS is pretty limited).
   1. Convert RDL files to Windward templates.
3. Expand the macro processor functionality for tags. This will eliminate the need for the function tag.
4. Add Excel conditional formatting support – for all formats, not just XLS(X)
5. Display the tags using a better mechanism (this may be Office 2007 and later only).
6. Implement the switch statement.
7. Implement report to email.
8. Improve the charting engine to provide prettier charts (this is more significant for Java as we have a very pretty .NET renderer).
9. Table & matrix wizards (this is two different things).
10. Handle the new file elements in the Office 2010 file formats.

There are a number of other items that are not worth listing above. And as always, we pay close attention to what is suggested on our ideas page. If you have any questions, please do not hesitate to call or email me.

Thanks - dave