Menu
▾
▴
firebird-net-provider
|
From: JS.staff <jsp...@ec...> - 2004-03-12 10:06:13
|
That would be useful to me too - specially with the timestamp issue potentially causing problems with the concurrency checking for a 'all field' check. John -----Original Message----- From: Dmitry Azaraev [mailto:fd...@do...]=20 Sent: 12 March 2004 09:28 To: fir...@li... Subject: [Firebird-net-provider] FbCommandBuilder - where's clause rule to generate control needed![Scanned] Hello, All! I'm needed what FbCommandBuilder can generate queries with where clause, for example, only for primary key fields. Some time needed for generate for specified fields... I suggest add to FbCommandBuilder property (what be visible in design-mode), via which i can control this behaivor (rule to generate where clause (all fields/PrimaryKeyOnly) :-) 2Carlos: I can programm this. ;) ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Firebird-net-provider mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-net-provider |
|
From: JS.staff <jsp...@ec...> - 2004-03-12 13:22:38
|
Why is 3 'Pessimistic'?? Surely it has less concurrency checking, so = should be called something like ReallyOptimistic??? Or = GodIHopeNoOneElseHasChangedThis.... ;) John -----Original Message----- From: Carlos Guzm=E1n =C1lvarez [mailto:car...@te...]=20 Sent: 12 March 2004 12:02 To: fir...@li... Subject: Re: [Firebird-net-provider] FbCommandBuilder - where's clause = rule to generate control needed![Scanned] Hello: > Yes, for this we can made third mode: what in where generate=20 > primary key and "TIMESTAMP" field for example... > I'm need in this may be too... anyway I this wants the breach of=20 > the parallelism for governing checking! Well at the end seems to be that there are more people with similar need = ;) I'm thinking on make a change to the 1.6 sources: * Create a new enumeration: FbBuilderBehavior ( really it's needs to be=20 FbCommandBuilderBehavior but it's too long ;) ) it will have as values: 1. Default 2. Optimistic 3. Pesimistic 1/2. Will do update and delete command generation as it's now. 3. Will do the update and delete command generation using only the pk=20 fields in the WHERE clausule. Opinions ??? -- Best regards Carlos Guzm=E1n =C1lvarez Vigo-Spain ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of = GenToo technologies. Learn everything from fundamentals to system = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Firebird-net-provider mailing list = Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-net-provider |
|
From: Dmitry A. <fd...@do...> - 2004-03-12 10:20:36
|
"JS.staff" wrote: > That would be useful to me too - specially with the timestamp issue > potentially causing problems with the concurrency checking for a 'all > field' check. Yes, for this we can made third mode: what in where generate primary key and "TIMESTAMP" field for example... I'm need in this may be too... anyway I this wants the breach of the parallelism for governing checking! |
|
From:
<car...@te...> - 2004-03-12 12:14:44
|
Hello: > Yes, for this we can made third mode: what in where generate primary > key and "TIMESTAMP" field for example... > I'm need in this may be too... anyway I this wants the breach of the > parallelism for governing checking! Well at the end seems to be that there are more people with similar need ;) I'm thinking on make a change to the 1.6 sources: * Create a new enumeration: FbBuilderBehavior ( really it's needs to be FbCommandBuilderBehavior but it's too long ;) ) it will have as values: 1. Default 2. Optimistic 3. Pesimistic 1/2. Will do update and delete command generation as it's now. 3. Will do the update and delete command generation using only the pk fields in the WHERE clausule. Opinions ??? -- Best regards Carlos Guzmán Álvarez Vigo-Spain |
|
From: Dmitry A. <fd...@do...> - 2004-03-12 12:52:06
|
Carlos Guzmán Álvarez wrote: > I'm thinking on make a change to the 1.6 sources: > * Create a new enumeration: FbBuilderBehavior ( really it's needs to > be FbCommandBuilderBehavior but it's too long ;) ) My first thought was such :) Truth shortened name I as well as not ïðèäóìàë, but FbBuilderBehavior I like! ;) > it will have as values: > 1. Default > 2. Optimistic > 3. Pesimistic All it is correct, but names "Optimistic/Pesimistic" I do not like, since this does not render on principle optimistic/pesimistic parallelism, either or both of them -- there is ways to realization optimistic parallelism, but with renovation strategy miscellaneous. Not certain, but can offer... mmm... Default, AllFields, PrimaryKeyFields but me such names too do not like :) So unless will be other offers -- consent to variant with Optimistic/Pessimistic names :) > Opinions ??? The fourth variant -- WHERE is generated on primary key fields and field with fixed-name (for example "TIMESTAMP" or "LAST_MODIFIED"). |
|
From:
<car...@te...> - 2004-03-12 13:20:05
|
Hello: > All it is correct, but names "Optimistic/Pesimistic" I do not like, > since this does not render on principle optimistic/pesimistic > parallelism, either or both of them -- there is ways to realization > optimistic parallelism, but with renovation strategy miscellaneous. > Not certain, but can offer... mmm... Default, AllFields, > PrimaryKeyFields but me such names too do not like :) So unless will be > other offers -- consent to variant with Optimistic/Pessimistic names :) Defult AllFields KeyFields KeyAndTimeStampFields As a reference Visual Foxpro allows: 1. Key Fields only 2. Key and updatable fields. 3. Key and modified fields 4. Key and timestamp ( That if i'm not worng works only for Sql Sever ) > The fourth variant -- WHERE is generated on primary key fields > and field with fixed-name (for example "TIMESTAMP" or > "LAST_MODIFIED"). As i don't like fixed things ;) if i do this i will add a property for this ( aand provide a default value for it, of course ) Opinions ???? -- Best regards Carlos Guzmán Álvarez Vigo-Spain |
|
From: Dmitry A. <fd...@do...> - 2004-03-12 13:35:59
|
Carlos Guzmán Álvarez wrote: > Default > AllFields > KeyFields > KeyAndTimeStampFields Yes :-) > 4. Key and timestamp ( That if i'm not worng works only for Sql Sever) Not wrong, but some-time peoples can use this method and in Firebird too... for example if on timestamp field creates trigger... in this case it's will work as AllFields, with that difference that request will have a more good plan for execution. :) > > The fourth variant -- WHERE is generated on primary key fields > > > and > field with fixed-name (for example "TIMESTAMP" or > > "LAST_MODIFIED"). > As i don't like fixed things ;) if i do this i will add a property > for this ( aand provide a default value for it, of course ) I'm don't like fixed things too... but TIMESTAMP fields can be more than 1, and may be selects this uniquely impossible. My opinion -- add a property, that have dafault value (empty?) -- auto search TIMESTAMP field?! ;-) Opinions ???? |
|
From:
<car...@te...> - 2004-03-12 13:55:47
|
Hello: >>4. Key and timestamp ( That if i'm not worng works only for Sql Sever) > > Not wrong, but some-time peoples can use this method and in Firebird > too... for example if on timestamp field creates trigger... I do that, checking a field in a before update trigger ;) > I'm don't like fixed things too... but TIMESTAMP fields can be more > than 1, Don't see why use more than one for this ¿?¿? ;) -- Best regards Carlos Gyuzmán Álvarez Vigo-Spain |
|
From: Dmitry A. <fd...@ua...> - 2004-03-12 14:13:22
|
Hello Carlos,
Friday, March 12, 2004, 3:44:53 PM, you wrote:
>>>4. Key and timestamp ( That if i'm not worng works only for Sql Sever)
>> Not wrong, but some-time peoples can use this method and in Firebird
>> too... for example if on timestamp field creates trigger...
CGÁ> I do that, checking a field in a before update trigger ;)
Logistical :) But way "Key and timestamp" shall leave :-) :-)
>> I'm don't like fixed things too... but TIMESTAMP fields can be more
>> than 1,
CGÁ> Don't see why use more than one for this ¿?¿? ;)
create table t1(
t1 timestamp,
t2 timestamp,
t3 timestamp
);
??? :-)
why not? :)
the sense itself do not see (but review beside who what
problems) :) in principle if field will be chosen -- fine. if
will first/last in table -- too live very possible... :-)
--
Best regards,
Dmitry mailto:fd...@ua...
|
|
From:
<car...@te...> - 2004-03-12 14:56:10
|
Hello: > create table t1( > t1 timestamp, > t2 timestamp, > t3 timestamp > ); > ??? :-) > why not? :) Huummm but you mean to use 3 three fields for concurrency control ?? -- Best regards Carlos Guzmán Álvarez Vigo-Spain |
|
From: Dmitry A. <fd...@ua...> - 2004-03-12 15:10:11
|
Hello Carlos,
Friday, March 12, 2004, 4:45:09 PM, you wrote:
>> create table t1(
>> t1 timestamp,
>> t2 timestamp,
>> t3 timestamp
>> );
>> ??? :-)
>> why not? :)
CGÁ> Huummm but you mean to use 3 three fields for concurrency control ??
no, this gipoteticheski. for instance person have 2 importances
with stamp of time happened event :-) and one for concurrency...
:-)
--
Best regards,
Dmitry mailto:fd...@ua...
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X