January 16, 2009 at 7:02 pm
vbguy,
I've been using the same code as in my sample code as my method of operation with Access for at least the last 5 to 6 years, and it works just fine. There's no real need for bound controls, and frankly, if you can show me the solution to what you just asked, I'll change over, assuming that I can control everything. As the linked table already provides the connection to the database, you need not reproduce the connection string in your code, regardless of whether it's the read a record portion OR the update or add portion. I've always populated the controls from the recordset with one statement for each control. It's not so great an effort that this is a big deal. After all, you only might need to have that same basic code appear twice - once as the code that populates controls, and a mirrored-version that populates the database record for either an add or update. Avoiding the unbound controls over something that takes such a small amount of time just seems like much ado about nothing to me.
Steve
(aka smunson)
:):):)
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
January 16, 2009 at 7:06 pm
Oh, I just realized you were concerned about having loaded the entire table into the recordset. If the table is large enough to cause that to be a genuine performance issue, then Access is the wrong tool to be managing that data, and you should be going for .NET instead.
However, if you think about it, loading the entire table isn't absolutely necessary. You can always dynamically create your SQL query that's an INSERT or UPDATE. You could even create a temp table just for inserts or updates, and you stage the record into that table, and then either INSERT INTO / SELECT WHERE from that temp table, using criteria if you need concurrency, to ensure you're only getting your own data from said table. You then delete the temporary record. That might be a lot of overhead, however, and again, if you need that much concurrency that this overhead could be a problem, again, you probably fall into the category of belonging in .NET instead of Access.
Steve
(aka smunson)
:):):)
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
January 17, 2009 at 1:13 pm
Thanks very much for the insight and code sample. Your advice is valuable.
I don't want to use bound controls for writing records. I found out right away that method can cause issues. I prefer the granularity and control over the data I can get using ADO.
I'm into VB.Net and have made a couple small databases with it. It looks to me like it would be a big project transforming this project over to .Net
Where do you draw the line and decide it's time to move to .Net?
January 17, 2009 at 6:52 pm
I wish I could draw that line for you, as I have zero knowledge or experience on the performance of .NET, but I do know when to call it quits with Access, and any DECENT setup with .NET and well-performing queries has GOT to be better than Access, even if the development timeframe is longer. However, if you get to the point of having more than 5 users with an Access mdb file, it's at least time to get to an Access project (.adp), and any time you have 10 or more users or more than 80,000 records or so with multiple users, those are some off-the-cuff estimates on where I typically draw MY line. Hit any of those targets and I won't do anything more than prototype it in Access, if that. Also, I suspect that in any borderline situation, the answer is more likely to be "it depends" rather than some simple "dare you to cross this line" type of thing. Hoep that helps...
Steve
(aka smunson)
:):):)
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
January 17, 2009 at 7:26 pm
smunson,
Your input is great I appreciate it and thanks! Time to draw the line on this thread though.
I saw you had some trouble with IIS/ASP.Net in another thread. I could give a hand if you ever need help there.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply