Board index » delphi » Re: Suggestoins for Local DB to use with Shareware

2006-05-01 05:52:40 AM
delphi114
"Wayne Niddery [TeamB]" <XXXX@XXXXX.COM>writes
have to make aren't any more difficult than those found in moving between
say, Sybase or SQL Server and Oracle (where dates also have to be handled
differently). In fact, I have found more problems moving between Sybase and
Oracle than between MS Access and either of the other two.
My question about Access would be based on the poster's comments about the
number of insert transactions and the amount of data being stored. I think
Access does much better with high traffic databases now than several years
ago but it still isn't a heavy duty RDBMS like Oracle, Sybase or SQL Server.
Ray
 

I.P. Nichols writes:
But
SELECT * FROM Orders WHERE OrderDate='11/16/1994'
is compatible with every *other* SQL system I know of (any that follow even
just the basics of SQL89/SQL92 standards).
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The purpose of morality is to teach you, not to suffer and die, but to
enjoy yourself and live." - Ayn Rand
 

"Wayne Niddery writes:
portability.
of ?
Oh, let me guess... ;-)
 

"Wayne Niddery [TeamB]" <XXXX@XXXXX.COM>writes
me when I switched from Sybase to Oracle. In Oracle, you have to use the
TO_DATE function to tell Oracle that the string you're supplying is a date
and you have to tell it which date format you're using. In Oracle, the
statement would be:
SELECT * FROM Orders WHERE OrderDate = TO_DATE('11/16/1994', 'mm/dd/yyyy');
This quirk along with the lack of a currency data type drove me crazy when I
first started with Oracle.
Ray Porter
 

I seem to recall that Access has serious issues when any table
approaches 500,000 records. Data corruption and other problems, IIRC.
I.P. Nichols writes:

"Graham" writes:
max size of 2 GB. You can confirm specifications at this URL:
office.microsoft.com/en-us/assistance/HP051868081033.aspx
With that said, storing and manipulating 500,000 or more records, assuming
the data has some value, isn't the sort of thing one does lightly in any
desktop database without due consideration for robustness. However I have
had good success with an Access database that contained some 200,000+
records and I was well pleased with the speed of queries and never
experienced any data loss or corruption.
Over the years I have heard many stories of problems with Access...

you mentioned, the whole database is stored in a single file (which has
obvious benefits) and the MS Access program itself is a very conventient
schema designer, data explorer, query builder tool.
The only things I don't like about using an access databases are:
1. The jet database engine is a total memory hog. Run a few queries and you
will see it chew up 20-30mb of memory on a fairly small database.
2. Access is open format so to speak because of it is driver ubiquity which
means you can not really hide data from users. I guess this can be bad or good
depending on the application. For some projects I have wanted to hide data
from users so they do not mess with it using an external app - something
that can not be done effectively if using access.
 

large numbers of records in a transaction. Perhaps that is the same error
you encountered (although I am pretty sure it only happened on updates and
not inserts).
I found the only way to avoid the error (besides the registry hack to
increase lock counts) was to avoid doing large updates in a transaction or
to open the database in exclusive mode.
 

"Jacob" writes:
use by embedding the password in the Delphi app. By no means the world's
best security but it does keep casually nosey people from being able to mess
with the data.
 

"Ralf Mimoun" writes:
function, which I referred to in my response to Wayne's comment, but didn't
explain why I preferred to use it. It respects the Country Format Settings
of Windows so that in the USA one would use
OrderDate=DataValue('11/16/1994') and in Germany
OrderDate=DateValue('16.11.1994') so that the WHERE clause in the above
SELECT will find the desired records.
 

Wayne Niddery [TeamB] writes:
<< But
SELECT * FROM Orders WHERE OrderDate='11/16/1994'
is compatible with every *other* SQL system I know of (any that follow even
just the basics of SQL89/SQL92 standards).>>
The standard datetime literals are clear and unambiguous:
DATE'1994-11-16'
TIME'00:00:00'
TIMESTAMP'1994-11-16 00:00:00'
Ole Willy Tuv
 

Ingvar Anderberg writes:
fb engine files on disk, but in memory stream ;-)
In that case, complete engine is in memory, and only DB file is on disk
;-)
--
Best regards,
Fikret Hasovic fikret.fbtalk.net
USAID TAMP Senior Programmer
* Firebird Foundation member. - Join today at
www.firebirdsql.org/ff/foundation
* Firebird and Fyracle news www.fyracle.org
* JEDI VCS contributor jedivcs.sourceforge.net/
Posted with XanaNews 1.18.1.3
 

"Ralf Mimoun" <XXXX@XXXXX.COM>writes
least not for anything other than maybe a quick mock-up or prototype.
-Trevor
 

Well the SQL standard is actually quite clear on this with the DATE keyword
and the ANSI value.
--
Hannes Danzl [NexusDB Developer]
Newsgroup archive at www.tamaracka.com/search.htm
 

with the right method for the task. Both, SQL and direct cursor access both
have their advantages and disadvantages.
--
Hannes Danzl [NexusDB Developer]
Newsgroup archive at www.tamaracka.com/search.htm