| A:在这里。 | |
| A:与BDE相反, IBX的Refresh方法只刷新当前记录（数据集的游标指向的记录），这是为了减小网络流量。如果想更新多条记录，你需要关闭再重新打开数据集。 | |
| A:Recordcount返回得到的记录数。当打开一个数据集后，如果是空的数据集就返回0否则返回1，这是因为IBX只有当明确要求得到下一条记录时才取新的记录。当调用FetchAll方法（实际中并不推荐这样）后，RecordCount将返回数据集中记录的总数。 在IBX中, 不应该靠使用RecordCount得到存在的记录数，其实只是Paradox和Dbase需要它。如果你确实需要知道数据集中的总数，这里有一个技巧：不要调用FetchAll方法，大多数情况下只要在一个单独的TIBSQL中写一条类似"SELECT COUNT(*)"的语句然后执行就可以了。 | |
| Q:为什么把一个DBLookUpComboBox与一个IBQuery连接时，我在下拉框中只看到一条记录? A:再说一遍，IBX只有当明确要求得到下一条记录时才取记录。在DBLookupCombo使用中，企图在填下拉框之前依靠RecordCount来测量下拉区域的个数是不正确的方法（参见前一个问题）。 解决这个问题，只要在combo 的AfterOpen事件中写上下面的代码就可以了（强行获得记录以增加RecordCount的值）：
| |
| A:简单的说，TIBTable对C/S系统不友好，IBX包含这个组件只是出于兼容的原因。TIBDataSet是它的直接代替品。 详细一点，Table范例来自基于文件的数据库，如Paradox。基本上不管表位于哪里，所有的行和列（一般还有所有的索引信息）都被存在本地，这样SQL 引擎（如BDE）才能处理数据。既然不管怎样，所有的数据都要在本地重新存储，TTable 被设计为能在那种环境下很好的工作。 | |
| A:首先，检查你的事务隔离机制是否为Read Committed。如果是Snapshot模式（IB默认的设置） ，你就总是得到一个和刚开始一致的数据库视图——你看不到其他用户做的更新。提示：双击你的TIBTransaction组件，把事务隔离模式改为Read Committed。 然后，确保你的应用程序在所有更新操作后明确的提交了一个事务，使用CommitRetaining 或 Commit 之一即可。 最后，如果其他用户执行了一些更新而你的数据集已经在你的电脑上打开了，你只有关闭然后重新开启你的数据集才能看到那些更改；或者已更新的记录刚好是你当前访问的记录，那么调用Refresh方法也可以看到这条记录的更新后的样子。 | |
| A:简单的说，对于IBX，这很正常。使用CommitRetaining或RollbackRetaining可以保持你的数据集处于打开状态。 详细的解释是，在IBX中,如果你调用Commit或Rollback，会结束客户端一个存在事务。因此，所有依赖那个事务的东西都会被重置或变为无效。没有事务，IB不知道你应该看到的记录的版本——也就是说，IB不能确定你的版本隔离机制是ReadCommitted还是Snapshot。 实际上有两方面依赖于一个事务：1) 所有已经post给服务器的改变； 2) 所有当前打开的“游标”。 IB中的游标是你执行一个有多条记录返回的查询语句后得到的东西。通过请求获取记录，游标产生作用，直到游标用尽。所有打开的游标依赖于一个事务当前的句柄，那么如果终止那个事务，游标就无效了。 所以，当你调用Commit或Rollback时，IBX做的事情就是关闭你打开的所有数据集以避免出现无效游标的错误。这是因为，IBX没有像BDE和IBO那样在保持数据集开启和终止事务之间提供一个隔离层。 如果你想让你的数据集一直打开，则推荐使用CommitRetaining或RollbackRetaining来处理你工作的逻辑单元以避免关闭数据集；当你要释放服务器资源时，则要使用Commit或Rollback，这样垃圾收集就会运行。当然，你还是应该尽量经常执行Commit或Rollback 。 | |
| Q:在一个主/细表关系中使用缓存更新，当我Post时细表怎么不见了? A:这是Tdataset级别上的行为。当你进入编辑模式（或者ApplyUpdates）时，数据链接传递一个消息：游标已经被重置。这个消息使细表查询关闭且在新的设置上重新打开。解决的方法只有终止数据链接：在主表更新前，设置细表的数据源（DataSource）为空即可。 | |
英文原文：http://ib.freeservers.com
| |
| Where can I download latest version of IBX? Always from CodeCentral. | |
| How does Refresh work in IBX? Contrary to BDE's behavior, the Refresh method in IBX refreshes only the current record (where the dataset cursor is positionated) in order to minimize network traffic. If you want to refresh more than one record, close and re-open the dataset. | |
| How does RecordCount work in IBX? Recordcount returns the number of fetched records. Because IBX only fetches new records when something actually asks for the next record, after opening a dataset RecordCount will return 0 if the dataset is empty and 1 if it is not. After a FetchAll (not an advisable practice), RecordCount will return the total number of records in the dataset. In IBX, RecordCount should never be used to rely on how many records exist since it is only reliable for Paradox and DBase. If you really need to know the number of records in a dataset, issuing a "SELECT COUNT(*)" in a separate TIBSQL does the trick in most cases without the overhead of a FetchAll. | |
| When connecting a DBLookUpComboBox to a TIBQuery, I see just one record in the drop down list. Why? Again, IBX only fetches records when something actually asks for the next record. In the case of the DBLookupCombo, it is incorrectly relying on the RecordCount (see previous question) to scale the drop down area before trying to fill the drop down list. To solve it, just do the following in the combo's AfterOpen event (to force the fetching of at least a handful of records; this will increase the value of RecordCount):
| |
| Why should I avoid using TIBTable? Short answer: TIBTable is not C/S friendly, it is included in IBX for compatibility reasons only. TIBDataSet is the direct replacement. Not-so-short answer: The Table Paradigm comes from file based databases like Paradox. Basically no matter where the table is located all the rows and all the columns (and usually all the index information) is brought locally so the SQL engine (like the BDE) can work | |
| I can't see updates made by other users. Why? First, check if your transaction isolation mode is Read Committed. If it's Snapshot (the Interbase default), you'll always get a consistent view of the data -- i.e., you won't see changes made by other users. Hint: To change the transaction isolation mode to Read Committed, double-click on your TIBTransaction component. Next, make sure your application actually commits a transaction after any updates, either by using CommitRetaining or Commit. Finally, if your dataset is already open on your PC when another user performs some updates, you will see those changes only after you close and re-open the dataset, or after you call the Refresh method and the updated record is the current record you are viewing. | |
| Why do my datasets close when I call Commit or Rollback? Short answer: That's normal IBX behavior. Use CommitRetaining or RollbackRetaining to keep your datasets open. Not-so-short-answer: In IBX, if you call Commit or Rollback this brings to an end the existence of a transaction handle on the client. As a result, all things that depend upon that transaction need to be rectified or they will become invalid. Without a transaction, InterBase doesn't know which versions of the records you should see -- i.e., it doesn't know whether your isolation mode should be ReadCommitted or Snapshot. There are essentially two things that depend on a transaction. 1) Any changes that have been posted to the server and 2) any currently open "cursors". A cursor in InterBase is what you get after executing a select statement with multiple records to return. You interact with the cursor by requesting fetches until that cursor is exhausted. All open cursors are dependant upon a transaction handle being present and if that transaction is ended the cursor will become invalid. So, what IBX does when you call Commit or Rollback is to close all of your open datasets in order to avoid getting an invalid cursor error. This is because with IBX there isn't a layer that provides isolation between having datasets opened and ending transactions as the BDE and IBO do. If you want to keep your datasets open, it is recommended that you use CommitRetaining or RollbackRetaining for processing your logical units of work (changes) to avoid datasets closing and that you reserve the usage of Commit and Rollback for when you want to free up the server so it can do its garbage collection, etc. You should do a "hard" Commit or Rollback as frequently as possible, though. | |
| When using Cached Updates with a Master/Detail relation, details disappear when I post. What gives? This behavior is up at the TDataset level. When you go into Edit mode (or when | |
|
|
487
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
