Update on Update

[dhaupert]

Hi folks,

I wanted to give you an update on where I am with the development of the Windows Mobile update. I ran into a snag last week debugging a known issue (note fields being truncated when using forms). Even though HanDBase works well with new Windows Mobile 6.x devices, to support older devices we need to compile for PPC 2003 OS, which predates even Window Mobile 5. This means using an older version of their development tools which only support debugging on older devices. Over the years, my pre WM5 collection has dwindled as devices breathed their last breath. The mainstay has been my Dell Axim X50V.

Last week, while charging it, I noticed the device was really hot and would not power up. I pulled it from the cradle and opened the battery cover and found that the Li-Ion battery pack was swollen and rounded, not to mention burning hot. From the stories I've read online, that's a really bad sign- Li-ion batteries that are swelling are generally a few moments away from an explosion, which has resulted in serious fires, burns and even the death of some people (typically those with the device in their pocket at the time of it exploding). Thank God, I did not see any of that happen- I removed the battery and am going to switch to using a different handheld. But I wanted to let you know that this will add to the time it takes to get this update out as I don't have any other compatible pre-WM5 devices that are in running state right now.

Sorry for the additional delay, and I'll keep you up to date on this!

[zooguy1492]

Can you give us another update on the WM update? Not to rush you but back in February, you said it would probably be released that month:
http://tech.groups.yahoo.com/group/HanD ... sage/22695

There have been many bugs reported in these forums and I'd like to know which ones have been addressed in this coming release.
For example, is the MS Access sync issue been/being addressed?

Yes, I am impatient... Like a child waiting for Christmas that never comes

[griffinr]

Hey Dave,

What's the latest status?

Bob

[dhaupert]

Hi all,

I'm looking at this thread and wondering where my last two postings have gone. I have posted two updates to the original post, but don't see them there and am concerned. I will check to see where they went. Here was the sequence of events:

- I got the new development environment working a little over a week ago, spent some time fixing issues and such with said update last week and later in the week sent a few beta testers a version to try and verify it was working well on devices. It did, and the popup menu issue on VGA screens is now reported fixed.

- I am now working (got my new battery as well) on the remainder of bugs for this release. I hope to have a development version released next week.

As for a list of what else is fixed, I don't have that info compiled to share at this moment, but thus far the main focus prior to the battery incident had been improved Vista compatibility. Specifically this means changes that will hopefully allow syncing on Vista machines without issues with whether UAE is turned on or off. Next I'm working on the Forms note truncation problem, and I have a handful of other smaller bugs to complete. Can you reiterate your Access sync issue? I'm not aware of anything that fits that description.

[zooguy1492]

The MS Access sync problem is that I could not sync a HanDBase database to MS Access using the PC Desktop environment and WM handheld... The problem was reported:
http://tech.groups.yahoo.com/group/HanD ... sage/22439
as well as through MANY e-mails and ticket numbers (e.g. Ticket Number: 468056, and 468056).

I was told this by Brian:

Thanks for your email. I want to let you know that David has confirmed that the desktop overwrites handheld sync isn't working properly but the one way sync option is working properly.

While I'm at it, here are a few other issues I've brought up before:
- Popup menus not rendering correctly on Touch Pro:
http://tech.groups.yahoo.com/group/HanD ... sage/22487

- Relationship field not updating properly:
http://tech.groups.yahoo.com/group/HanD ... sage/22566

- Copy Record to New not copy Time field properly:
http://tech.groups.yahoo.com/group/HanD ... sage/22578
Also mentioned in Ticket Number 468056.

- Renaming database and custom forms no longer available:
http://tech.groups.yahoo.com/group/HanD ... sage/22651

- Syncing views between Handheld and Desktop (you probably think of this as a feature):
http://tech.groups.yahoo.com/group/HanD ... sage/22415

It also would be nice if the "long true-unique" trick was made more 'user-friendly' and that unique, link, linked were removed if they shouldn't be used. It also would be nice if the condition field was updated when adding a field (see other thread).

[dhaupert]

It also would be nice if the "long true-unique" trick was made more 'user-friendly' and that unique, link, linked were removed if they shouldn't be used. It also would be nice if the condition field was updated when adding a field (see other thread).

I'll comment on your issues posted separately but wanted to address this. The Link/Linked and Unique fields are very useful in many situations. In the case of the link and linked field, these are not supplanted by the relationship field, they serve a different purpose and they are more widely used in database designs than the relationship for good reason! The only limitation they have is in interfacing with outside database managers where new records are going be created. And that's because the outside database managers do not know how to generate a matching value for this type. Hence the need for the relationship field in those cases. But please don't confuse this with them being not-useful. Most people are not interfacing with outside systems and the link and linked are as convenient and automatic as a RDBMS can be in this case!

