Announcing LDSql

[RossEvans]

This is lousy marketing practice, but I am renaming this system LDSql.

The new URL for the website is http://www.ldsql.com/

The detailed content of the site will be edited as soon as it is feasible for me to do so.

Meanwhile, the original post at the top of this thread cannot be edited by me. I would be obliged if any moderator empowered to do so would make that change at the top. Or at least make an insert to that effect in the top-level post.

[aebrown]

Meanwhile, the original post at the top of this thread cannot be edited by me. I would be obliged if any moderator empowered to do so would make that change at the top.

Done. But I would note that it appears that you missed one instance of LDSQLite on your LDSql site -- the one in the upper left corner.

I'm guessing you're working on it, but you also might want to rename your support group on Google Groups.

[RossEvans]

Done. But I would note that it appears that you missed one instance of LDSQLite on your LDSql site -- the one in the upper left corner.

I'm guessing you're working on it, but you also might want to rename your support group on Google Groups.

Thanks much!

I think I have done what I can do immediately on the main web site. To fix the link on the upper left corner, using the otherwise quick-and-easy authoring system at Google Sites, I think I have to rebuild the whole thing. I also will set up a new Google Groups.

EDIT: As it turns out, renaming both the web site and the Google Group was quite easy. (Thanks, Google!) All the high-references to the old name have now been changed to the new name. The URL for the support group did have to change. It is now http://groups.google.com/group/ldsql

I will take my time, and some care, to rename internal references in attached filenames and documentation in the next release.

[RossEvans]

One last observation about the stake and ward exports:

Now that Alan_Brown has cleared up the rules governing the "Indiv ID" and "HofH ID" columns, the three stake export files seem to contain the data for a robust schema based on solid primary and foreign keys.

That is not quite true for the ward MLS exports. They include HomeTeaching.csv and VisitingTeaching.csv, which are pretty lame as MLS spits them out. As we have discussed in this forum and the Community dev Wiki before, the MLS developers omitted any keys at all from those files. So they pose an inherent risk that there will be ambiguous records for home teachers, visitiing teachers or supervisors, and even a remote chance of ambiguous records for households or sisters being taught.

Every developer who relates these ward files together must grapple with that klunky problem. The solution I adopted in the LDSql schema is to select, semi-arbitrarily, a unique key for a member or household, and provide flags and views to warn users of potential ambiguities.

[RossEvans]

I have released a new version. The principal new features of v 0.9.2 are views that emulate the subreports of the Bishopric Action and Interview List in MLS, with extended fields that are not in the MLS reports also included:

• "Rpt Children Near Baptism"
• "Rpt Unbaptized Members"
• "Rpt Overdue Aaronic Ordinations"
• "Rpt YM Near Missions"
• "Rpt Men Not Served Mission"
• "Rpt Potential Missionary Couples"
• "Rpt Bishop Youth Interviews"
• "Rpt Bishopric Youth Interviews"
• "Rpt YSA Interviews"

See the Downloads section of the LDSql web site.

[RossEvans]

I have released v 0.9.3, which is available at the free Download page of the LDSql website:

http://www.ldsql.com

The principal new features of v 0.9.3 are a view that emulates the New Member Report in MLS, as well as enumerated callings and home-and visiting-teaching assignments for each member, concatenated and formatted for display. Those columns are available in most existing views. (Some now-redundant columns were deprecated.) See the release notes in the distribution package for details.

[RossEvans]

I have released v 0.9.4 of LDSql. It reimplements as tables three views introduced in 0.9.3. This change cures performance problems exhibited by that earlier release. These tables, containing concatenated text values by member for callings and HT/VT assignments, are populated at the time the database is loaded.

The prior release performed okay on my Windows laptop and desktop, but not well in when I prototyped queries of the schema on my Android.

[elderlarryhawkes-p40]

Thanks much!

I think I have done what I can do immediately on the main web site. To fix the link on the upper left corner, using the otherwise quick-and-easy authoring system at Google Sites, I think I have to rebuild the whole thing. I also will set up a new Google Groups.

EDIT: As it turns out, renaming both the web site and the Google Group was quite easy. (Thanks, Google!) All the high-references to the old name have now been changed to the new name. The URL for the support group did have to change. It is now http://groups.google.com/group/ldsql

I will take my time, and some care, to rename internal references in attached filenames and documentation in the next release.

;)
The Link in the first post at the top of this thread for the Support Group needs to be updated too.

Also, and your hopefully already addressing this, but does LDSql support the new export format of MLS 3.1 ? As you mention in the earlyer part of this thread, changes in the export from MLS will affect the ability of LDSql to properly work. I have been using MyWard from Shiblon software and it no longer works and will probably not get fixed since there have been no updates since 2006. I also tested MLS companion database and it didn't work with the new export format from MLS 3.1 either.

I'm hoping your LDSql will be a good replacement to MyWard. :p:)

[RossEvans]

;)
The Link in the first post at the top of this thread for the Support Group needs to be updated too.

Also, and your hopefully already addressing this, but does LDSql support the new export format of MLS 3.1 ? As you mention in the earlyer part of this thread, changes in the export from MLS will affect the ability of LDSql to properly work. I have been using MyWard from Shiblon software and it no longer works and will probably not get fixed since there have been no updates since 2006. I also tested MLS companion database and it didn't work with the new export format from MLS 3.1 either.

Yes, I am working on that. I anticipated the changes in 3.1, but until I saw the beta I -- like developers of any software that reads the MLS export files -- could not prepare in advance. I imagine that most third-party software will need to be fixed to accommodate the changes.

I'm hoping your LDSql will be a good replacement to MyWard. :p:)

LDSql is not really intended as a standalone application for end users. Rather it is designed as a generalized back end for multiple applications on different platforms. I am optimistic that developers of some apps, such as the recently open-source Ward Tools, will adopt it going forward. I have been in touch with several such developers.

An alternate target for LDSql are "power users" on personal computers, who can use the tables and views as-is to browse and query, import into spreadsheets or generic database programs, etc. But I have not built any user-friendly, front-end application for that.

[elderlarryhawkes-p40]

An alternate target for LDSql are "power users" on personal computers, who can use the tables and views as-is to browse and query, import into spreadsheets or generic database programs, etc. But I have not built any user-friendly, front-end application for that.

The output of MyWard was a set of HTML files that could be put on a PC or PDA, and with any web browser, used as a quick reference for most all ward callings and membership info.
Will LDSql output possibly provide an HTML output option?