关于一条对离线数据库进行查询的sql语句(100分)

R

receyes

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-01

• #1

小弟写了一条sql语句用于对大富翁离线数据库进行模糊查询，可是总是得
不到正确的结果:用rapidsqlpro5.22(通过ODBC访问Access)执行时，返回记
录为空(实际肯定不为空),用另一个通过DAO访问Access的sql工具执行时，
程序死机。如果单独执行Union的两个子句则没有问题。请各位大侠帮忙看
看问题究竟在哪里。另外请各位大侠推荐一种专问针对Access的sql工具。

SQL语句如下：

select id,subject,userfrom from letters
where parent = 0 And content like '*aaa*'
union
select id,subject,userfrom,parent from letters
where id in (select parent from letters where parent <> 0 And content like '*aaa*')

 

C

cAkk

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-01

• #2

关注.

关于Access的IN子句的用法,我也有同样的疑问,我曾经写过基本一样的语句,也是
死记,实际上没有死,似乎是死循环了.可能用法不对.

 

茶

茶叶蛋

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-01

• #3

我也写过类似的语句，目的是同时查询满足标题和内容都包含的SQL语句，
实际上没有死机，如果将其分解（不是分为两个分别查询的语句，那样的话会很快出结果）
成为只查id（好像是这样，记不清了），在tools菜单下面的那个Database工具里面
查询还是能够出结果的，只不过在等待的过程中我喝了一杯茶而已。

建议：绕过这个问题，当然有更好的解决方法另当别论。
我在今年上半年遇到这个问题的时候，最后想出来的歪办法是把整个纪录区域
分为若干个小纪录区域，再进行查找，这样还可以方便的显示出进度来，不过操纵麻
烦些，而且效率降低不少。
曹晓刚不用"content like '*ds*'这种办法，而且可以方便地中止，具体方
法可以看离线浏览器那里，虽然他没有实现多条件查询，不过他的方法还是可以参考
的。

 

3

3h

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-02

• #4

why not:

(subject like '%abc%') or (content like '%abc%')

 

R

receyes

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-02

• #5

以上的sql只是举个例子，实际上兄弟是希望构造一个多条件查询语句，至于条
件之间的And或Or则可以通过通过radio button自己选择.现在的关键是Union后
执行不了，也不出错，似乎陷入死循环.

 

C

cAkk

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-02

• #6

对. 我也是很想通过这个问题了解union和IN子句的用法.

 

R

receyes

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-03

• #7

搞定了，看来程序死机和DAO有关系，而sql语句本身也有小问题。下面是小弟
D4SP3中的测试结果，请各位试验一下：

1．通过用BDE连接Access，以上sql语句可以执行，但返回的结果集为空。将模
式匹配中的*改为%，则可得出正确结果，查询速度可以接受。

2．通过ADO访问Access(我用的是ADONIS)，情况和BDE相同，只要将sql中的*
改为%，可得出正确结果，速度明显快于BDE。

3．用RapidSqlpro5.22(通过ODBC访问Access)，也是将*改为%号后可得出正确结
果，但速度太慢。

4．通过DAO访问Access(我用的是Diamond 和gmDAO)，则会出现死机情况。

DiamondAccess确定有些问题。上次用它合并离线数据库中的数据，死活
执行不了insert into table1 select * from table2，换了个gmDAO才搞定。没
想到这次两个都不灵光了。看来以后还是要多用BDE。

啊....，困死了，明天再发分。

 

E

Energy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-03

• #8

如不做索引如下简单的查询也会奇慢
SELECT id, subject, userfrom, parent
FROM letters
Where id=20
UNION SELECT id, subject, userfrom, parent
FROM letters
Where id=30;

再有access2000已经支持union查询时使用memo字段，
升级到access2000或dao3.6吧。

我的测试结果，没索引--死寂
索引后--17秒
(K6-200)

 

E

Energy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-03

• #9

// 莫名其妙，又少了一段，而且是关键

我分析了一下这个问题，你们没错，dbe,odbc没错，dao更没错
错就错在，数据库根本没有索引，请你们对id,parent,roomid,
userfrom,datetime,subject等字段做一下索引。问题立刻能
解决。

这个故事告诉我们，有很多时候不要怀疑自己，也不要怀疑敌人
要怀疑环境！！！！！！！！！！！！！！！！！！！！！！！

如不做索引如下简单的查询也会奇慢
SELECT id, subject, userfrom, parent
FROM letters
Where id=20
UNION SELECT id, subject, userfrom, parent
FROM letters
Where id=30;

再有access2000已经支持union查询时使用memo字段，
升级到access2000或dao3.6吧。

我的测试结果，没索引--死寂
索引后--17秒
(K6-200)

 

C

cAkk

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-03

• #10

>>DiamondAccess确定有些问题。上次用它合并离线数据库中的数据，死活
>>执行不了insert into table1 select * from table2

没有的事,我也是用的diamond,可以执行该语句.

 

R

receyes

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-03

• #11

呵呵....Energy老兄所说的是正解，果然是索引的问题。加上索引以后没有问题
了。老兄教训的是，以后要多从自己方面找原因，不能乱怪控件。还有个问
题：使用DA0时通配符必须用*才能查询到正确结果，用%则不行，和BDE、ADO正
好相反，这是为什么？

to cAKK: 关于用DiamondAccess导数据，我是先把11月数据库的letters和users
两个表导入7月份的数据库，表名分别为letters1和users1。然后使用如下sql语
句insert into letters select * from letters1。结果使用DiamondAccess1.85
执行时出错:'syntax error in INSERT INTO statement';改用DiamondAccess1.9
执行则出现'invalid operation'的错误。而用gmDAO3.25执行则没有问题。我还
用过ADONIS3.5试过，也出错，具体信息记不清了，好像是说expert不允许为空。
请cAKK指点。

 

C

cAkk

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-03

• #12

>>使用DA0时通配符必须用*才能查询到正确结果，用%则不行，和BDE、ADO正好相反，这是为什么？
呵呵,这得问比尔.

2.我用得也是diamond185,好像很正常.

 

R

receyes

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-03

• #13

发分喽.

 

R

receyes

Unregistered / Unconfirmed

GUEST, unregistred user!

• 1999-12-03

• #14

多人接受答案了。