Hi guys
Had a thought about this
I woder if there is a syntax for this
TsqlObject = class (TsqlPersistentObject)
private
MainEntTable: TsqlTable
DetailEntTable: TsqlTable relatedby MainEntTable.PK = DetailEntTable.FK
public
attribute: string read MainEntTable.Column
published
I think taking this appoach (updating thru strored procs) is a 'poor mans'
multi-tier
I would either
1/ Put in a middleware layer or
2/ Implement update multiple tables, validity checks et al in triggers
Do you really want to implement a complex middle layer in a script
language?
The
David
Re
I'm also not sold on triggers. Maybe I've just never seen a good
implementation, but in my experience they tend to cause performance
problems
and are vastly more difficult to debug than stored procedures. One of
their
biggest benefits is consistency of updates
True, Triggers are
the day you have 2 stored procs that update a
common set of tables is the day the wheels
have come loose
I really fail to see how you can say that this is always true. We write
distinct functions and procedures to do distinct tasks - whether in a client
application, 'nth tier', or stored
Paul
The fact that
they operate on the same tables is not in itself an indication that the
"wheels have fallen off" - IMHO of course.
You'll note that I said 'loose' not 'fall off'! Essentially you are
embedding data integrity logic in
two places - which opens the door to inconsistency.
It
Essentially you are embedding data integrity logic in
two places - which opens the door to inconsistency.
I am talking about using SPs at a higher level than just updating records.
A non-normalised database 'opens the door to inconsistency' but people still
design them that way, and make money
Paul
It is clear I am looking at this from a different perspective to you, and
as
such these generalisations aren't going to achieve much. I'll therefore
leave you to it.
Fun tho aint it :-)
Neven
---
New
It is really applying OO paradigms to SQL Servers - Just consider
Tables as collections of Objects, Row Clumns as properties, and then
triggers as event driven methods.
And stored procedures as normal standard methods. I agree.
Exactly. The arguments for using stored procedures (or
Paul
And stored procedures as normal standard methods. I agree.
Updating via stored procs (without triggers) is then
analagous to writing delphi progs only using RTTI
I withdraw the RTTI Comment - I was being too flippant
The analogy of SP as methods is quite valid if you abstract out a
MAIL PROTECTED]
Sent: Saturday, November 25, 2000 1:34 PM
Subject: Re: [DUG]: embedded database.
Gary, great, exactly what I ws after!
Matt.
- Original Message -
From: "Gary T. Benner" [EMAIL PROTECTED]
To: "Multiple recipients of list delphi" [EMAIL PROTECTED]
Se
This is and interesting point - how do other access methods SQL DBMS
handle
surrogate key generation - ie how do they relocate the record
they have just
inserted
Very easily - they all fail. You have to write special code to get the
generated primary key value back from the server.
November 2000 11:29
Subject: RE: [DUG]: embedded database.
This is and interesting point - how do other access methods SQL DBMS
handle
surrogate key generation - ie how do they relocate the record
they have just
inserted
Very easily - they all fail. You have to write special code
Myles
If ADO Supports this (if only for MS SQL and Access) is this
part of the ADO Provider Spec (ie could other OLE DB
Providers support this)
Yes, no reason why not - but don't know if the OLE-DB spec has anything
about this.
The problem really only occurs when attempt to a
It's a right pain to have to handle this as a special case
(using SP's etc to solve).
Maybe this points towards the real problem, that SPs are perceived to be a
pain? We use Visual Studio to edit and debug stored procedures on a SQL
Server 7 database and it is very simple, with code
It's a right pain to have to handle this as a special case
(using SP's etc to solve).
Maybe this points towards the real problem, that SPs are perceived to be a
pain? We use Visual Studio to edit and debug stored procedures on a SQL
Server 7 database and it is very simple, with code
Unfortunately it doesn't work so well if you want to go
to the next logical step and have all of your data
selection via stored procs - it's not really possible to
write good select stored procs which handle multiple
possible filter parameters.
I have had no trouble in this area, but
Unfortunately it doesn't work so well if you want to go
to the next logical step and have all of your data
selection via stored procs - it's not really possible to
write good select stored procs which handle multiple
possible filter parameters.
I have had no trouble in this area, but
[Moved to DUG-DB]
Try writing that in a single fast SQL statement!
Are you able to build up the SQL string only for the items that have been
defined and EXECUTE(@statement) that?
Another method that's simplified the code and debugging for me is to use a
temp table created with SELECT *
Re
This approach seems to becoming increasingly common and is one which we
are
also taking. It works very well for updates and allows you to do very nice
things (such as update stored procs which update multiple tables, create
an
audit trail, check the validity of the change, not to mention
Gidday, I remember someone talking about embedded database engines (or maybe
a couple of dlls you distribute with your app), as apposed to having to
deploy the bde.
Does anyone know what these ones are and have links to them?
Cheers,
Matt.
[Reply]
At 11:28 on 25/11/2000 Malcolm wrote
To :
CC :
From: Matthew Comb, [EMAIL PROTECTED]
Gidday, I remember someone talking about embedded database engines (or maybe
a couple of dlls you distribute with your app), as apposed to having to
deploy the bde.
Does anyone know what these ones
Gary, great, exactly what I ws after!
Matt.
- Original Message -
From: "Gary T. Benner" [EMAIL PROTECTED]
To: "Multiple recipients of list delphi" [EMAIL PROTECTED]
Sent: Saturday, November 25, 2000 10:42 AM
Subject: RE: [DUG]: embedded database.
[Reply]
At 11:28 o
On 25 Nov 2000, at 11:34, Matthew Comb wrote:
Gidday, I remember someone talking about embedded database engines (or maybe
a couple of dlls you distribute with your app), as apposed to having to
deploy the bde.
I use Flash Filer from turbopower , your project can be complied as a single exe
iple recipients of list delphi" [EMAIL PROTECTED]
Sent: Saturday, November 25, 2000 12:02 PM
Subject: Re: [DUG]: embedded database.
On 25 Nov 2000, at 11:34, Matthew Comb wrote:
Gidday, I remember someone talking about embedded database engines (or
maybe
a couple of dlls you dist
controls work with it?
Cheers,
Matt.
- Original Message -
From: "Ian Fear" [EMAIL PROTECTED]
To: "Multiple recipients of list delphi" [EMAIL PROTECTED]
Sent: Saturday, November 25, 2000 12:02 PM
Subject: Re: [DUG]: embedded database.
On 25 Nov 2000, at 11:34
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Matthew Comb
Sent: Saturday, 25 November 2000 12:34
To: Multiple recipients of list delphi
Subject: [DUG]: embedded database.
Gidday, I remember someone talking about embedded database
engines
At 05:23 pm 25/11/00 +1300, Mark Derricutt said:
Take a look at http://www.elevatesoft.com/
What do they charge for it? And how much does it increase your exe by?
Blurb says ..
Compiles directly into your .EXE with no external .DLLs or configuration
files needed
Has a very small footprint,
On 25 Nov 2000, at 14:00, Matthew Comb wrote:
Yes it completely compies into the Exe in single user mode, comes with its own
components
for database sesseion and Ttable which mimic's the starndard delphi stuff
Havent at this stage fount any controls that dont work with it, appears to work fine
28 matches
Mail list logo
