我很生氣，因為我花的錢和我的時間上的東西我不能使用。我的決定是根據你的顯示器上vB.org。這不是說你所提供的3.8是不是太棒了，因為我認為它是。作者： vBET
你告訴我說，在那裡你寫了（初期表現在vB.org），它的不兼容******!!與 VB4。然後我會道歉並關閉行動。
馬特 Olieman
無標題文檔
自動翻譯 （谷歌、 微軟 ®， 網站 Yandex、SDL Language雲端、IBM Watson及協會）：
我很生氣，因為我花的錢和我的時間上的東西我不能使用。我的決定是根據你的顯示器上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
在vBET 4.0將被釋放，可以使用vBET 2.4 - 西港島線是你的網頁已編制索引，並釋放後，您將擁有更好的性能作了更新，給您的用戶可能編寫職位，不同的語言。
最後編輯者 vBET; 12-01-10 在 03:03.
只是為了確保：
目前我暫時禁用緩存清除，因為我的服務器幾乎下井時更新緩存在“正常刪除”。因此，更新後的MOD在幾天內，我可以將其設置為“正常刪除”，一切都會順利運行？
你可以使用緩存清除現在 - 有其他戰略方面專門為這種情況。
另外，在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策略使用快速刪除和重建索引之後 - 這當然是最耗時的一部分。我們可以將策略調整，將作出快速刪除沒有索引重建 - 這將增加了你的指標，因此重建將需要不時，但你可以做手工的最佳時間為您的服務器（一些保存時間）。
有沒有別的辦法，我們可以做的（這意味著我們沒有看到其他的解決方案，現在
此外，我相信新的MOD時 installig它必須刪除目前的大表，重建新表從頭開始安裝過程中，對不對？ （試圖分裂成更小的大表在安裝過程中會過於密集的服務器）
最後編輯者 krisp; 13-01-10 在 23:22.
你的計算是正確的這一刻。但請記住，現在你已禁用結算，所以你必須有更多的數據，通常你將與清算有關。
你有好點的有關這些 timelaps - 這是個好主意 - 我加了它在TODO列表，但不能保證我們將它列入3.3.0它是定於週日。如果我們不將它列入下一版之後
此外，我不認為這將是同一時間重建一個大指標和12個較小的有相同數量的總和行。它取決於複雜的算法（這將是相同的，如果它是線性的）。例如，它是非常容易的排序名單有2行12比1的列表有24行... ...當然，誠實 - 我不知道什麼是準確的MySQL的算法在這種情況下，但正如你已經注意到有最小的表給了我們機會單獨與 timelaps較小的任務全做什麼更好的服務器
是的 - vBET會自動刪除舊的緩存表中的更新。
回覆時引用
