I have a client that uses Storis as his point-of-sale system. We've got a C#/ASP.NET app running on their intranet that monitors and reports on some other systems, and we wanted to add Storis to the mix. Storis uses IBM UniData as its back end, so this is where we started.

One of the things we got from Storis was a UniData Client CD, which includes an Admin, the UniDK, UniData ODBC, VSG, UniTools, and Dynamic Connect. Included in the UniDK are an OLEDB driver and UniObjects.NET. You might think that UniObjects.NET was the thing to use but that is not what we discovered. We WERE able to pull data out of Storis with UniObjects.NET, but the data was in its native form and SQL was not available. We had to do weird stuff, like query a table for its keys, get them in an array, and then query the table again by its keys. You couldn't just pull back data where Date >= '2009-03-08', for example. At least in no way that was apparent to us.

We installed all that stuff, but it turns out not all of it is necessary. We ended up only using the ODBC driver and VSG.

How we did it:

1. Install the ODBC Driver
2. Edit the C:\IBM\UniDK\Config\uci.config file, adding this to the bottom:
   <storis>
   DBMSTYPE = UNIDATA
   network = TCP/IP
   service = udserver
   host = [your storis IP address]
3. Add an ODBC System DSN
1. Click Administrative Tools - Data Sources. Note that on a 64-bit system, you will need to access the 32-bit ODBC applet, which you can get to (on Vista x64, for example) in Control Panel -> View 32-Bit Control Panel Items
2. On the System DSN Tab, Click Add...
3. Select the IBM UniData ODBC Driver
4. Click Finish
4. Configure the DSN
1. Select your DSN from the list
2. Click Configure...
3. Give it a Data Source Name. We went with "StorisUnidata"
4. For the server, specify "storis", which is the first line you added to the uci.config file above.
5. Specify your Database name. In the UniData world, they often refer to this as the Account Name, which is a little confusing.
6. For the User, specify a windows account that can access your database. To eliminate permissions issues, we started with a local system administrator account. We entered that account name under User.
7. Click OK.
5. Before you can access your data with SQL, you need to use the Visual Schema Generator to create a SQL Mapping:
1. Prepare yourself, because this app is a bit ugly :). Think Lotus Notes...
   
2. Launch the VSG
3. This is just like configuring the DSN:
   
1. For the server, specify "storis", which is the first line you added to the uci.config file above.
2. Specify your Database name. In the UniData world, they often refer to this as the Account Name, which is a little confusing.
3. For the User, specify a windows account that can access your database. To eliminate permissions issues, we started with a local system administrator account. We entered that account name under User.
4. Enter the password for that windows account.
   
5. Click OK.
4. Click List on the Main Menu, to see all your tables.
5. Select a table, such as SALES.FLASH.DAILY
   
6. Click Open. Note that the dots are illegal in SQL table names, so they will be changed to underscores.
7. It was not necessary for us to configure any privileges. Possibly because the account was an admin. You may wish to try an Administrator account first as well, then come back here to refine the permissions after you have it working.
8. Click Map Attributes
9. Click the columns you want, and hit Add. You may be prompted to rename your column, swapping out illegal characters with underscores.
10. Click OK.
11. Click Close.
12. Hit List on the Main Menu and you should see your SQL Table listed in the right column.
13. You can exit VSG.
    
6. At this point, you should be able to access data in your Storis database via ODBC. So if you're an Access user, you're just about done. You can create a linked table in your usual way, specifying this DSN for your connection information. For .NET programmers, continue:
   
7. Your ConnectionString will look something like this: <add key="StorisSystemDsn" value="dsn=StorisUnidata;srv=storis;dbq=YourDatabaseName;uid=YourUserName;pwd=YourPassword;" />
8. If you're using the Enterprise Library Data Access Application Block (DAAB), your connection string will look more like: <add name="StorisOdbc" connectionString="dsn=StorisUnidata;srv=storis;dbq=YourDatabaseName;uid=YourUserName;pwd=YourPassword;" providerName="System.Data.Odbc" />
9. You're ready to code!
10. If your server is 64-bit, your app will not be able to load the 32-bit ODBC driver, and as far as I know, no 64-bit one is available. To get it working in IIS7 on a 64-bit box:
1. Create a new application pool, and call it something like StorisApp32
2. In its Advanced Settings, Set Enable 32-Bit Applications to True.
3. Set your app to use this application pool.
4. It will now run in 32-bit mode and load the ODBC driver.
5. You do not have to change the way you compile (no need to specify x86 only, or anything like that).
   

