新的效果图如下：


注意：这次我偷了一点懒，生成表格时用了“门牌号”字段，而不是像之前那样合成门牌号，所以你必须自己保证门牌号字段的正确性。


[ 本帖最后由 TonyDeng 于 2014-10-18 21:22 编辑 ]

上山容易下山难

我做这个及贴出来，是作为一种示范的，很多常见的问题都可以在这里找到解决方法，其实已经回答了很多坛上问过的问题。看不看是他们的事。

表格中出现多个“户主”，显然不是一个家庭，而是多个家庭（多户）呀！

那是你门牌号错了。都说你不是真实数据，我怎么可能一户一户去查，反正不同的户有不同的结果，不是多户合在一起的。

对不起老师！我再把表中的记录审核一遍。

你看我的源代码就知道了，那里用了一条SQL SELECT语句筛选记录供给表格，就是WHERE 门牌号，出来是怎样就怎样，不会错的，错了一定是数据错，即门牌号字段中数据错了，所以我211楼特异补充了最后一句话，提醒你注意。（哪里可能出问题，我心中很清楚，呵呵）

如果你检查到数据真的有错误，那么这就是一个活生生的例子，我曾经反复强调，表和数据库设计规范要求不要有冗余数据，原因就在这里。在使用和维护的过程中，确保冗余的数据一致性是要付出代价的。如果你不设计“门牌号”这个字段，那么迫使我（像之前一样）写一段代码构造门牌号，就不会出错。当然，要改回来不用那个字段，也很简单，所以我说偷了一个小懒，就是这个意思。

得到一个教训也是好的，不然很多人以为数据库的设计规范可以忽略，又总不明白人家为什么要那样规定，不碰过钉子，怎么明白道理。

好的，谢谢老师，我在细细的推敲。

嗯，你先看看数据的问题，到时我再把代码改一下，仍然是构造门牌号，不用那个字段。写程序，对任何地方都要有控制权，想怎么改就怎么改，那个程序才是你自己的，否则总是用人家现成的设计器之类，就是花架子，到时无法按需求而变，还得求人，这也是我很反对别人用设计器的原因。