How can we help you today? How can we help you today?
Tilman
Hi Emmanuel, Please see these threads http://www.red-gate.com/MessageBoard/vi ... ight=grant http://www.red-gate.com/MessageBoard/vi ... ight=grant Regards, Tilman / comments
Hi Emmanuel, Please see these threadshttp://www.red-gate.com/MessageBoard/vi ... ight=granthttp://www.red-gate.com/MessageBoard/vi ... ight=grant Regards, Tilman
0 votes
Hi, Thanks for posting. I'm afraid I couldn't reproduce your problem. Any chance you could give me a more detailed example? Cheers, Tilman / comments
Hi, Thanks for posting. I'm afraid I couldn't reproduce your problem. Any chance you could give me a more detailed example? Cheers, Tilman
0 votes
Hi Mike, The snippets are saved here %USERPROFILE%\Local Settings\Application Data\Red Gate\SQL Prompt 3\SQL Prompt 3 Snippets.xml Let us know if you find anything. There is at least one other person who seems to have the same problem. Regards, Tilman / comments
Hi Mike, The snippets are saved here %USERPROFILE%\Local Settings\Application Data\Red Gate\SQL Prompt 3\SQL Prompt 3 Snippets.xml Let us know if you find anything. There is at least one other pers...
0 votes
Hi Travis, Thanks for the feedback. This is a known issue which fell by the way due to time constraints. We are planning to address this in a future version. Regards, Tilman / comments
Hi Travis, Thanks for the feedback. This is a known issue which fell by the way due to time constraints. We are planning to address this in a future version. Regards, Tilman
0 votes
Hi, I'd like to see the joins go BOTH ways if possible. I actually prefer doing <table I'm joining to>.col = <table I'm joining from>.col. A small semantic difference, but just the way I like to write my SQL. This has already been suggested, and it's on our list, but I don't think it will make it into v3. Now, a version that doesn't work... did you know that the ON clause can go in one of two places? SELECT * FROM [HumanResources].[EmployeeAddress] ea JOIN [HumanResources].[Employee] e JOIN [HumanResources].[EmployeeDepartmentHistory] edh ON e.[EmployeeID] = edh.[EmployeeID] ON --*** Hit space before the *** comment and you'll get a column list rather than JOIN candidates. The ONs here are nested in the same order as the JOINs, so you should get a list of candidates for the JOIN between "e" and "ea". (Note, I absolutely *hate* this syntax, but I see it from time to time so I suppose it should be supported) I actually didn't know this. Thanks for pointing it out. I've added an issue to our system. Now, another weird thing... What if I accidentally leave the ON below the JOINs? SELECT * FROM [HumanResources].[EmployeeAddress] ea JOIN [HumanResources].[Employee] e ON --*** JOIN [HumanResources].[EmployeeDepartmentHistory] edh ON e.[EmployeeID] = edh.[EmployeeID] ON Again, hit space before the *** comment and it's broken... Until I do something like: SELECT * FROM [HumanResources].[EmployeeAddress] ea JOIN [HumanResources].[Employee] e ON --*** JOIN [HumanResources].[EmployeeDepartmentHistory] edh ON e.[EmployeeID] = edh.[EmployeeID] ON x This is kind of expected behaviour. Our parser doesn't work very well with invalid SQL (which is kind of ironic, i know, but hey...), so as a rule of thumb, the more valid the SQL the better Prompt will work. Regards, Tilman / comments
Hi, I'd like to see the joins go BOTH ways if possible. I actually prefer doing <table I'm joining to>.col = <table I'm joining from>.col. A small semantic difference, but just the way I like to w...
0 votes
Hi, I'm afraid this is by design. We do not detect at the moment when the schema changes. Regards, Tilman / comments
Hi, I'm afraid this is by design. We do not detect at the moment when the schema changes. Regards, Tilman
0 votes