Grab some data and bind it to a GridView called gvRecords like this:

OdbcConnection odbcConnection = new OdbcConnection(ConfigurationManager.AppSettings["StorisSystemDsn"]);
OdbcDataAdapter odbcDataAdapter = new OdbcDataAdapter("select * from from SALES_FLASH_DAILY", odbcConnection);
DataSet dataSet = new DataSet();
odbcDataAdapter.Fill(dataSet);
gvRecords.DataSource = dataSet.Tables[0];
gvRecords.DataBind();

If using the Enterprise Library, try this:

Database db = DatabaseFactory.CreateDatabase("StorisOdbc");
DbCommand dbCommand = db.GetSqlStringCommand("select * from from SALES_FLASH_DAILY");
DataSet dataSet = db.ExecuteDataSet(dbCommand);
gvRecords.DataSource = dataSet.Tables[0];
gvRecords.DataBind();

That worked for us, and I hope it works for you!

Notes: I was not able to get the OLEDB Driver to work. I kept getting errors about the provider name not being correct. I tried different provider names, even using a script to get the exact name registered with the system, but to no avail. If you get it working, please leave a comment with some instructions :)

You might see OPTION=3 in your MySQL connection string. That number--3 in this case--is the sum of a couple MySQL option flags. In this case, it's

1. FLAG_FIELD_LENGTH: "Do not Optimize Column Width", and
2. FLAG_FOUND_ROWS: "Return Matching Rows

So, that option setting allows you to direct your MySQL server to behave in a specific manner for the duration of each connection. A complete table of these options is available in the MySQL 5.0 Reference Manual.

You might also want to use OPTION=67108864, which allows you to execute multiple sql statements in a single MySQL Connector/ODBC batch, separated by semicolons. To keep other things working the way most people expect, just use 67108867, which is all three options combined.

If you've got the Enterprise Library installed and already know how to connect to SQL Server databases, connecting to MySQL databases is not any harder.

One way to do it is to use ODBC. This is what I did:

1. Go to MySQL.com and download the latest MySQL ODBC connector. As I write this it's 5.1.5. I used the 64-bit version, as I have 64-bit Vista.
   
2. Install the ODBC Connector. I chose to use the no-installer version. I just unzipped it and ran Install.bat at an administrator's command prompt. The MSI version probably works fine, but I did it this way back when I installed the 3.51 connector.
   
3. Verify the installation by opening your ODBC control panel and checking the Drivers tab. You should see the MySQL ODBC 5.1 Driver listed there. It seems to even co-exist peacefully with the older 3.51 version if you already have that. Additionally it coexists peacefully with the .NET connector if that is installed too.
4. At this point you will be doing what you've done to connect to a SQL Server database. All you need to know is what to use for a connection string.
5. Here's what mine looks like:
   <add name="MySqlDatabaseTest" connectionString="server=myservername;database=mydbname;uid=myusername;pwd=mypassword;driver={MySQL ODBC 5.1 Driver};option=3;" providerName="System.Data.Odbc" />
6. Of course you can set "name" to whatever you want.
7. If this is your only database, you can set it up as the defaultDatabase like this: <dataConfiguration defaultDatabase="MySqlDatabaseTest"/>
8. Access your data in your code like you always do! Here's a plain text sql example:

