Tuesday, July 15, 2008

ARC: Did You Know #4

Did you know you can execute a portion of an SQL script buffer in the ARC SQL Utility?

Many new users are not aware that you can can highlight a specific section of a script and just execute that selection.

The technique can also be utilized with the SQL debugger. You can set a breakpoint and select a portion of a script, or you can select a portion of a script and simply hit F10 to start debugging just that selection. Often times this is not terribly useful as you would almost always need the variable declarations at the top of the script in order for the script to run. However, this can be a useful technique if you have a large upgrade script that creates procedures/triggers/functions and you want to debug or execute just a portion of the those new objects without pulling them out into a temporary script file.

Thursday, July 10, 2008

Advantage Training

Warning:Marketing content below! I strive to provide mostly technical content in this blog, but this post is purely trying to let you know about a training opportunity. It's technical training, so I hope you will let this slide... :)

I can tell from my web and RSS stats that I have picked up quite a few Visual FoxPro readers. The Getting Started with Visual Foxpro and Advantage post remains one of my most popular. If you are interested in learning more about Advantage, our Advantage Technical Summit would be the absolute best place to start. We provide the training and meals, you only have to pay for airfare and hotel.

Our trainings in Boise not only provide an opportunity to attend classes, but you also get to mingle with other Advantage users. Listening to their success stories, tips and tricks can often prove invaluable. In addition, you have full access to our support and engineering staff who are always happy to answer questions, sit down and debug code, help write some new code, etc.

The next training is September 10th and 11th. Check out the schedule here, and register here. We can always schedule one-on-one sessions if you have specific questions or problems.

If you can't attend this training be sure to stop by our booth at Southwest Fox 2008 October 16-19.

Thursday, July 3, 2008

Decoding winmail.dat files

I don't have a Microsoft e-mail client, and every once in a while I get an e-mail with a single winmail.dat attachment.

I use a simple utility I thought some readers might find useful called WMDecode to extract the attachments. It's simple and has worked on every winmail.dat file I have used it on.

There is a free version with a timeout, or you can buy a perpetual license for 10 dollars.

Tuesday, July 1, 2008

Nitpicks Matter

I mentioned in a previous post that nitpicks matter. This is the main premise of Joel Spolsky's book User Interface Design for Programmers, which while simplistic in the realm of UI design, is very fun and easy to read and significantly influenced my redesign of the Advantage Data Architect (ARC) GUI in version 8. Every little thing that might not seem significant adds up to a poor user experience. Sometimes you can't quite peg what is wrong. It's nothing major, nothing worth spending the time reporting to the software vendor, but it's just annoying.

The irony here is that often the little bugs that drive you crazy are the easiest to fix. One or two lines of code and that bug that makes you curse every time you run into it is gone. You are happy as an end user, and we are happy as developers because we were able to quickly and easily address something that was bothering you.

While adding some stored procedures and triggers to an internal utility that uses Advantage recently, two things became very apparent; 1) I had not done enough usability testing with the SQL debugger and 2) Users are not sending us the nitpicks that are annoying them.

#1 is entirely my fault, and there isn't much I can do now except fix up my mistakes and do some more usability testing. The rewarding part is as mentioned above, many of these fixes are just small tweaks in the user interface behavior.

#2 became apparent as I ran in to at least 4 issues that drove me crazy. The cursor left the editor buffer after every execution (which one user did report, thanks!) and ARC would not position the cursor at an error location when saving a trigger with errors. I had a less than stellar experience. A few days later a partner called me to explain a similar experience they had encountered. I'm convinced many others have run into the same issues but do not have time or do not know how to report the issues. Many also probably thought the bugs were nitpicks and did not warrant nagging us with an e-mail. Nag us, please!

How do you report these nitpicks? In the future we will put a simple interface into ARC that allows you to report whatever you want with no required input fields. Until then, you can always send email to advantage@ianywhere.com and put "attn: JD" in the subject field. Those e-mails will get to me and I will log them in our bug tracking utility myself. Often a small video is much easier than expressing re-creation steps in an e-mail, so feel free to use utilities like Jing to send URLs of short video clips if that is easier.

ARC: Did You Know #3

Did you know you can "bootstrap" a debug session in ARC? You don't have to have any breakpoints set to start debugging. Simply clicking "step over" (F10) or "step in" (F11) will start a debug session and stop on the first line in the script.

This is a handy way to get ARC to quickly jump to the source code of a procedure or trigger you want to edit. For example, in this video I use this functionality to quickly jump into a procedure, edit it, and then verify my changes.

In the future the SQL Utility in ARC will hopefully have the ability to directly open procedures, triggers, and functions via the open command, but for now this is a convenient shortcut (as opposed to having to open the procedure properties dialog).

One thing to keep in mind is that once you have canceled the session and are inside the procedure buffer in the editor, you need to click "step over", "step in", or "start debug session" (Shift-F5) to start a new debug session, not "execute" (F5). Clicking "execute" will just attempt to execute the current buffer because you bootstrapped the initial debug session and there are no breakpoints set (breakpoints are how ARC usually decides if you want a debug session or if you just want to execute the script you are currently viewing). Hitting F10 or F11 will use the base script you started with as the driver for the debug session, which is likely what you intended.

Another alternative is to set a new breakpoint once you have the procedure buffer loaded in the editor. At that point the "execute" command will always start a debug session, and will always use your driver/base script to call the procedure.