RecordSet的多线程和操作 [英] Multithreading and manipulation of RecordSet

查看:75
本文介绍了RecordSet的多线程和操作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发我的第一个SQL Server数据库应用程序(适用于30个以上的用户),并且真的可以使用一些建议由于该应用程序的设计非常复杂,因此请耐心等待.   我的应用最终将显示 出于各种目的(打开文件,修改文件的元数据等)总是(希望)保持最新状态文件列表(以及一些相关的元数据).  用户每天要处理(打开文件,修改元数据等)数十个文件(如果不是几百个文件),因此开发一款应用程序使其变得超级快速和便捷,将在一年的时间里真正节省公司在我们环境中的时间

I'm developing my first SQL Server database app (for 30+ users) and could REALLY use some advice particularly because the app’s design is pretty complex so please bear with the long explanation.  My app eventually will display an always (hopefully) up to date list of files (and some related metadata) for a variety of purposes (open file, modify file’s metadata, etc).  The users deal with (open files, modify metadata, etc) dozens if not hundreds of files everyday so developing an app that making it all super quick and easy would really save company time in our environment over the course of a year.

列表总是很大,因此我目前的计划是永远不要关闭应用程序运行. 该应用将具有用于更新列表(修改后的数据,新文件和已删除文件)的方案(TBD). 大约需要加载所有数据需要45-60秒,如果我允许用​​户关闭应用程序,则该数据将使我的应用程序无法使用.

The list is always enormous so my plan at the moment is to never close the app once it’s running.  The app will have schemes (TBD) for updating the list (modified data, new files & deleted files).  It takes approx. 45-60 seconds to load all the data which would make my app unusable if I were to allow the user to close the app.

设计变得复杂,因为列表是两个共享文件夹结构的合并 一些相对文件夹结构和文件.  主列表来自文档管理系统(DMS),辅助列表来自特定的本地文件夹结构(例如C驱动器).   与许多DMS一样,用户无法直接在该系统中修改文档. 相反,用户签出文档(即保留所有权并获得本地副本),使用文件的本机软件(编辑器)进行修改,然后将文档签回到DMS中(即上传新版本,然后放弃所有权).  我的DMS由安装程序配置为将本地文件夹映射(关联)到DMS中的根文件夹,从而在两个结构之间建立关系,因此DMS客户端知道将文件下载到哪里,比较DMS版本反对这 本地版本的文件以向DMS客户端应用程序中的用户显示信息(例如,描述DMS文件的图标比本地更新). 从DMS下载文件时,其 相对文件夹结构(来自DMS的根文件夹)在映射的本地根目录下本地复制,然后复制文件. 要消除在两次列出本质上相同的文件(同一文件位于不同位置-DMS与本地)之间的混淆,即用户想要哪些文件?  我的应用程序中将包含一些逻辑,以确定要删除的重复项(DMS还是本地),以及是否要删除 列表中的剩余恰好是DMS文件(即比本地副本更新),例如,如果用户希望使用文件的本机应用程序打开文件然后我的应用程序知道先下载文件 请先从DMS本地访问该文件,然后再使用与文件扩展名相关的应用程序将其打开. 

The design gets complicated because the list is a merging of two folder structures that share some relative folder structures and files.  The main list comes from a document management system (DMS) and the secondary list comes from a specific local folder structure (e.g. C drive).  As with many DMSs, the user cannot modify documents directly in that system.  Instead the user checks the document out (i.e. retains owership and gets a local copy), makes modifications with the file's native sofware (editor) then checks the document back in to the DMS (i.e. uploading a new version and gives up ownership).  My DMS is configured by the installer to map (relate) a local folder to the root folder in the DMS thereby creating a relationship between the two structures so the DMS client knows where to download the files to, compare the DMS version against the local version of a file to display info (e.g. an icon depicting the DMS file is newer than the local) to the user in the DMS client app, etc.  When a file is downloaded from DMS, its relative folder structure (from the root folder in DMS) is replicated locally beneath mapped local root then the file is copied.  To eliminate confusion in listing essentially the same file twice (the same file in different locations - DMS vs. local), i.e. which files does the user want?  I will have some logic in my app to determine which duplicate to remove (DMS or local) and if the duplicate that remains in the list happens to be a DMS file (i.e. newer than the local copy) then if for instance the user wants to open the file with the file's native application then my app knows to first download the file from the DMS locally before opening it with the app associated to the file extension. 

