I've been struggling with an SSIS package for a while now.
Any time I run it in VS, it runs just fine and loads my data as I'd expect. However, when I deploy the code to my SQL Server and run it, it fails, complaining about missing column delimiters.
I'm thinking that maybe there's something wrong with the deployment (even though I've redeployed a few times) and it's Just Borked™.
I guess I'm gonna right-click Delete the package from the server and try again.
No, I don't know why I told y'all this, I guess I just needed to say it out loud.
Dear SSMS.
Why must you crash every time I try to dock the Object Explorer to the left edge of your window?
With love,
A concerned, but increasingly annoyed user
I'm glad I decided to delete the package and redeploy it. In the process, I realized what an id10t I've been...
I finally realized that I could deploy multiple projects within 1 folder in the SSISDB catalog. So, I started modifying my deployments to do that. This will allow me to have just one set of environments, instead of having to create a new Dev and Prod for every package I deploy.
I call a Stored Procedure from my VBA code to launch the package. (You can see where this is heading, right?)
I forgot to update the stored proc to call the package from the new location.
All this time, I've been beating my head on my desk trying to figure out why my fixes worked in VS but not when I call them from VBA and it's because I haven't been calling the fixed code from VBA!!!!!
:( our Azure database finally became available, so I tested this. Now it's telling me that The environment reference '11' is not associated with the project.
Despite the fact that it clearly (to me, at least) is.
Next on my list is #4793. An obscure (documented for C?) binary file format, with a ridiculously outdated editor, and outstanding questions on how to enable for VBA?
Rubberduck VBA permits creation of virtual project hierarchy within the IDE, but the project is imported/exported as a single folder with all files. Sometimes, direct access to the project folder is useful, in which case having materialized project structure on hard drive is helpful. For example,...
@HackSlash Both VBA and VB6 need on-disk hierarchies.
FWIW, I firmly believe that many potential RD features would be most easily introduced though VB6. I know that it's limited to hobbiests right now, but VB is where VBA originated. VBA is VB6 with a more complicated storage mechanism, and no standalone execution.
@HackSlash No, Rubberduck is C#, but it brings modernity to VBA and VB6. I'm just saying that certain features are easier to introduce to a client that already treats source files as, well, files.
VB6 stores its files on disk. VBA stores them in its host document, as it sees fit. More complicated.
I am trying to implement the game 2048 in Excel VBA.
The each TRUE / FALSE Boolean value in row 2, 4, 6 and 8 are used for determining the data of each cell in row 1, 3, 5 and 7 is 0 or not.
The experimental implementation
Sub MergeUp()
Dim loop_num
Dim loop_num2
For loop_num2 = 1 To...