Suggest a new feature, an enhancement, a bug, ask a question...

Create folders in the SQL Connect Project

I've been using SQL Compare and Data compare for years, and was planning to use the new SQL Server 2012/VS2010 Data Tools instead. But those MS tools are far from the quality of Red-Gate.

I've installed SQL Connect and I like the core concept. BUT I have hundreds of stored procedures which I have categorised in folders in a VS 2010 Database project. Great for better overview and control for my developers. Doing the same in SQL Connect is as I understand not possible. Is this something you consider as new functionality in SQL Connect? For now this is actually stopping me from buying the product for me and 4 other developers.

6 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Per SchjetnePer Schjetne shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    7 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Jason SeeleyJason Seeley commented  ·   ·  Flag as inappropriate

        I am in this same boat and was going to post this suggestion. This one feature is all that keeps me from migrating my SSDT project to SQL Connect (and purchasing the developer or toolbelt packages). We only have a small team (3 developers) and will probably only add one more this year, so I don't know how much of an impact that is in prioritization, but we have a huge database with literally thousands of stored procedures. Being able to organize those into categorical folders and then sub-folders in VS is VERY important to us. Being able to organize tables into categorical folders is secondary and not that important as we only have a couple hundred tables. I'm fine with this organization being on the VS side only. Note: converting an SSDT database project to SQL Connect retained my folder structure in the dbo schema, but I can't create new folders. Just being able to do that would be sufficient.

      • Per SchjetnePer Schjetne commented  ·   ·  Flag as inappropriate

        For us, the most important thing is to break down all our stored procedures, views etc into groups of object. It could be schema based, but that will change the whole way of programming for us as we don't use schemas today. So supporting both schema and a custom made folder structure would be good. And I think it's important for you to provide some of the same functionality as Microsoft has. Not being able to create folders might be a show-stopper for potential customers.
        Based on your first reply, we made a decision to spend quite a lot of money and migrate from Microsoft to Red Gate. So I do hope you stick to your roadmap of making folders available in the project :-).

      • David AtkinsonAdminDavid Atkinson (Admin, Red Gate) commented  ·   ·  Flag as inappropriate

        Yes, we're thinking about supporting different ways of representing the objects. By object type and by schema/object type are obvious candidates. Is it important that this is represented in how the files are saved to disk, or is it more important that the project tree shows the objects in your preferred logical hierarchy?

      • philcartphilcart commented  ·   ·  Flag as inappropriate

        Rather than creating arbitrary folders, would be better to be able to organise database objects into folders for schemas. Just needs a little bit of extra thought upfront when creating the items, but in the end makes things much easier to find. VS 2010 Database project has and option to script things by type or schema and type.
        EG: I'm working on a legacy database that has 1100+ procedures. Most of the procedures have some sort of prefix dbo.Admin_xxx, dbo.Reporting_yyy, dbo.Form_zzz, Would make a lot more sense if the prefix was the schema and the scripts were stored by schema.

      • Per SchjetnePer Schjetne commented  ·   ·  Flag as inappropriate

        Thanks for your reply David. We have now implemented SQL Connect in our development team. We will post some wishes here for future enhancements in the product as well.

      • David AtkinsonAdminDavid Atkinson (Admin, Red Gate) commented  ·   ·  Flag as inappropriate

        The limitation is there because SQL Connect is designed to be used in conjunction with SQL Source Control, which currently enforces a fixed structure. This hasn't been a problem as this structure is hidden from SSMS users. However, it's clearly exposed in VS and it makes sense for us to lift the restriction. However we won't be able to do this until we've done some core engine work, so please bear with us for the time being. It's definitely on our roadmap so please reassure your four developers to this effect, and hopefully they'll be able to live with it in the meantime?

      Feedback and Knowledge Base