server crashes when creating database on OSX 10.9 Mavericks
---
Key: CORE-4536
URL: http://tracker.firebirdsql.org/browse/CORE-4536
Project: Firebird Core
Issue Type: Bug
Affects Ve
I got errors returns from the email server so I'm re-sending:
Jim, your latest posting does not help the current situation.
It only complicates the discussion unnecessarily.
The immediate problem, and the only one that needs immediate discussion
on this list, is how to re-instate the functionalit
Jim, your latest posting does not help the current situation. It only
complicates the discussion unnecessarily.
The immediate problem, and the only one that needs immediate discussion
on this list, is how to re-instate the functionality in the initial
release of FB3. The problem was identified
OK, my spelling has never been that goode.
But how about session specific field encryption?
Carlos?
On Sunday, August 31, 2014, Tom Coleman wrote:
>
>
> On Aug 31, 2014, at 9:39 AM, James Starkey wrote:
>
> This calls into question whether Firebird exists to serve the interests
> of its users
On Aug 31, 2014, at 9:39 AM, James Starkey wrote:
> This calls into question whether Firebird exists to serve the interests of
> its users or just for the amusement of certain dilantants.
Jim's often prescient comments sent me to the dictionary to look this one up.
Per Webster:
dil·et·tant
DY> What about unencrypted distributed databases? Should we care about
DY> hiding PSQL source also from SYSDBA / DBO? Are there real cases when it
DY> would be needed?
Well, the currently "hack" makes no distinction of users, so if the
idea is to maintain currently behavior, it doesn't matter who
Let's try another tack on this problem. What is the best possible way to
solve it if schedule were not a problem? And is this a special case of a
more general problem?
Here's an idea to get the creative juices working: Suppose the database
parameter block were extended with a composite containi
31.08.2014 15:51, Carlos H. Cantu wrote:
>
> We have a "hack" that many people uses for a long time, to make it
> more difficult to stole procedures/triggers source (more difficult,
> not impossible, since BLR can be decoded to source). They know it is
> not 100% safe, but so far it is the only wa
31.08.2014 22:11, Dimitry Sibiryakov wrote:
> To secure it from examining by users, no?..
This is the last reason for such a move.
Dmitry
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org
>> And it might not be feasible to rewrite PSQL code to UDRs, given
>> time and money constraints.
>
>Hey, PSQL words fine in may ways, is natively integrated - why should we
>even consider of moving the code to anything else?
Exactly, and with a set of (custom) external functions (UDFs), there's
31.08.2014 20:06, Thomas Beckmann wrote:
> why should we
> even consider of moving the code to anything else?
To secure it from examining by users, no?..
--
WBR, SD.
--
Slashdot TV.
Video for Nerds. Stuff that
> And it might not be feasible to rewrite PSQL code to UDRs, given
> time and money constraints.
Hey, PSQL words fine in may ways, is natively integrated - why should we
even consider of moving the code to anything else?
Greetings, Thomas
--
Mit freundlichen Grüßen,
Thomas Beckmann
Diplom-Info
>> UDR is about integration.
>
>> Anyone claiming UDR to be a replacement to PSQL or exposition
>> of code does not understand what UDR is.
>
>There is still a lot of room for moving complex code out of
>PSQL and into external procedures. There are many things for
>which PSQL is not an ideal choic
Adriano dos Santos Fernandes wrote:
> On 31-08-2014 12:06, Geoff Worboys wrote:
>>
>> I'd like to argue that developers have already had years to
>> find a better solution than deleting the source, but really the
>> only better solution is UDR, and developers need significant
>> time to migrate. S
Mark Rotteveel wrote:
> On 31-8-2014 17:06, Geoff Worboys wrote:
>> I still haven't forgiven Firebird for the abrupt change of
>> alias ambiguity rules from v1.5 to v2.0. The particular
>> circumstances of the time meant that this was hugely
>> inconvenient to one of my largest projects. Had some
On 31-8-2014 17:06, Geoff Worboys wrote:
> I still haven't forgiven Firebird for the abrupt change of
> alias ambiguity rules from v1.5 to v2.0. The particular
> circumstances of the time meant that this was hugely
> inconvenient to one of my largest projects. Had some migration
> mechanism been
On 31-08-2014 12:06, Geoff Worboys wrote:
>
> I'd like to argue that developers have already had years to
> find a better solution than deleting the source, but really the
> only better solution is UDR, and developers need significant
> time to migrate. So if you want projects to stay current, y
James Starkey wrote:
> [...]
> Carlos has enumerated a set of acceptable possibilities, none
> of which is overwhelming difficult. I can see no constructive
> reason why his request should not be accomodated other than
> contempt for users.
Despite my objections to the technique (that it could, q
There is no technical requirement to store sources for triggers and
procedures. It is done, presumably, for the convenience of application
developers. Some application developers, of which Carlos is just one, have
demonstrated that storing the sources is sometimes extremely inconvenient,
even det
On 31-8-2014 13:51, Carlos H. Cantu wrote:
> Let's get back to the facts and try to reach a decision:
>
> We have a "hack" that many people uses for a long time, to make it
> more difficult to stole procedures/triggers source (more difficult,
> not impossible, since BLR can be decoded to source). T
31.08.2014 13:51, Carlos H. Cantu wrote:
> As pointed before, databases with procs/triggers with null source can
> be restored in FB 3 without any problem, but you can't erase the
> sources anymore. This looks inconsistent.
>
> Proposals so far:
>
> 1) Create an official way to make the source null
Let's get back to the facts and try to reach a decision:
We have a "hack" that many people uses for a long time, to make it
more difficult to stole procedures/triggers source (more difficult,
not impossible, since BLR can be decoded to source). They know it is
not 100% safe, but so far it is the o
Thomas Beckmann wrote:
> As it has been pointed out, erasing source is a familiar way
> to obfuscate source code, we have been using this from time
> to time ourselves. Moreover, you can restore an FB2-DB
> without sources to a working FB3-DB, but you can not create
> it by FB3 natively - that's i
Unhandled exception at 0x777B03B8 (kernel32.dll) in fsql.exe: 0xC005:
Access violation writing location 0x00030FFC window 7 sp1
---
Key: CORE-4535
24 matches
Mail list logo
