我很生气，因为我用的东西我不能用钱和我的时间。我的决定是基于你vB.org显示。这不是说，你所提供的3.8的是不是太棒了，因为我认为这是。作者： vBET
你能告诉我你写上去（在vB.org初步介绍）说，这是不兼容的******!!与VB4。然后我会道歉，并关闭。
马特Olieman
无标题文档
自动翻译 （谷歌、 微软 ®， 网站 Yandex， SDL语言云， IBM Watson和Arpertium):
我很生气，因为我用的东西我不能用钱和我的时间。我的决定是基于你vB.org显示。这不是说，你所提供的3.8的是不是太棒了，因为我认为这是。
你能告诉我你写上去（在vB.org初步介绍）说，这是不兼容的******!!与VB4。然后我会道歉，并关闭。
马特Olieman
无标题文档
冷静下来的家伙 - 有3不同版本的软件 - 它明确规定每一个vb.org什么版本。保费3.x版，这是只有在这里，而不是vb.org，尚未公布为VB4，笔者前面提到的。我敢肯定，他会给你退款，如果你只问。
最后编辑者 tavenger5; 11-01-10 在 23:03.
我想我没要求....我很平静
马特Olieman
mycockpit.org
我知道你生气 - 你付出的东西，你不能立即使用。很多人会在这种情况而感到愤怒。
我们刚刚添加此免费版页上的信息，以避免今后发生此类混乱。这是从来没有的，我们打算作出任何混淆，我们非常遗憾的是，它发生。我们只是想给每个人都喜欢用它免费赠送。
正如我写 - 付费版本将与VB4兼容，它已经在我们的时间表。您可以对这个问题后vBET 4.0版本（VB4）提醒我们，我们将改变你的许可开始日期，所以你不会失去你一年的免费获得新版本的任何一天。
此解决方案是为您确定吗？
谢谢您，我很欣赏和接受你的报价。
我被突然的道歉。我觉得你已经有了一个美妙的产品，我期待着它一旦付诸于行动VB4兼容的版本可用。
我诚挚的谢意和良好的祝愿，
马特Olieman
mycockpit.org
很抱歉 - 我不理解，。我还以为你要快速反应 或 退款。我想我没要求....我很平静
马特Olieman
mycockpit.org
请参阅以前的帖子，为解决这个问题的主张，并明确有关情况的声明。
我们很高兴，使我们的客户满意，我 们的目的是让他们高兴
编辑：
刚刚看到你已经回答了我很高兴我们迂到双赢的局面 ! 我希望你会觉得在你的论坛上
在vBET 4.0将被释放，你可以使用vBET 2.4 - WIL已经将您的网页索 引，并释放后，你会做出更新更好的性能，给用户在不同的语言编写职位的可能性。
最后编辑者 vBET; 12-01-10 在 03:03.
只是为了确保：
目前，我暂时禁用缓存清除，因为我的服务器几乎下井时，在“正常删除”的更新缓存。因此，在几天后更新国防部，我可以将它设置到“正常删除”，一切都将平稳运行？
您可以使用缓存清除 - 现在有专门为这种情况下作出的其他战略。
此外，在vBET 3.3.0缓存是改变 - 有单独的表中为每一种语言，所以索引将缩小52倍和删除将会更快。
我们无法告诉它足够快的速度将您的论坛使用正常删除 - 这取决于表中，你将有多少行。 MySQL的数据将被删除时重建索引。这是花时间的原因 - vBET只能为您提供其他的方法来删除数据（和它提供了这种策略）。其余的是在MySQL的手中。
请只检查，如果仍然将有问题，那么它意味着MySQL将无法处理删除你在正常的方式缓存翻译的1 / 15。在这种情况下，只检查等策略。
如果有必要，我们可以考虑添加额外的策略 - 不重建索引快速删除。现在2个策略是使用快速删除和重建索引后， - 这当然是最耗时的一部分。我们可以添加策略，将不重建索引快速删除 - 这将您的索引增长，因此重建会不时必要的，但您将能够做手工，为您的服务器的最佳时间（一定的养护时间）。
有没有别的办法，我们可以做的（这意味着我们没有看到其他的解决方案现在） - 我写的是MySQL作出结算。
目前的短期和中期的缓存，有大约300万行各为12种语言。我觉得一切都正常，直到我达到600.000左右在每个。所以你说的表，现在3m/12 = 300.000每个新表为每种语言？以此计算，有意义吗？我猜，相同的工作量将必须从现在开始做，但，然后在每个表上的工作时间，而不是一个大表“串行”方式...也许如果有timelap每个表的更新之间的几分钟会更好吗？您可以使用缓存清除 - 现在有专门为这种情况下作出的其他战略。
此外，在vBET 3.3.0缓存是改变 - 有单独的表中为每一种语言，所以索引将缩小52倍和删除将会更快。
我们无法告诉它足够快的速度将您的论坛使用正常删除 - 这取决于表中，你将有多少行。 MySQL的数据将被删除时重建索引。这是花时间的原因 - vBET只能为您提供其他的方法来删除数据（和它提供了这种策略）。其余的是在MySQL的手中。
请只检查，如果仍然将有问题，那么它意味着MySQL将无法处理删除你在正常的方式缓存翻译的1 / 15。在这种情况下，只检查等策略。
如果有必要，我们可以考虑添加额外的策略 - 不重建索引快速删除。现在2个策略是使用快速删除和重建索引后， - 这当然是最耗时的一部分。我们可以添加策略，将不重建索引快速删除 - 这将您的索引增长，因此重建会不时必要的，但您将能够做手工，为您的服务器的最佳时间（一定的养护时间）。
有没有别的办法，我们可以做的（这意味着我们没有看到其他的解决方案现在
此外，我相信installig新的模块时，将删除目前的大表，并从头开始重建新表在安装过程中，对吗？ （试图解体成在安装过程中的大表，未免太服务器密集）
最后编辑者 krisp; 13-01-10 在 23:22.
在这一刻，你的计算是正确的的。但要记住，现在你已禁用清除，让你有更多的数据，通常你会与结算上。
你对那些timelaps有好点的 - 这是个好主意 - 我添加TODO列表，但不能保证，我们将包括在3.3.0，它是星期日举行。如果没有，我们将包括在下一版本后
另外，我不认为这将是重建一个大的指数和12之行相同数量的同时。它取决于复杂的算法（如果它是线性的，这将是相同的）。例如，它是非常容易进行排序清单12，有2比1列表中有24行的行... ...诚实当然 - 我不知道什么是准确的MySQL在这种情况下的算法，但因为你已经注意到最小的表为我们提供了机会，单独用什么将整个服务器更好timelaps更小的任务
是 - vBET会自动删除旧的缓存表，在更新过程中。
回覆时引用
