DDL script, SQL Editor, doesn't save connection info

Posts   
 
    
timbered
User
Posts: 80
Joined: 09-Feb-2020
# Posted on: 11-Jan-2025 02:29:46   

Designer 5.11.4 Hotfix, Model First with Firebird

When I change my model, code-generate a DDL SQL Update Script, and select Open in SQL Editor Tabs, there's an option to Execute the script - which is fantastic! Except, I have to Edit..., re-enter my connection info, ID and password every time.

Is there a way I can save this info?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39797
Joined: 17-Aug-2003
# Posted on: 11-Jan-2025 09:15:53   

It should remember within the session but not across sessions, as we don't persist connection info for an adhoc sql session (and we never persist passwords, also not for projects for instance). It didn't remember it within a session? (With session I mean, you keep the tab open)

Frans Bouma | Lead developer LLBLGen Pro
timbered
User
Posts: 80
Joined: 09-Feb-2020
# Posted on: 11-Jan-2025 21:40:35   

Every time I run the Create or Update, it creates a new script, and opens in a new tab. So yes, I have to enter the info for every new tab.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39797
Joined: 17-Aug-2003
# Posted on: 13-Jan-2025 09:11:54   

timbered wrote:

Every time I run the Create or Update, it creates a new script, and opens in a new tab. So yes, I have to enter the info for every new tab.

I understand. The current design is that a SQL tab contains the connection information (as you can connect to whatever servers in different tabs) and that's not something that's shared among tabs. This is a limitation with the current design. We'll see if we can make this easier in a future version

Frans Bouma | Lead developer LLBLGen Pro
timbered
User
Posts: 80
Joined: 09-Feb-2020
# Posted on: 13-Jan-2025 10:27:36   

Ok, thanks.

I'm kinda surprised at the things I've encountered over the past couple of weeks, in that I seem to be the only person working with Firebird in the past ten years working model first, five years using derived entities, and don't know how long in asking for this.

I feel like a beta tester in some regards. Or maybe just a pioneer... 🤔😁

Thanks again for your help.

R

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39797
Joined: 17-Aug-2003
# Posted on: 13-Jan-2025 12:15:42   

timbered wrote:

Ok, thanks.

I'm kinda surprised at the things I've encountered over the past couple of weeks, in that I seem to be the only person working with Firebird in the past ten years working model first, five years using derived entities, and don't know how long in asking for this.

I feel like a beta tester in some regards. Or maybe just a pioneer... 🤔😁

Our apologies for the issues and I'm sorry you feel that way. Firebird isn't a well used database on .net, tho there are some users of Firebird, but most work database first I think. The issue described in this thread is a limitation of the system we designed. It re-uses the SQL editor which is re-using the same connection data with every query. It won't be hard to change that tho, but alas, sometimes things have a more limited scope than perhaps anticipated...

The earlier firebird issues were indeed cases which shouldn't have happened. We have had firebird support since 2003 I think, when Carlos was still writing the ADO.NET provider, but this slipped through. I hope we've fixed all issues now smile (and if not, please let us know so we can fix them)

Frans Bouma | Lead developer LLBLGen Pro
timbered
User
Posts: 80
Joined: 09-Feb-2020
# Posted on: 13-Jan-2025 13:18:07   

As a software developer, I know things happen, believe me. You can't test everything and things come up, especially in something as complex as LlblGen.

And don't get me wrong, I think LlblGen is a great product with fantastic support. Considering the hours and days of work it has saved me over the past few years, I'm not about to give it up.

You've addressed (and solved) all my issues as soon as one is found. That's what counts. I'm still a very satisfied customer.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39797
Joined: 17-Aug-2003
# Posted on: 13-Jan-2025 14:44:48   

Thanks! simple_smile

Frans Bouma | Lead developer LLBLGen Pro
timbered
User
Posts: 80
Joined: 09-Feb-2020
# Posted on: 19-Jan-2025 17:33:19   

I thought of a workaround for this (not saving the connection info): If you added a "Copy All" option to the context menu in the tab's text area, that would save me a couple mouse clicks to get the script to my own script editor for execution.

Or maybe even a dedicated button somewhere to accomplish the same?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39797
Joined: 17-Aug-2003
# Posted on: 20-Jan-2025 08:33:44   

In the next version, 5.12 (which will release in a month or so, maybe a little later), we've implemented caching in SQL Tabs of the connection info per database type. So that basically re-uses the connection info of one tab in the next (you can of course edit it again, it simply pre-fills it) if the database type is the same. I think that's the closest to what you wanted simple_smile

Frans Bouma | Lead developer LLBLGen Pro
timbered
User
Posts: 80
Joined: 09-Feb-2020
# Posted on: 20-Jan-2025 12:04:13   

Wow, thanks! That's great news. Like I said above, your support is fantastic, and another reason I'm happy to give you my money. 👍