public List<Contact> Contact_SelectAll()
{
    string sql = string.Format(@"
        select
            *
        from
            Contact
    ");

    List<Contact> contactList = new List<Contact>();
    Database db = DatabaseFactory.CreateDatabase("MySqlDatabaseTest");
    DbCommand dbCommand = db.GetSqlStringCommand(sql);
    using (IDataReader dataReader = db.ExecuteReader(dbCommand))
    {
        while (dataReader.Read())
        {
            Contact contact = new Contact();
            contact.ID = (int) dataReader["ContactID"];
            contact.FirstName = dataReader["ContactFName"].ToString();
            contact.LastName = dataReader["ContactLName"].ToString();
            contactList.Add(contact);
        }
    }

    return contactList;
}

Another way to do it is to build and use a MySql provider. This guy did that.
I learned how to do this by adapting these instructions for connecting to Access.
Oh, and here are some more MySql Connection String samples.

For the longest time my HTC Touch Pro has told me I've got a voicemail, but it's wrong. I don't. It somehow got out of sync. The phone has a way to reset the voicemail indicator, but it's buried pretty well. How to reset the voicemail indicator of your Windows Mobile 6.1 device:

1. Hit the "Phone" button like you would to place a call.
2. Instead of dialing the number, tap "Menu".
3. Tap "Options".
4. Navigate to the "Services" tab.
5. Choose "Voicemail" from the list box.
6. Click "Get Settings..."
7. Hit the "Clear" button.
8. Press "ok" to close the window.

Your main screen should reflect this action immediately, and should not indicate that you have a voicemail!

The Event Log shows: "Volume Shadow Copy Service error: An internal inconsistency was detected in trying to contact shadow copy service writers."

I noticed that if, at a command prompt, I ran "vssadmin list writers", I got nothing back. I was under the impression that all the VSS-compatible writers should be listed, such as SQL Server.

This was KILLING ME all morning. I'd been running backups just fine on this server for the longest time, and it stopped working. I think it was related to my uninstallation of Windows Desktop Search 4.0, but the KB article related to that didn't help. Maybe it was some update? Other articles and forum posts suggesting that I stop the VSS and SWPRV services and register a bunch of DLLs didn't help either.

Finally I found the solution. Well, it worked for me anyway. It was a variation of a forum post I found in google's cache. Here's what I did:

1. Remove the registry key "HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}". You should probably export it first so you can restore it if this doesn't work for you.
2. Reboot.
3. The key is re-created.
4. "vssadmin list writers" returns several writers.
5. The Backup Utility no longer hangs on "Preparing to backup using shadow copy..." longer than maybe 20 seconds. The backup runs normally now!

This server is a VMWare virtual machine, in case that matters.

I'm looking into making the switch from SourceSafe to SVN.

But, when I installed the 64-bit TortoiseSVN client version 1.5.5 on my Vista Ultimate x64 box, I got a BSOD upon the next reboot. The error was IRQL_NOT_LESS_OR_EQUAL.

I was able to boot by hitting F8 and going into the Last Known Good configuration. Once I got back to my desktop, I uninstalled the SVN client and rebooted again. This time, no crash. It was definitely the client, or something triggered by it.

I tried a re-install of the client, but this time with my antivirus disabled (Eset Nod32 64-bit) and everything else quit out of the notification area (ATI Catalyst stuff, SyncBack Pro, Daemon Tools, various Logitech stuff for my G15 and MX 1000, Window Clippings, HP Digital Imaging Monitor). The install went smoothly and I made it back into windows just fine, with the SVN client working, including shell integration.

My hunch is that some aggressive anti-virus protection was keeping the client from installing itself properly. Upon reboot, windows encountered some partially loaded software, couldn't make sense of it, and crashed. It's rare to see a BSOD that is not hardware or driver related, so I think some driver was getting confused somewhere.

2008-12-10 Update: Even after reinstalling Tortoise SVN with anti-virus disabled I was having BSODs on later reboots. I have now removed Eset Nod32 x64 Anti-virus, Daemon Tools, Adobe Version Cue Server, and Adobe Drive CS4 x64. Things seem to be working now. My new theory is that it was Adobe Drive CS4 x64. This app does version control and is a shell extension just like Tortoise SVN. I bet they were conflicting.

2008-12-10 Update 2: Successive reboots were OK, but when trying to run a disk check upon reboot, I was bluescreening. Thinking about this more carefully, I actually had it working earlier where it would boot up OK, but bluescreen during the disk check, if one was scheduled for the next bootup. I used SysInternals Autoruns app to search for stuff that is starting up with the system that may be conflicting. Doing a search for "Adobe" finds some stuff other than Adobe Reader / PDF-related stuff. Specifically I saw an Adobe Device Somethingerother (I should have written it down before deleting it, but I figured if I needed it back I'd reinstall CS4) and an Adobe File System driver. They both sound like they're related to the Versioning system or are otherwise related to hardware device management, which means they may mess with kernel-mode code, which can cause a BSOD. So, I removed both of those and I can now reboot and even run a disk check without problems. I THINK I've got it at this point but I'll let this configuration ride for a bit before I mark this as Solved.

2009-03-08 Update: No crashes in months, so this is a done deal! SOLVED!

The onboard Atheros LAN (never heard of them) on my P5Q Pro motherboard was freezing if I transferred large files (a few gigs) over the network. My Windows Server 2008 Server x64 driver was WHQL and current according to the ASUS support site. I went directly to Atheros and found a more recent driver that was also WHQL. I thought that would fix it but the problem persisted!

So I opened up my box-o-old-PCI-cards and I had an Intel Pro/1000 MT Desktop LAN adapter in there. After uninstalling the Atheros driver and disabling it in the BIOS, I installed the Intel card and its most recent driver.

Now the server is solid again, and can transfer large files with ease. I moved a 5 gig rar at over 80 meg/sec! So I don't know if my Atheros experience is common or I just got a bad board, but I'd rather just use an old, reliable part than RMA this motherboard. The Intel Pro/1000 series rocks (I have several of them, single and dual port varieties, PCI and PCI-X varieties).

So I upgraded a Virtual Machine Host to an ASUS P5Q Pro and 3Ghz Core 2 Duo. The installation went smoothly except for a couple things. One of them was that the Marvell BIOS would hang for over a minute with every bootup. This was pretty annoying but I eventually fixed it by changing the single optical drive that was on the IDE controller from Cable Select to Master. Now the BIOS takes only a couple seconds!

I think this behavior is by design, where Windows Vista and Windows Server 2008 treat networks they do not understand as public ones, assuming they are more dangerous. This poses a problem with VMWare Workstation 6.5 and VMWare Server 2.0, whose networks never register as anything other than Unidentified Networks, as far as I know.

So, if I'd like a computer running VMWare (a host) to be available for Network Discovery and / or File Sharing, I need to configure these options every time I boot up that computer, which is pretty annoying. Since I don't use the NAT or DHCP features of VMWare (I use only network bridging), I found a way to get rid of the Unidentified Network entirely by disabling the VMWare options I don't use. I can always enable them later.

1. Start the VMWare Network Editor as an Administrator
   
1. Hit the windows key and start typing "Network" without the quotes.
2. Right click "Virtual Network Editor" and select Run as Administrator.
2. On the NAT tab, set the VMnet host to Disabled and hit Apply. The Service Status should now read "Stopped". If you don't have an apply button it's because you didn't run the Virtual Network Editor as an Administrator.
   
3. On the DHCP tab, remove the two Virtual Networks called VMnet1 and VMnet8. Stop the DHCP Service, and hit Apply.
4. On the Host Virtual Adapters tab, remove VMnet1 and VMnet8 again, and hit Apply. This should cause the unidentified network to disappear from the Network and Sharing Center.

With no Unidentified Networks, your system should properly persist the Network Discovery and File Sharing options.

VMWare adapter bridging still works, and resources previously occupied by unused NAT and DHCP features are now freed up. If you ever need all this stuff back, just restore your original settings. I'd just use an unmodified VMWare host for reference.

2008/12/07 Update: I found an alternative work-around. You CAN change Vista and Server 2008's default behavior for Unidentified Networks. Just run the Local Security Policy. You'll see the setting under Network List Manager Policies. It's simply called "Unidentified Networks". Change the Location Type to Private and you're all set. You can leave User Permissions unset because the default setting will allow you to change the location. Immediately, and upon further reboots, your VMWare Unidentified Network will show up as Private, which will allow your Discoverability and File Sharing settings to survive system restarts.

Security Warning: By changing this setting, you're saying you trust unidentified networks to an extent. For example, if you were to install a device or application that created a network windows could not identify, it would immediately become private, and take on the private profile of your firewall, which is generally less restrictive. I personally find this risk acceptable, because I doubt I will be creating many unidentified networks.

I had the weirdest problem. My Logitech G15 Programmable Keyboard's macros (assigned to the G Keys) were not running in Visual Studio. At first I thought they were not working at all, but then I noticed they worked fine in Notepad and just about every other app I had running. So why not Visual Studio? I could record them there, but not execute them. Weird!

Well, because I do web development on IIS, I need to run Visual Studio as an Administrator. Since I run the Logitech G-series Keyboard Profiler under my normal, limited user context, it was Vista's security that was preventing my G keys from working. The amount of interaction between limited-user-run apps and administrator-run apps is severely limited, so that limited user apps cannot inherit the administrative rights of administrator-run apps. Makes sense.

The solution: Run the Logitech G-series Keyboard Profiler as an administrator. It will now have the permissions to inject keystrokes into applications run by an administrator account!

Security Warning: By doing this, you're trusting the keyboard profiler. You're trusting that it won't accidentally mess up your system, and you're trusting that it doesn't have any exploits that malicious users could use to get to the rest of your system. I personally do not think this is a significant risk. It's a risk you probably wouldn't even think about if you were using Windows XP. If you keep your system clean, this should be a "hole" you can live with. Just my opinion.