总体而言,该想法是拥有一个始终最新的列表,该列表可以找到所需的文件通过数据过滤控件或用户将注意力集中在DataGridView上,可以非常快速地 控件然后在所需文件名的开头键入前几个字符,以将列表滚动到该文件. 该应用提供了一些当前可以在文件上执行的命令(打开等),我确定还会添加更多命令. 

The idea in general is to have an always up to date list that can locate the desired file(s) extremely quickly either by data filtering controls or if the user places focus on the DataGridView control then types the first few characters at the beginning of the desired file name to scroll the list to that file.  The app offers a few commands currently to execute on the file (open, etc) and more will added I’m sure. 

我需要的是有关使列表保持最新状态的想法. ; 昨天,我已经阅读了MSDN上"Visual Basic .NET中的多线程"的所有相关线程,这似乎正是我所需要的(即后台处理). 多线程似乎是一个非常复杂的主题,我的应用程序也是如此,因此我认为多线程需要以一种非常特定的方式进行设置(此外,我也已经看到了一些基于多线程文档的知识点) ) 所以我 确实可以使用一些指针. 

What I need from you is ideas on keeping the list up to date.  I’ve read all the related threads to "Multithreading in Visual Basic .NET" on MSDN yesterday which seems to be exactly what I need (i.e. background processing).  Multithreading appears to be a pretty complex subject and my app is as well so I’m figuring that the Multithreading needs to be set up in a very specific manner (plus I also can already see some gotchas based on the Multithreading documentation) so I could really use some pointers. 

推荐答案

Mike,如果从数据库加载数据需要45-60秒,这已经是一个问题.我首先建议仅在软件的特定时刻获取用户所需的信息.例如,如果文件"你指的是 存储在数据库中,您需要所有文件的名称,然后仅在数据库中查询文件的名称(也许还有一些元数据),仅此而已.当用户选择文件并在应用程序中打开文件时,查询数据库 再次针对该特定文件.用户打开该文件的那一刻应该是最新的.不必自己下载所有文件.如果花费45至60秒下载所有数据,那么您显然不希望拥有 持续不断地下载和更新这些文件.这将极大地减慢您的服务器以及本地计算机的速度.如果您追求的是速度,那么再次重申,仅在必要时以最小的数量将数据传输到服务器或从服务器传输数据. 就足够了.如果您 绝对需要 一个不断更新的应用程序,并且绝对没有解决办法,那么可以考虑给数据库中的文件一个唯一标识符,然后 比较标识符,仅更新不匹配的文件.同样,我不建议这样做,但是应该可以.至于多线程,.Net使其非常简单.只是谷歌它,有很多的例子,将帮助您实现它. 快速搜索后,我发现了几个网站.例如:

Mike, if it takes 45-60 seconds to load data from the database, this is already an issue. I would first suggest to only grab the information that is necessary to the user at that particular moment in the software. For example, if the "files" you refer to are stored in the database and you need the names of all of the files, then query the database only for the names of the files (and maybe a little more metadata) but that is all. When the user selects a file and opens it within the application, query the database again for that particular file. It should be up to date to the moment the user opens that file. It isn't necessary to actually download all of the files themselves. If it takes 45-60 seconds to download all of the data, then you obviously don't want to have to continuously download and update those files constantly. It would slow down your servers immensely as well as your local computer. If it's speed you're after, then again, only transfer data to/from the server when necessary and in the smallest amount which will be sufficient. If you absolutely need a constantly updating application and there is absolutely no way around this, then maybe consider giving the files in the database a unique identifier, then compare the identifiers, and only update the files that don't match. Again, I would not recommend this, but it should work. As for multithreading, .Net makes it pretty simple. Just google it and there are plenty of examples which will help you implement it. After a quick search, I found several websites. For example:

http://www.codeproject.com/Articles/4358/Introduction-to-making-multithreaded-VB-NET-Apps

http://www.codeproject.com/Articles/4358/Introduction-to-making-multithreaded-VB-NET-Apps

希望这对您有所帮助!


这篇关于RecordSet的多线程和操作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