From: Russell R <Ru...@pa...> - 2010-03-03 10:34:09
|
Hi there I am lookng at ways to store my database within Subversion and to be able to search for differences between versions. I tried extracting the whole of the DDL using FlameRobin, but as I have computed fields, when I run the SQL in an empty database I get an error. So I extract the data with isql. However, when I do this, all the procedures and triggers come out all on one line. Is there any way round this. Here is some sample output: ALTER PROCEDURE TEST1 AS DECLARE VARIABLE t1 int; declare variable t2 int; declare variable t3 int; BEGIN t1 = 10; t2 = 5; t3 = t1 * t2; END ^ where within FlameRobin it comes out as: ALTER PROCEDURE TEST1 AS DECLARE VARIABLE t1 int; declare variable t2 int; declare variable t3 int; BEGIN t1 = 10; t2 = 5; t3 = t1 * t2; END^ -- View this message in context: http://old.nabble.com/Changing-procedures-and-extracting-metadata-tp27766504p27766504.html Sent from the flamerobin-devel mailing list archive at Nabble.com. |
From: Russell R <Ru...@pa...> - 2010-03-03 12:13:20
|
I have worked out that the reason for this is because there are two carriage returns per line. With a HexEditor when I replaced 0D0D with 0D everything displayed okay. Is this a buglet within FlameRobin? ... or is there a workaround without having to parse things through a Hex Editor -- View this message in context: http://old.nabble.com/Changing-procedures-and-extracting-metadata-tp27766504p27767421.html Sent from the flamerobin-devel mailing list archive at Nabble.com. |
From: Michael H. <mg...@gm...> - 2010-03-04 21:15:09
|
Hi Russell, On 03.03.2010 11:34 Russell R wrote: > So I extract the data with isql. does that mean the following is a problem with isql, or is it a problem with FlameRobin? > However, when I do this, all the procedures and triggers come out all on one > line. > > Is there any way round this. > > Here is some sample output: > ALTER PROCEDURE TEST1 AS > DECLARE VARIABLE t1 int; declare variable t2 int; declare variable t3 int; > BEGIN > t1 = 10; t2 = 5; t3 = t1 * t2; > END ^ > > where within FlameRobin it comes out as: > ALTER PROCEDURE TEST1 > AS > DECLARE VARIABLE t1 int; > declare variable t2 int; > declare variable t3 int; > BEGIN > t1 = 10; > t2 = 5; > t3 = t1 * t2; > END^ Could you please clarify what it is you're asking? Is it something that FlameRobin does wrong, in your opinion? Or is it something that you'd wish isql would do the way FlameRobin does it? Anyway, for us to discuss this at all here you would need to provide some more data, like information about what FB and FR versions and platforms you use, what you see, and what you'd expect to see instead. Or what you think is wrong behaviour on FlameRobin's part. And if it's in fact a FR bug, then a description of a simple way to reproduce it would increase the chances of the bug getting fixed. Thanks -- Michael Hieke |
From: Russell R <Ru...@pa...> - 2010-03-05 07:38:33
|
I believe the issue is with FlameRobin and I think there are two issues. First, I am using Firebird v2.1, FlameRobin v0.9.2.1851 and running on a Windows Workstation running XP SP3. Issue 1 If I extract all the DDL via FlameRobin and then try to run it into a new database I get an error caused by the calculated fields. If I extract the data via isql, this doesn't happen. For me this is a minor issue as I can use isql Issue 2 There is more work to demonstrate this. I performed the following actions: create a new database (DB1) with a very simple table extract the whole DDL using isql add a new procedure to the script using a text editor (wordpad) create another new database (DB2) using this modified script and confirmed the procedure was there extract the data from DB2 and confirmed the new script was okay modified the procedure using FlameRobin within DB2 extract the data again from DB2 this time the script had the main body of the procedure on a single line Using a hex editor, I determined there were extra 0D's (carriage returns). When I did a global replace of 0D0D with 0D within the script, the procedure displayed correctly -- View this message in context: http://old.nabble.com/Changing-procedures-and-extracting-metadata-tp27766504p27790768.html Sent from the flamerobin-devel mailing list archive at Nabble.com. |
From: Michael H. <mg...@gm...> - 2010-03-05 08:07:08
|
On 05.03.2010 08:38, Russell R wrote: > Issue 1 > If I extract all the DDL via FlameRobin and then try to run it into a > new database I get an error caused by the calculated fields. If I > extract the data via isql, this doesn't happen. For me this is a > minor issue as I can use isql This is certainly an issue with FlameRobin, which should be fixed. There is already #2815486 in the tracker, maybe it's the same cause. > extract the data from DB2 and confirmed the new script was okay > modified the procedure using FlameRobin within DB2 > extract the data again from DB2 > this time the script had the main body of the procedure on a single > line Thanks for the explanation, I will try to have a look at this ASAP. Thanks -- Michael Hieke |
From: Michael H. <mg...@gm...> - 2010-03-05 08:34:23
|
I get the opposite behaviour. Using both FR and local Firebird on my Windows machine I get all the trigger and procedure code with correct line endings (carriage return + line feed), and all the other FR generated statements with wrong line endings (linefeed only) for that platform. I already added tracker item #2801132 for another issue where line endings handling is inconsistent within FR. How the resulting sql file looks depends on the editor. On notepad it's basically unusable. On a smarter editor it generally looks OK, but there are stray rectangles on procedure and trigger code lines. Line endings in procedure and trigger code retrieved from the database metadata could of course be filtered to contain platform native line endings, but IMHO this is only part of the necessary work, which is to make FR always use the correct line endings, everywhere. Which isn't a complicated task, but certainly a big one, with the potential to break things on the way. Maybe running unix2dos / dos2unix / recode or something like this on the sql file would make it usable with SVN. Thanks -- Michael Hieke |
From: Milan B. <mil...@gm...> - 2010-03-05 12:30:48
|
On Wed, Mar 3, 2010 at 11:34 AM, Russell R <Ru...@pa...> wrote: > Hi there Hi Russel, I replied to you 2 days ago on this, but my message never went through. Here's the copy: Russell R wrote: > I am lookng at ways to store my database within Subversion and to be able to > search for differences between versions. I tried extracting the whole of > the DDL using FlameRobin, but as I have computed fields, when I run the SQL > in an empty database I get an error. This is a known issue, recursive dependency resolver (that works for views) is not implemented for computed columns. > However, when I do this, all the procedures and triggers come out all on one > line. > > Is there any way round this. Are you using both isql and FR on the same operating system? Instead of bothering with hex editor, you can simply open the file in Geany, Notepad++, SciTE or any other editor that has the option to convert line endings and then just save it. Alternatively, you can use FR's find&replace functionality with "convert backslashes" option turned on. In such case, use \r for CR (carriage return, code 13) and \n for LF (line feed, 10). Regards, -- Milan Babuskov http://www.flamerobin.org http://www.guacosoft.com |
From: Russell R <Ru...@pa...> - 2010-03-05 13:17:00
|
I can modify the script using notepad++, but this is proving very difficult as my boss doesn't want to extract the data via isql and then have to modify it as a separate operation. If there was something that allowed me to to do this within a batch file then I could hide the mechanism and so it would be fine. However, I have not been able to find an editor that runs in command-line mode. One thing notepad++ does give me is I can clearly see the extra CR's being placed within the file -- View this message in context: http://old.nabble.com/Changing-procedures-and-extracting-metadata-tp27766504p27793611.html Sent from the flamerobin-devel mailing list archive at Nabble.com. |
From: Russell R <Ru...@pa...> - 2010-03-05 14:55:47
|
How do I set the configuration to save in native format? -- View this message in context: http://old.nabble.com/Changing-procedures-and-extracting-metadata-tp27766504p27794943.html Sent from the flamerobin-devel mailing list archive at Nabble.com. |
From: Michael H. <mg...@gm...> - 2010-03-05 15:12:53
|
On 05.03.2010 15:55, Russell R wrote: > How do I set the configuration to save in native format? You can't, there isn't any configuration setting for it. FlameRobin should really do the right thing on its own, but unfortunately it doesn't. Someone would have to invest the time and fix the source code. Right now things will only work correctly for FlameRobin on systems <> Windows, and without ever changing database metadata from any Windows machine. Thanks -- Michael Hieke |
From: Michael H. <mg...@gm...> - 2010-03-05 14:52:15
|
On 05.03.2010 14:03, Russell R wrote: > I can modify the script using notepad++, but this is proving very difficult > as my boss doesn't want to extract the data via isql and then have to modify > it as a separate operation. If there was something that allowed me to to do > this within a batch file then I could hide the mechanism and so it would be > fine. However, I have not been able to find an editor that runs in > command-line mode. You don't need an editor. Any command line tool to do the \r\n -> \n or the \n -> \r\n conversion will do. For example there is <http://www.thefreecountry.com/tofrodos/> > One thing notepad++ does give me is I can clearly see the extra CR's being > placed within the file There are no extra CR's AFAICS. If you use FlameRobin on Windows there will be missing CR's, and if you load the file with the mixed line endings into an editor that will treat it as a file with Unix line endings, then the CR's will show up as extra. If you load the file with the mixed line endings into notepad it will treat it as having DOS line endings, and most of the text will be one single lines. The key is to get FR to save files in the platform-native format. That means inserting any missing CR's when on Windows, and stripping all CR's on other platforms. Thanks -- Michael Hieke |