Subject | Re: [ib-support] Re: Case Sensitivity on Indices |
---|---|
Author | Kumar |
Post date | 2003-01-15T12:17:20Z |
Darryl, et al.
First, thanks again for all the kind support and suggestions you all have provided. I've gotten nice responses before from other ng's as a newbie, but not the quantity and quality that I've been given here.
For this particular issue, I think the duplicate data field and casting will work just fine for me (I only have one field in one table that I need this for). I have been able to, I think, identify 95% of the database issues that I will face with this conversion in just two days (with all of you guys/gals support)! And, with FB 1.5's support of the Boolean field, I will make a quantum leap from what I was looking at just a day ago.
I'm just curious about something... and maybe some of you can make some comments... We've deployed an application that uses D5+Asta+DBISAM to about 30 clients... no DB issues except for one client. And this is our largest client (about 45 concurrent users, heavy traffic with selects, updates, etc.) Every once in awhile it seems that their server starts doing the hooky-pooky and freezes up. It usually seems related to someone running a large update (maybe 200 records) or someone running a very large report. But, it occurs so sporadically we have been unable to duplicate the issue. This client has about 0.5 gig of data for a 1 year period (I don't know how much this will translate into FB once converted, but I'm hoping it will be less).
While we are still not 100% certain that the issue with this client is DB or Asta (middleware), we've chosen to do a DB migration to FB not only in hopes of resolving this issue, but also because of: Its' being Royalty free; potential concurrency issues with DBISAM; hopefully some reporting speed improvement; cross-platform potential; and because we expect to have clients with 1,000+ (up to about 100 concurrent threads) users in the near future.
My q. is: Many people keep telling us to just go with MSSQL and have the client pay for its license (which will go over like a fart in church for most of them) or look at MySQL instead of FB. Do you folks see FB as a solid alternative to MSSQL (no, I don't care if it is as fast, just 90% as fast would be fine)? Is MySQL something that I should be looking at... or is it just another flat-file system with the same issues I've already faced.
Thanks,
-k-
[Non-text portions of this message have been removed]
First, thanks again for all the kind support and suggestions you all have provided. I've gotten nice responses before from other ng's as a newbie, but not the quantity and quality that I've been given here.
For this particular issue, I think the duplicate data field and casting will work just fine for me (I only have one field in one table that I need this for). I have been able to, I think, identify 95% of the database issues that I will face with this conversion in just two days (with all of you guys/gals support)! And, with FB 1.5's support of the Boolean field, I will make a quantum leap from what I was looking at just a day ago.
I'm just curious about something... and maybe some of you can make some comments... We've deployed an application that uses D5+Asta+DBISAM to about 30 clients... no DB issues except for one client. And this is our largest client (about 45 concurrent users, heavy traffic with selects, updates, etc.) Every once in awhile it seems that their server starts doing the hooky-pooky and freezes up. It usually seems related to someone running a large update (maybe 200 records) or someone running a very large report. But, it occurs so sporadically we have been unable to duplicate the issue. This client has about 0.5 gig of data for a 1 year period (I don't know how much this will translate into FB once converted, but I'm hoping it will be less).
While we are still not 100% certain that the issue with this client is DB or Asta (middleware), we've chosen to do a DB migration to FB not only in hopes of resolving this issue, but also because of: Its' being Royalty free; potential concurrency issues with DBISAM; hopefully some reporting speed improvement; cross-platform potential; and because we expect to have clients with 1,000+ (up to about 100 concurrent threads) users in the near future.
My q. is: Many people keep telling us to just go with MSSQL and have the client pay for its license (which will go over like a fart in church for most of them) or look at MySQL instead of FB. Do you folks see FB as a solid alternative to MSSQL (no, I don't care if it is as fast, just 90% as fast would be fine)? Is MySQL something that I should be looking at... or is it just another flat-file system with the same issues I've already faced.
Thanks,
-k-
[Non-text portions of this message have been removed]