Re: Best modality for rather large stacks
Kurt Kaufman wrote: I know there was a discussion on this topic about a year ago, when I inquired about the necessity of using a formal database extension to Rev vs. a text file vs. multiple substacks. I ended up going with the substacks as in doing so multiple users could concurrently access different records, and the data of the individual records (in this case) did not need to be combined in any way. Would it have been possible to allow multiuser access had I used a single text file instead of multiple substacks? Possible but difficult. Sufficiently difficult that I'd say it wouldn't be worth it. If you have multiple simultaneous users including one (or some) doing updates, then use a database. (or multiple substacks, but personally I'd just go the whole hog and use a database). -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 16/12/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Best modality for rather large stacks
Alex Tweedly wrote: [...] sqlite sounds like a good option - but I'm not sure it is needed. For 5000 records of 50 fields, that's not a scale of problem that *requires* any database. There may be other aspects of your problem that cause you to need a database (complex searches or sorting, maybe), but for many purposes, the simple text file with CR + TAB delimiters should be adequate. [...] I know there was a discussion on this topic about a year ago, when I inquired about the necessity of using a formal database extension to Rev vs. a text file vs. multiple substacks. I ended up going with the substacks as in doing so multiple users could concurrently access different records, and the data of the individual records (in this case) did not need to be combined in any way. Would it have been possible to allow multiuser access had I used a single text file instead of multiple substacks? At this point the question is academic, as the system I have in place is working fine. Thanks, Kurt ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best modality for rather large stacks
Gordon Tillman wrote: On Dec 16, 2005, at 13:18, [EMAIL PROTECTED] wrote: Can anyone advise on the best mode? At the moment I am inclined to create a one-card stack that links to a text file. In the text file, one line of text would contain all of the data for one card. So to "go" to card 533 the computer would simply read line 533 of the text file, parse it, and set up the data onto the fields. This method seems really good as searches are very fast using "lineoffset", and if things get fouled up I can simply open the text file in any word-processor and fix it. I also like the fact that I don't have to continually save the stack -- in my script the text file would be continually updated as fields are changed, cards created/deleted. I would recommend that you use the altSQLite external from http:// www.altuit.com/webs/hemingway/AltuitCover/default.htm. This external is a wrapper around the excellent SQLite database engine. You can read more about SQLite here: http://sqlite.org/ Works very well, is extremely fast, and can handle even much larger databases that what you are needing. Plus it is less expensive than than the Valentina route. The database file is also fully cross- platform. sqlite sounds like a good option - but I'm not sure it is needed. For 5000 records of 50 fields, that's not a scale of problem that *requires* any database. There may be other aspects of your problem that cause you to need a database (complex searches or sorting, maybe), but for many purposes, the simple text file with CR + TAB delimiters should be adequate. I have a couple of such projects - the larger one is 8-9,000 records of 40 fields per record - around 1.4 Mb total data. Straightforward searches - e.g. filtering to display only those records that match a couple of values or even regexes in specific fields - are, to all intents and purposes, instantaneous. I don't do much in the way of inter-record combinations, though I do some (it's a pedigree database, and I do things like multi-generation pedigrees and offspring reports). This is done with a simple text file for storage, with a the data held in a Transcript variable. You should be careful about how / when you save changes (I do so only on user command, and keep N generations of backups, where N is user-selectable) - but my database is close to read-only - changes are infrequent and usually arrive in a large batch. My advice is to not leap into using a more complex solution until you've proven a need for it. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/204 - Release Date: 15/12/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Best modality for rather large stacks
> Fred, SQlLite is *extremely slow*. Like bicycle comparing to rocket. > > Do not believe just me! That's the only valid point you make. Not to believe you. I use SQLite with altSQL and it is fast, efficient and very clean. I combine this with Trevor's libDatabase. If you are in a competition to win friends and influence people then you have lost the plot, mate. Attacking other products to promote your own is marketing suicide. People don't like it, no matter the value (or lack of) of your product. Given that the people from Altuit are always helping out here for free I find your comments offensive in the extreme. Yes- I'm a newbie to Rev. But I've been programming (professionally) for over twenty years and I can assure you I've met twits like you before. I suggest you refine your marketing strategy or risk continuing looking like a goat. Scott Kane ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best modality for rather large stacks
Ruslan.. Once again you find it necessary to attack someone else's product to promote your own. I, for one, find this pretty distasteful and I can't imagine it's making you very popular in this community. You say there are testimonials of developers that have used both on your site. I went there and searched for SQLite and the only mention is in the one you included in your email. And that guy's not even using Rev. He's using Valentina with Cocoa and/or RealBASIC. You are not helping yourself here, sir. On 12/16/05, Ruslan Zasukhin <[EMAIL PROTECTED]> wrote: > > On 12/16/05 9:26 PM, "Gordon Tillman" <[EMAIL PROTECTED]> wrote: > > Fred, SQlLite is *extremely slow*. Like bicycle comparing to rocket. > > Do not believe just me! > > read testimonials of developers that have use both and can compare. > http://paradigmasoft.com/en/testimonials > > > -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, "Revolution: Software at the Speed of Thought" >From http://www.shafermediastore.com/tech_main.html ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Best modality for rather large stacks
> Works very well, is extremely fast, and can handle even much > larger databases that what you are needing. Plus it is less > expensive than than the Valentina route. The database file > is also fully cross- platform. Don't know if it was lost in Ruslan's response on SQLite but, if you upgrade Studio or higher now you'll get VXCMD for free. Best regards, Lynn Fredricks President Paradigma Software, Inc Joining Worlds of Information Deploy True Client-Server Database Solutions Royalty Free with Valentina Developer Network http://www.paradigmasoft.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best modality for rather large stacks
On 12/16/05 9:26 PM, "Gordon Tillman" <[EMAIL PROTECTED]> wrote: > I would recommend that you use the altSQLite external from http:// > www.altuit.com/webs/hemingway/AltuitCover/default.htm. > > This external is a wrapper around the excellent SQLite database > engine. You can read more about SQLite here: > > http://sqlite.org/ > > Works very well, is extremely fast, Fred, SQlLite is *extremely slow*. Like bicycle comparing to rocket. Do not believe just me! read testimonials of developers that have use both and can compare. http://paradigmasoft.com/en/testimonials Pay attention to Justin's quote about SqlLite and Valentina. - Justin Drury on Valentina for Cocoa and REALbasic I¹ve been using Valentina since 2000 first with Realbasic and now with Cocoa. What has always struck me as impressive is not just the database engine but the dedication and excitement the folks at Paradigma have for their product. I had moved to Apple¹s Cocoa framework about a year ago and had to use alternate databases(SqLite/MySQL) while Valentina 2 was prepared. Recently I have been able to start integrating V4CC(Valentina for Cocoa) into my apps, and frankly its THE most exciting addition to my development environment! I can use Valentina¹s RAM databases with the same ease as CoreFoundation¹s datatypes with all the speed and efficiency that we have come to respect out of Valentina. With its objective C interface and built-in binding support, Valentina for Cocoa (with xCode) is an incredible RAD tool. I had been using CoreData with both its XML store and Sql Lite store and while that was fine for a few thousand records it quickly started to bog down and I missed the ability to tinker under the hood. Within an hour I had whipped together a prototype using Valentina and was awed by its power. I¹m again able to access hundreds of thousands of records with lightning speed and with its mature SQL support I¹m able to manipulate the data with ease. --- > and can handle even much larger databases that what you are needing. Plus it > is less expensive than than the Valentina route. The database file is also > fully cross- platform. If somebody care about price, then please be aware that right now Runtime Revolution offer you Valentina 1.x for FREE. -- Best regards, Ruslan Zasukhin VP Engineering and New Technology Paradigma Software, Inc Valentina - Joining Worlds of Information http://www.paradigmasoft.com [I feel the need: the need for speed] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best modality for rather large stacks
Howdy Fred, On Dec 16, 2005, at 13:18, [EMAIL PROTECTED] wrote: Hi: I have to port a bunch of Hypercard Stacks over to Revolution. A typical stack contains 5000 cards with one background and about 50 fields. While these are not huge stacks, they are big enough where if I simply port them as they are to Revolution, searches will be glacially slow. I need to be able to search quickly and see different views of the material. For example, one of the stacks is my address stack. Most of the time I just need to find a person's name; at other times, I need to see a list of everyone with a certain zip code, or a list of those who responded to a mailing, etc. Can anyone advise on the best mode? At the moment I am inclined to create a one-card stack that links to a text file. In the text file, one line of text would contain all of the data for one card. So to "go" to card 533 the computer would simply read line 533 of the text file, parse it, and set up the data onto the fields. This method seems really good as searches are very fast using "lineoffset", and if things get fouled up I can simply open the text file in any word-processor and fix it. I also like the fact that I don't have to continually save the stack -- in my script the text file would be continually updated as fields are changed, cards created/deleted. I would recommend that you use the altSQLite external from http:// www.altuit.com/webs/hemingway/AltuitCover/default.htm. This external is a wrapper around the excellent SQLite database engine. You can read more about SQLite here: http://sqlite.org/ Works very well, is extremely fast, and can handle even much larger databases that what you are needing. Plus it is less expensive than than the Valentina route. The database file is also fully cross- platform. Regards, Gordon Tillman ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Best modality for rather large stacks
Hi: I have to port a bunch of Hypercard Stacks over to Revolution. A typical stack contains 5000 cards with one background and about 50 fields. While these are not huge stacks, they are big enough where if I simply port them as they are to Revolution, searches will be glacially slow. I need to be able to search quickly and see different views of the material. For example, one of the stacks is my address stack. Most of the time I just need to find a person's name; at other times, I need to see a list of everyone with a certain zip code, or a list of those who responded to a mailing, etc. Can anyone advise on the best mode? At the moment I am inclined to create a one-card stack that links to a text file. In the text file, one line of text would contain all of the data for one card. So to "go" to card 533 the computer would simply read line 533 of the text file, parse it, and set up the data onto the fields. This method seems really good as searches are very fast using "lineoffset", and if things get fouled up I can simply open the text file in any word-processor and fix it. I also like the fact that I don't have to continually save the stack -- in my script the text file would be continually updated as fields are changed, cards created/deleted. Before I invest the time in the above method, can anyone tell me if I am taking the right approach? For example, what about using arrays, or Valentina? I don't know anything about them. I'm not asking for detailed instructions, just a hint at what is the best approach. Thanks for your suggestions. Fred Moyer ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
