@MathieuGuindon Going over examples for Assert.SequenceEquals got me thinking. For when boundaries aren't identical theres an Error 9 Subscript out of range message. A bit less user friendly than the boundary message or dimension message.
Also saw if both boundaries don't match it only shows the lower bound as being different.
Nice touch on having it state which dimension its on. :+2: for that alone.
> introduces Rubberduck.Resources project, begins to split up RubberduckUI.resx into namespaces, replaces relative paths with pack URI's in xaml markup.
@WaynePhillipsEA There are no options related to VBA/Security as far as I am concerned. I have tried to add the iFix project to Trusted Locations in Office, but that's not working either. own is supported [RubberduckLog.txt](https://github.com/rubberduck-vba/Rubberduck/files/1994846/RubberduckLog.txt)
``` 2018-05-07 20:32:32.7893;WARN-2.2.6698.27995;Rubberduck.Inspections.Rubberduck.Inspections.Inspector+<FindIssuesAsync>d__7;System.ArgumentException: Element o tym samym kluczu został już dodany. w System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) w System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) w Rubberduck.Inspections.Concrete.OnErrorStatementListener.ExitModuleBodyElement(ModuleBodyEl
> The problem here is that the listener populates two dictionaries with additional information to be passed to the inspection results. These do not get cleared in `ClearContexts`. Consequently, a rerun of the inspection will fail on adding a context the second time.
To be honest, I have not been able to determine the actual use of the two dictionaries. The first one actually does not save any information one could not get from the context via an existing extension method.
The Lie-to-Children paradigm is pervasive in education. In elementary school you learn that the sky is blue. In high school you learn that the sky appears blue because the atmosphere is blue. At university, you learn that the atmosphere filters out non-blue light to a greater extent than blue light. In grad school, you are led to wonder what the defintion of "blue" was anyway, the historical context of defining the sky as blue, and what the likely social, economic, and political ramifications of a non-blue sky would be. During your PhD, you claim that the sky is mauve and defend your model. — Robert Columbia15 hours ago
@LightnessRacesinOrbit: Java programs are never frictionless, but in their natural state with mass approaching infinity, they do approach becoming perfectly spherical. — R..2 days ago
@DainIronfootIII Is teaching a simplified (and thus more understandable) model equivalent to lying, though? (But I did actually enjoy that quote nonetheless.) :)
Glad you don't. :) (I think it would make for a horrible education always teaching the most advanced/detailed/known-to-be-most-accurate model first. No chance for a kid to gradually learn complex correlations...)
> If there's something strange in you neighborhood Who you gonna call? (resourcebusters) If there's something weird And it don't look good Who you gonna call? (resourcebusters) I ain't afraid of no resource I ain't afraid of no resource If you're seeing things running through your head Who you gonna call? (resourcebusters) An invisible man Sleeping in your bed Who you gonna call? (resourcebusters) I ain't afraid of no resource I ain't afraid of no resource Who you gonna call? (resourcebusters) If you're all alone
one dumb way would be to script a script from production db then try to run it on dev.
By default script includes USE <database> at the top of the script
and even if you've changed the SSMS dropdown to connect to the dev db, running that script trumps that and you end up making changes to the prod db
For that reason, I change the SSMS options to not include the USE <databse> when scripting and always manually check the database dropdown before I hit F5.
and under Programmability, I'd probably stick to just Stored Procedures for now and not worry about other subfolders until you're totally comfortable with the 3 core objects (table/view/sprocs).
^^ Note that there are several caveats that comes with using functions, especially scalar functions. You need to reorient yourself into thinking in a set-based manner, rather than iterative manner so it's best to avoid the scalar functions. Table-valued function is likely a better next step after the sprocs, IMO.
> I am getting the Rubberduck Opportunity described in the title of the issue. I've tried several things to solve it, but haven't been able so far. Things I've noticed/tried:
1. It's only present for the second to fifth test modules. The first one doesn't have this "opportunity". 2. Fixing it (adding the '@Ignore IllegalAnnotation) doesn't make it go away either, as can be seen on the screenshot. 3. Removing the tag breaks the execution of the test cases in the test module.
> If you replace the '@Ignore IllegalAnnotation line with a NEWLINE (i.e. leaving a blank line between the declarations section and the Sub statement, does the inspection result go away?
> Although it isn't very clear in the screenshot, there is a line between the declarations section and the sub statement already. Anyway, I just removed the '@Ignore IllegalAnnotation with a blank line, but this didn't make the result go away. I added more white space before the sub statement, but that didn't fix it either.
> Ah, sorry I missed it. In any case this is worrying - it seems to imply that the test engine isn't going to recognize the ModuleInitialize method. If you put a breakpoint and run the tests, is the breakpoint hit?
> But I must clear something up: all tests are running ok (even with the opportunity present). If I remove the annotation, then they break. But as shown on the screenshot above, I am being able to run all my test just fine. It's just my OCD acting up that makes me want to get rid of those "opportunities" :)
@IvenBach a better analogy woudl be working with a text editor like Word -- BEGIN TRANSACTION disables the autosaving. If you don't disable the autosave, you end up saving what you didn't want to save
imagine you have a table with bank accounts and balances. you need to withdraw from one account and credit another
you can't withdraw from one account without crediting the other, and you can't credit the destination account without the withdrawal on the source account
it's a case of "all these operations must happen as an atomic unit, or not at all"
it would be super bad for the bank if a debit happened without a credit or credit without debit. Even if the bank didn't get sued, they'd likely go out of business because money is fast going out.
^ that's why I referred to the analogy of autosaving -- you need to pretend that by default, any changes you make in your database are automatically saved immediately and are done so at the statement level.
Meaning, if you had two UPDATE statements in your SQL script, and 2nd one failed, you're stuck with the effects of the first UPDATE statement and in database world you totally don't want that.
In Word, it's nice to have your document autosaved because you're editing it all the time. In database, there is no "editing state", in a manner of speaking. And you definitely don't want your "drafts" going into the database.
and then your stress level goes up because you're working against the production DB, and shit hits the fan when you run your "this will fix it" update statement.... without a where clause
^ been there, done that, bought the shirt and gnashed the teeth.
so that's why when applying the changes to the production, you really really want a script that'll do it all atomically so that you can easily bail out when something goes wrong.
@MathieuGuindon In a hand wavey oversimplification its saying pending with "I want this stuff to be done" and if something comes up as a failure you tell it "All the pending stuff, don't actually try to perform it".
yes. internally SQL Server maintains a transaction log, that can actually fill up and go over-capacity if you run a transaction with too many operations.
I also hit the log capacity maximimum once on a test server. I was deleting a lot of test outputs (via a stored procedure that did not partition its work properly). The output to delete turned out to be larger than 2TB.
That's a good reason to never use the default of allowing your log files to grow infinitely. Giving it a large enough size and setting up a proper backup schedule avoids the dreaded issue where your log file has turned into the blob and took up the entire drive and you can't make a backup without any data loss.
Well, 2TB is the largest size you can set a log file to in SQL Server. The transaction roll back log increased until it hit the capacity limit. Then the database tryed to roll back the transaction; fun.
> SQL Server provides commands that are not Transact-SQL statements, but are recognized by the sqlcmd and osql utilities and SQL Server Management Studio Code Editor. These commands can be used to facilitate the readability and execution of batches and scripts.
batch is whatever is the center of a Go sandwhich?
Go
--However many statements in between
--All of this is considered a single batch
Go
Right, when you consider that some statements like CREATE PROCEDURE or CREATE VIEW (for example) must be the only statement in a batch, GO let you include those with other statements but behind the scene, SSMS will basically sepearate in each GO and execute each.
Yes.
one thing to watch out for --- GO; or GO --blah won't work as intended.
@IvenBach script 10K inserts one after the other, without a GO anywhere: you'll get an error involving "batch size" or something. now sprinkle GO every 1500 inserts or so, and the script runs fine.
Do be extra careful when doing DDL & DML in a single script. Not all errors are fatal and SQL Server has this stupid behavior where it will keep on executing the rest of script even after encountering an error which can wreak everything, and transaction won't help you. That's why you want the SQLCMD with :ON ERROR EXIT to ensure it aborts on the first error.
The INTO keyword is marked [ INTO ] and therefore optional. Is it a best practice to include it to avoid ambiguity/implicit stuff being done? Is it taboo to not include it.
so you can insert into dbo.Table1 (col1, col2) select 42, 'abc' when Table1 exists. or you can select col1=42, col2='abc' into dbo.Table1 to createTable1.
the INSERT syntax basically combines all possible ways to do things, so pretty much everything is optional, and none of it really is - only depends what you want to do
I'd prefer to avoid omitting the options. I don't like reading INSERT i(x,y,z) SELECT f.a x, f.b y f.c z FROM foo f; - I"d rather read INSERT INTO dbo.i(x, y, z) SELECT f.a AS x, f.b AS y, f.c AS z FROM dbo.foo AS f;.
Might I get a bit of help with starting an Insert? I'm trying to change a fields type to money from nvarchar(255) but get a warning about `"Saving changes is not permitted.".
I would like to copy the rows but am drowning in documentation.
I mean, your money column might be 6-15 digits, including the dot and decimals. you're inserting it into a nvarchar(200), what's the risk of omitting the length?
VBA Rubberducking
VBA Rubberducking