I am usually not one to find bugs in programs. But the number of 'rough edges' I have found so far is disturbing. Here's another.

I create a new organization, "Sirius Radio." I then create a new task, "Signed up for Sirius Radio." I attempt to link the task by opening the newly created task form and clicking the + sign. The recently created Sirius cannot be found. All other orgaizations can be found however. I then attempt to go to differnt windows, thinking Daylight will refresh itself, still can not link the new task to the new organization. "Sirius" cannot be found. I then close Daylight and reopen. Still no joy. Finally, I go to the task screen, drag the task over to the Organization screen, dropping on Sirius. Joy! It works! And I can now add other tasks to Sirius through the task + function.
Why did it not work to begin with?

This message has been edited. Last edited by: JackR,

Okay, I'll eat my hat if this isn't a bug. I just found out that I can replicate the issue every every time I try. I also found out that the newly created organization cannot be found by using a Quick Find. However, as soon as I rebuild the indexes using the rebuild function in Preferences, the new organization can be found and linked to.

Doesn't Daylight automatically create the index when I create a new Organization? I thought the Rebuild function was simply for repairing a damaged index.

More information. The organizatios that cannot be found are ones that have no contact initially attached. If I create a new Org and at the same time link a contact, then I have no problem subsequently finding the new Org. However, if I have no contacts initially in the new Org, (and I do that sometimes,) then the new Org cannot be found unless I rebuild the index. Would appreciate a reply from Marketcircle on this.

After doing the testing I have not been able to reproduce this issue you're having. I would suggest you contact our support team about this unusual behavior.

What version of Daylite are you using?
What OS version are you using?

Thanks for your concern and feedback.

This message has been edited. Last edited by: Oscar,

Using the latest version of both.

Just updated to the new build. Same issue. I must manually rebuild the index in order for a newly created lone organization, (one with no Contacts,) to be found using Quick Find.

I read in the release notes something about some sort of index corruption detection. Can't seem to discover how that feature works.

That index corruption detection is for a different issue than the one you're experiencing. Have you contacted our support team?

A followup for those interested. I contacted support and they asked me to mail them my database. I indicated that, for privacy reasons, I was not willing to do that. We tried to diagnose the problem via email, but to no success. It appears I have a corrupt database, which is very disappointing indeed. I am not using this on a multiuser system, and been giving the program a trial, (I did pay for it,) as a prelude to moving my team over to Daylight completely. Very disconcerting to have corruption issues, but even more disconcerting that there is no way (other than to email support my database,) no way to rebuild this database. In a previous program, the one we currently use, we could *completely* export the *entire* database to a brand new copy, customizations and all. Evidently this is not possible with Daylight. When fished, one would have a brand new database, free of any corruption. I am told that this cannot be done in Daylight.

There is a tool that will allow you to "dump and load" each table in the database (146 of them), however, in your case, from what I've gathered support telling me, the problem would propagate to your the new database anyways.

Also - I don't think we've ever had a reason to dump and load an entire database - ever. We've always been able to solve these kinds of issues with a simple sql command or added code in the app to handle the situation.

The only problem we have not been able to recover from is when the user moves a database while it is running (which is why we hide the database from plain view).

It seems that you have one either an unexpected character in a field or a field that we expect not to be empty is empty.

I'm sure support has told you that we are willing to sign an NDA if necessary.

Yes, they offered to sign an NDA. Unfortunately that is not acceptable for us. I should add that Matthew was very polite and willing to help as much as he could.

Question: How do you think this corruption occured?

Without looking at it, it's really hard to say. It could be from an import (unlikely but possible) or it could be a bug somewhere - something silly like setting something to null when we shouldn't be.

We could also isolate it if you give us remote access (so no need to send us your database).

I just hope/pray that this corruption issue was a extremely rare occurrence, and that I was simply very unlucky to experience my first time out. I'd be lying if I said I didn't have my doubts.

AJ, how do I get the program that will dump the tables, the one you referred to earlier? You said it probably wouldn't help, as the issue would simply propagate to the new database. Nothing ventured nothing gained, especially when there is no understanding of why this corruption has happened to begin with.

AJ,

Just following up on my question: is that program available, the one used to dump the tables?

If I had Filemaker link, am I able to duplicate *every* table in Daylight?

Sorry for the delay. I've been quite busy lately.

I'm almost 100% sure that doing a dump and load will simply propagate the problem (like 99.999999999999999% sure). And it would take you a really long time to do. We've **never** had to do this, so we don't have a canned process for this either.

Can you send your logs into support again please (mention this thread) and I'll look at the logs again. Maybe I or someone in engineering can gleen something more useful.

quote:

Originally posted by AJ:
There is a tool that will allow you to "dump and load" each table in the database (146 of them), however, in your case, from what I've gathered support telling me, the problem would propagate to your the new database anyways.

Also - I don't think we've ever had a reason to dump and load an entire database - ever. We've always been able to solve these kinds of issues with a simple sql command or added code in the app to handle the situation.

The only problem we have not been able to recover from is when the user moves a database while it is running (which is why we hide the database from plain view).

It seems that you have one either an unexpected character in a field or a field that we expect not to be empty is empty.

I'm sure support has told you that we are willing to sign an NDA if necessary.

AJ,

Can you elaborate on "moving a database while it is running?" Also, I use Mozy online backup to backup data. It supposedly has the ability to back up open files. Does this present a possibility for corruption of the Daylight database? Mozy backs up automatically at prest times, so a database may be running.