Regarding the unique field, this too is still useful- for example, I use it often to resolve ties in sorting, as you've likely seen. When you are for example sorting by a value or two where there is a chance for ties, and to keep the sort order stable in this instance, you can add the unique field value as a tie-breaker. It's also quite useful in cases where you are entering data on one device only!

In regards to the long unique trick, this is not something most people need to use, but for those that are, it would be nicer if there were a better way. But adding a new field in a minor version update is not going to happen, we save updates that change the format of our database for major updates. So this is not something you'll likely see in the short term.

I'll comment on your specific bugs in a followup..

[zooguy1492]

I am sorry I've hit a nerve...

I know in the past, you attempted to explain to me the difference between some of these fields. To be honest, I'm still not clear. It would probably make sense if I was the programmer that implemented it or was familar with the history of the system but from the end user's point of view, I'm not understanding. I am EXTREMELY familar with SQL and relational databases. I've also been a software programmer for 30 years. In general, all I really want to do is relate two database and I'm being given too many choices. As you see by my other posts, I picked a "relationship-unique" fields, which I'm now being told was incorrect. The Windows Desktop Version 4 manual (dated 12/5/2007) doesn't shed much light on the intriquicies of these fields.

In the case of the link and linked field, these are not supplanted by the relationship field, they serve a different purpose and they are more widely used in database designs than the relationship for good reason! The only limitation they have is in interfacing with outside database managers where new records are going be created. And that's because the outside database managers do not know how to generate a matching value for this type. Hence the need for the relationship field in those cases. But please don't confuse this with them being not-useful. Most people are not interfacing with outside systems and the link and linked are as convenient and automatic as a RDBMS can be in this case!..

Simple question.. What do you mean by "outside database managers"? I just want to sync one handheld with one desktop...

This link (http://www.ddhsoftware.com/knowledgebase.html?read=195&UID=) describes supposedly describes the relationship field vs link/linked fields but most of it simply describes how to setup the database rather than the specific advantage and disadvantage of each (in addition to it being dated 2002 and describing HanDBase 3.0):

In addition, the Basic Tutorial 3 (Link/Linked) seems to be broken on this page
http://www.ddhsoftware.com/support.html

Also, I think what you've told me in the past is that I shouldn't use a "relationship-unique" relationship when you could modify the database on the handheld and desktop (see another thread about unique fields). Instead you say I should use "relationship-(link/conditional) trick to make sure I get a true unique field.

Regarding the unique field, this too is still useful- for example, I use it often to resolve ties in sorting, as you've likely seen. When you are for example sorting by a value or two where there is a chance for ties, and to keep the sort order stable in this instance, you can add the unique field value as a tie-breaker. It's also quite useful in cases where you are entering data on one device only!

By "one device" you mean only one desktop OR one handheld and not both. Correct?

Again, it's not my intention to be a pain... I've been trying to get my databases configured for the past 6 months and I'm getting nowhere. I have alot of time invested in getting my databases into HanDBase and I'd like others not to go through the same trouble. Everywhere I turn now, I'm having trouble.

Again, sorry...

[dhaupert]

I am sorry I've hit a nerve...

I know in the past, you attempted to explain to me the difference between some of these fields. To be honest, I'm still not clear. It would probably make sense if I was the programmer that implemented it or was familar with the history of the system but from the end user's point of view, I'm not understanding. I am EXTREMELY familar with SQL and relational databases. I've also been a software programmer for 30 years. In general, all I really want to do is relate two database and I'm being given too many choices. As you see by my other posts, I picked a "relationship-unique" fields, which I'm now being told was incorrect. The Windows Desktop Version 4 manual (dated 12/5/2007) doesn't shed much light on the intriquicies of these fields.

First off, my apologies if it sounds like I was upset or frustrated in my last post. Was not intentional! I would agree that the concepts are confusing at first, but really most users seem to master them once they understand. There are several ways to relate data on HanDBase. Let's go over them here:

DB Popup: the simplest to understand, the field type is like a text field but it's popup list can come from another table. Many would argue this is not a truly relational field as the data is copied from the other database into this text field, but nonetheless, it still lets you relate data in one table to another. I assume this field type is not an issue and won't mention it any further!

Link and Linked: If you are familiar with other databases and SQL this field type may seem quite foreign to you. Here's the concept- the idea was to relate a parent table (containing a link) to a child table (containing the linked field) without forcing the end-user to create a unique value in either table. The link and linked field when set up properly take care of all of this for you, and because the relationship type is one to many, much of the program knows what to do with it. In addition, since HanDBase is a mobile application, there is a good chance that there are more than one user or device creating records, and the link and linked fields can handle this automatically as well.

I would hope that the tutorials for link and linked can explain how to set this field up properly, but the basic idea is that the parent needs a link field that points to the linked field in the child table. The child table needs it's linked field to point to the parent table.

There is only one downside to the link/linked field- interfacing with other database programs. While an export to another program like Access, SQL Server, etc is not a problem- the field types can be set up using the relationship designers of those programs, creating new records in a program that doesn't know how to create these values is a major issue. This is because in order to be unique among many devices and users the uniquely identified value must contain several facets to guarantee it's uniqueness. A simple number alone won't do- it would have to be many, many digits long to be represented this way!

So that said, if you are working with an outside program (ie, something that is not HanDBase) or importing existing data that already has some type of relationship defined, the Link and Linked field types are not the ones for you!

Relationship field type: This was designed in HanDBase 3.0 because of the above limitation and the increasing use by customers of 3rd party database programs like Microsoft Access where they had related tables already configured.

The concept here is that the database field type itself does not store any data, it's actually a connection whereby you specify two related fields. These related fields are a field in each database table that has a value matching the other, so that the program knows that the two records are related when their respective fields have a match. In this case, defining the values is not automatic- it's up to the end user to come up with a unique key value for the records and it would be most common to use something like a customer ID, patient ID, or something that you know is unique for each entity.

That should offer the most basic of explanations between the field types. My understanding of what you have been wanting to do was use the relationship field type because you had to export/import from some other database application. If you didn't, the link/linked field is definitely the best choice! If you do, then most typically you'd select a text field to store your key value in each database, and relate the two via the relationship field.

It seemed that you wanted to point the relationship field to a unique value so that the end-user would not have to come up with a value that is unique on their own. I and others have explained that the unique value is not globally unique- it's really more of a counter field and since there are potentially multiple copies of this (eg, your desktop, your handheld, and perhaps other desktops and handhelds, the chance of this field being and staying unique for each record is actually very small). If you need to do this, we suggested one of two options:

Using the 3rd party plugin called UserID from UnpluggedIdeas- this plugin lets you have a text field filled with a globally unique value and solves the problem of auto generating something unique.

An alternate workaround was to use the link fields generator to somehow set a value in the field that can be used as a globally unique identifier. This is I believe where you have been struggling for a few weeks now.

I'd like to be able to help you further with this, but really think that this is more of a personal technical support issue than it is a public forum topic at this point. In other words, if I could see your databases, get an idea of exactly what you're hoping to do, I can probably point you in the right direction with specific instructions to you!

Simple question.. What do you mean by "outside database managers"? I just want to sync one handheld with one desktop...

Hopefully the above clarifies this for you. If it's as you describe here, the link/linked field type are the perfect solution here.

This link (http://www.ddhsoftware.com/knowledgebase.html?read=195&UID=) describes supposedly describes the relationship field vs link/linked fields but most of it simply describes how to setup the database rather than the specific advantage and disadvantage of each (in addition to it being dated 2002 and describing HanDBase 3.0):

The information may be dated from 2002, but it's still accurate for the current HanDBase program as these field types have not changed since HanDBase 3.0! You mentioned it does not list the advantages and disadvantages, but there is a chart doing just that a few paragraphs down!

In addition, the Basic Tutorial 3 (Link/Linked) seems to be broken on this page
http://www.ddhsoftware.com/support.html

I'm seeing this as well and thanks for letting me know. I hope we'll have this link fixed tomorrow- sorry about that!

Also, I think what you've told me in the past is that I shouldn't use a "relationship-unique" relationship when you could modify the database on the handheld and desktop (see another thread about unique fields). Instead you say I should use "relationship-(link/conditional) trick to make sure I get a true unique field.

That was if you wanted to also sync to something like Access, SQL Server, etc. If not, then the link and linked fields do this for you!

Regarding the unique field, this too is still useful- for example, I use it often to resolve ties in sorting, as you've likely seen. When you are for example sorting by a value or two where there is a chance for ties, and to keep the sort order stable in this instance, you can add the unique field value as a tie-breaker. It's also quite useful in cases where you are entering data on one device only!

By "one device" you mean only one desktop OR one handheld and not both. Correct?

Correct!

Please let me know if this answers or doesn't answer any further questions you may have. And feel free to contact me directly at my email address listed below!

[dhaupert]

Just a further update on the upcoming maintenance release. I'm almost there- down to two bugs left to work on and hope to finish them if not tomorrow, on Thursday. There are a few items that were reported that I could never duplicate so the list may grow slightly if I get responses back from the users who reported it, or we can duplicate the issue on our own, but nonetheless, the time is near for this update.

Thanks for hanging in there for so long on this update!

[dhaupert]

So we are working on getting a development version together, hopefully to be live today or tomorrow the latest. This contains all the bug fixes and changes we've worked on. Since a lot of the installation aspects have been changed for improving our interaction with Vista infamous UAE, and since the base compiler tools were updated to work with the Windows Mobile 5 SDK (previously targetted Pocket PC 2002 and higher using older tools), we decided it best to release this as a development version and gauge feedback from those of you willing to try. I'll post a new topic once it's live, but wanted to let you know that we're almost ready!