用于查询的类似下拉组合框的功能
informix 客户端工具是否可以提供以下类型的功能？
当用户键入名称的前两个字符时，下拉列表为空。在第三个字符处，列表仅填充以这三个字符开头的名称。在第四个字符处，MS-Access 完成第一个匹配的名称（假设组合的自动扩展已打开）。一旦输入了足够多的字符来识别客户，用户就会跳到下一个字段。
在击键之间加载组合所花费的时间是最短的。对于每个条目，这种情况只会发生一次，除非用户再次在前三个字符之间退格。
如果您的列表仍然包含太多记录，您可以通过将常量 conSuburbMin 的值从 3 更改为 4，将记录数量减少另一个数量级。
Is it possible to provide the following type of functionality with informix client tools?
As the user types the first two characters of a name, the drop-down list is empty. At the third character, the list fills with just the names beginning with those three characters. At the fourth character, MS-Access completes the first matching name (assuming the combo's AutoExpand is on). Once enough characters are typed to identify the customer, the user tabs to the next field.
The time taken to load the combo between keystrokes is minimal. This occurs once only for each entry, unless the user backspaces through the first three characters again.
If your list still contains too many records, you can reduce them by another order of magnitude by changing the value of constant conSuburbMin from 3 to 4.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这需要两件事的组合，其中只有其中之一部分受 Informix DBMS 或 Informix Client API 的控制。
首先，您需要接受用户输入的小工具来异步生成与用户键入的内容相匹配的查询，从 DBMS 获取一些结果并显示它们。其次，您需要 DBMS 快速响应此类查询。问题的一部分是“查询采用什么形式”。但基本功能是：
您可能会也可能不会担心“第一行优化”；你可能会也可能不会为 ORDER BY 烦恼。您的代码只会选择前 N 行。您可以使用一些优先级信息（最常用的名称等）来完成此操作。
但这对于任何 DBMS 来说基本上都是相同的逻辑 - 给出或获取细节，例如处理案例映射的技术选择（函数调用与列） ) 以及子字符串与 LIKE 'abc%' 的表示法。
然而，棘手的事情是用户输入与从 DBMS 收集数据的异步组合；最好使用多个线程来处理，一个处理用户输入，一个处理 DBMS，（可能）一个处理显示（或者也可能是处理用户输入的线程）。这需要连接到 UI API - 而不是 Informix API 自己做的事情。 UI 可以通过 ODBC 或任何其他稍微相似的 API 轻松访问 Informix（或任何其他 DBMS）。
This requires a combination of two things, only one of which is partially under the control of Informix the DBMS or Informix the Client API.
First of all, you need the gadget that is accepting user input to asynchronously generate a query which matches what the user has typed, fetches some of the results from the DBMS, and shows them. Secondly, you need the DBMS to respond rapidly to such queries. Part of the issue is 'what form does the query take'. But the basic functionality is:
You might or might not bother with 'first rows optimization'; you might or might not bother with an ORDER BY. Your code would only select the first N rows. You might do it with some prioritization information - most frequently used names, etc.
But this is logic is basically the same for any DBMS - give or take the details such as the choice of technique for dealing with case-mapping (function call vs column) and notation for substrings vs LIKE 'abc%'.
The tricky stuff, though, is the asynchronous combination of user-input plus collecting data from the DBMS; that is best handled with multiple threads, one dealing with the user input, one dealing with the DBMS and (possibly) one dealing with the display (or that might also be the one dealing with user input). And that requires hooking into the UI API - not something that the Informix APIs do of their own accord. The UI can get at Informix (or any other DBMS) easily enough through ODBC or any other faintly similar API.