#>On 10 Jul 2009, at 9:31pm, Rick Ratchford wrote: #> #>> After examining the above, it appears that what this does is modify #>> the table itself. So I suppose then that it is not possible #>to create #>> a recordset instead that meets what I'm trying to do. If #>this is the #>> case, I'll have to make a copy of this table first as I #>don't want to #>> modify the original. #> #> #>I don't understand why people keep trying to do these things #>inside SQL when they're obviously ysing a programming #>language anyway. If the solution was entirely without a #>programming language there would be some point to it, but #>since you have your programming language, why not take #>advantage of it ? Keeping the previous value of a field in a #>variable does not take lots of programming ! #> #>Read the existing records from taxTable in date order. #>Compare the value of 'tax' in this record with the one you #>remember from the previous record. No need to write a new #>table. No need to write the directions to disk at all, since #>you apparently only need them for output. #> #>Simon.
I understand what you're saying Simon. But I will say this, that the program I'm currently working on is a "rewrite-update". In other words, it's a completed application that uses no DB at all. I'm currently updating it and adding features, and it came to my attention that SQLite could make my life easier for much of what it does now and want it to do. My application used arrays and arrays of structures extensively to do what I'm now having SQLite/SQL do. And I'll tell you this, it is so much cleaner and less code extensive to use SQLite when you're able to just send a SQL query with instructions on what you want rather than indexing multiple dimension arrays in layered loops. The type of work my application does absolutely loves SQLite (database) approach. The reason I even started using it is that I wanted to reference data in a certain way that would require elaborate array indexing. Sure it can be done in code. Everything can be done in my programming language. But from my experience of writing the original program and now changing many procedures over to DB (SQLite) and SQL, it's been a real joy. Of course, this has been a steep learning curve for me as I just started this about 4 weeks ago. Before then, I've never looked at DB, SQLite or any other DB or SQL type situation. Olaf mentioned his DB wrapper for VB6 and off I went. As mentioned in a previous message, I could simply take all the data from the table and plug it into an array. I could easily run it through a loop, do the comparison, store the data in the array (of struc) itself, and then do whatever I want with it. However, IF there was a way to just ask the DB to do it for me, using a single SQL statement, isn't that a whole lot easier and better? The data is there already anyway, right? And for each procedure where I made the change from arrays to DB, I've timed it and actually increased the speed of the procedure. One went from 14 seconds (zzz) down to under 2 seconds after the DB rewrite. If I hadn't already written this application before, using arrays and such, then I'd not know the advantage of one over the other. But these last few weeks, I've experienced an approach to dealing with price data that feels more organized, cleaner, less coding, less looping, and more often than not returns to me exactly what I'd be searching for in looping arrays, using one SQL statement, and one simple line like Set RS = OpenRecordset(SQLString). It just doesn't get easier than that! For my applications where I am dealing with stock price data, having to do lots of searches, comparisons and the like, I'm going to use SQLite. The only thing that slows me down is my inexperience in thinking like a DB programmer. PS: My application never writes to a disk, and the DB is in-memory. Thanks. Rick _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
