I have a question for all of you and please any ideas are welcome. We have alot of MSAccess database projects in our repository on which developers work and do there tests in Dev Envoirment on there own. As you all know compiling a databse project is itself a wrong statement, cause you actually need to test your scritps and reports and everything else againt a databse. SO what can we do in TFS build script in case of MSAccess Projects , i am out of ideas. Anybody who has come across this issue and have done something about it, i would really appriciate if you share.
Any example or link which will explain how to go about it would be even more better. Please understand that its an MS Access Projects.
Thanks
BOB
Compiling is not entirely an wrong statement.
In the VBA side, there is a an option under the Debug menu called Compile (I don't believe its truly a compile like in C, but it is pre-parsing your code, etc.). This combined with building an MDE in the GUI side equates to compiling.
Typically, when working with the VBA I'll run the Compile frequently to make sure everything is syntactically correct, etc.
As far as testing goes, once you know that it compiles you still aren't done. If can compile and still be wrong. That's why you need automated test scripts. I'd consider a little script/form within the MDB that you can run manually to open and close all the Reports are concerned about and exercise the code. Actual form functionality would be more tricky to automate, but could be done as well.
Related
I have created an SSIS-Package, which is supposed to import Data from Flatfiles (txt. Files) into a Database.
When I execute the package via Visual Studio (Enterprise, 2015), there are no problems and everything works just fine.
The problem occurs when I deploy the package into SSMS (Express, 2014). When I execute the package from SSMS, I get an Error (no idea if there is an Error Code or where to find it) concerning the property "CreationName". SSMS doesn't seem to give me any other information.
In the package are 5 scripts, which all do the same but with different flatfiles.
They all get this CreationName Error.
Has anyone any idea on how to fix it or the source of the problem?
i solved the problem, but it had nothing to do with the creationname apparently - i made some wrong settings in my sql agent + i made it work by deplying it from my hard drive instead of the virtual drive. I also had a typo in one of the scripts :x Idk why it had problems with the virtual drive though; maybe it was an authentication problem. Still THANK YOU ALL SO MUCH! You guys kinda brought me there :)
I don't understand what's written on the attached image, but I would disable 4 out of 5 components then run through the job. If there's no error than disable 3 out of 5 and run it again...you get the point. Obviously this has to be done in a non-prod environment. I believe that will help you narrow down the problem within your package. Maybe you can debug from thereon?
I just installed the latest version of SQL Server Design Tools for Visual Studio 2017 (in order to get SSIS templates etc.)
Prior to this I could right-click a report in Solution Explorer and choose run, and this would deploy and run just that one report, but not the others in the project.
Now it seems that when I do the same, all reports (and data sources) in the project are being re-deployed every time I try this. It's not a huge problem, but I liked the old way, in case somebody knows of a little setting tweak in there - I've not found it yet in search.
We had a similar problem when we recently upgraded our setup.
The first thing to note is that Run isn't typically used as a deployment model. It's supposed to be something used for testing, so the behavior you're seeing is likely related (in part) to that. To actually deploy a report, you should be using Deploy, which is right above the Run option.
Additionally, we often saw this behavior when VS could not completely build the entire solution. If you have any reports in your solution that don't build, or are missing (as in they're in the solution but not on disk), the overall build "failed".
That means that VS will continue to try and rebuild the whole project each time you build, run, or deploy anything. If you remove everything from your solution that doesn't pass, and then do this once, you should notice that behavior goes away.
Thankfully this bug was fixed in Reporting Services Projects 1.18.
I have a very large amount of code written in VBA in Access .mdb files, containing forms and connecting to an Access data base. I need to migrate this code to a VB6 application. It isn't practical to rewrite all of it as there is just too much.
Is there a way to call that VBA file from a VB6 form with buttons, that would allow users to launch each one of these VBA modules, via a simple click on its corresponding button? What line of code in VB6, allows to launch a VBA file?
Update
I finally succeeded to figure out how to launch a VBA mdb file from my VB6 form using this instruction :
Call Shell("C:\Program Files (x86)\Microsoft Office\OFFICE11\MSACCESS.EXE C:\presto.mdb /runtime /cmd", 1)
So the VBA project is now launched from the VB6 form, but it crashes, at start up, showing this error "Runtime error ‘3024’ Could not find file ‘C:\db.mdb’".
I feel like I'm half way to thee solution. But I don't know what am I missing here?
Without knowing the structure of your VB6 application and your access files and what they do, it is virtually impossible to give any sort of useful answer.
What you want to do is not easily possible, as stated in comments VBA projects are not designed to work in this way.
However here are some suggestions.
Investigate the RunMacro command and see if this is of use to you.
You could try to use a tool like autohotkey to record mouse clicks where you want them and replay from your VB6 app.
Look at pulling out sections of VBA that are business logic and directly copy and paste code into your VB6 app. This may or may not work depending on the code.
Begin the slow process of rewriting (but don't rewrite in VB6, use VB.Net, C# or do a web app or something at least resembling a 2015 application).
If you want my honest advice begin to migrate to a more modern solution such as VB.NET so you won't have an even worse problem in 2020.
There is NO silver bullet for your problem.
It would be better to design a new form in VB6 with button as you said but also with some text(s)/list(s)/whatever(s) you want to display the results, then you copy/paste VBA code into button_click(s) event(s) to execute it and add to that vba code some output to the text(s)/list(s)/whatever(s) you decided to put on the VB6 form.
Edit : Ok, so taking your comment in consideration perhaps that trick could help avoiding re-write thousands of line code : add in the VBA code a while loop that trigger some Sub or Function on the presence of a flag on the system (a specific c:\temp\fileFlag.txt for example) so as soon as it appear the VBA code is called... if the VB6 control the flag would it do the job ? :)
So currently my boss and I are the two employees that work on our company's access database. I just got Office 2013 on my computer and he is will working with 2010. We have ran into some inexplicable bugs with the database.
Most of these can be fixed by just copying an old version of a form or report into the database when it fails; however, it is quite disconcerting when we spend hours trying to discover why something is wrong and are able to fix it without explaining why.
Most of the issues so far have occurred when I am using the db in Access 2013. So far the issues have been:
Access occasionally crashes and restarts when I am working in the VB code
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile erro. To further explain the "bugging out", the form usually contains about 2000 separate forms that you can search through, but when it bugs out it will only show one blank form. At first I panicked thinking all the table's data was gone, but nothing changed the table
There have been other hiccups, but nothing noteworthy besides these two
I guess my question is if anyone else has had issues along these lines, or if they knew of any other known issues. I tried to research errors people have been having, but I couldn't find anything besides Microsoft's official release of what features were being deleted.
As always, thanks in advance!
Your system should be split into two files. FE(front end) containing all forms, queries, code, etc., linked to the BE. BE(back end) containing the data tables only.
Maintain a development copy of the FE that is only used for making modifications.
Each user should have their own copy of the FE on their local machine. If you don't know how to split, just search for it as there are plenty of instructions out there.
I have 2010, but I worked with a consultant who worked on the same project in 2013. I too, saw some behavior that looked like version related bugs, but nothing definite.
Responding to your list:
Access occasionally crashes and restarts when I am working in the VB code -- This has happened to me in every version of Access I have used, from 97 to 2010.
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile error... -- If the compile error is severe enough to lose project state, this is not surprising.
Recommendations:
Decompile your application front-end occasionally, especially when 'weird' errors show up. See this SO link: automating decompile / recompile in ms-access
Compact & Repair at least daily while developing your application
Backup! Do this at least for every significant revision. Sometimes, the Access front-end will become so corrupt that it trashes all of your work. When this happens, nothing is recoverable.
We have developed Custom SSIS components that integrates with an online REST API (Shopify to be precise) and these components work fine in BIDS and every single time too. However, when I create a SQL Server Agent job for the SSIS package that uses the components, some of the components don’t work, there is no error, just never hits the Pre Execute. The components that don’t work call the REST API and set specific TAGS on some orders, they do so using a JSON. The SQL Server agent is running on the same machine (my own) and it's executing the same SSIS package that works in BIDS. There are no errors and the SQL Server JOB reports success.
My machine is a 64 bit setup, so obviously the Agent will be running in 64bit so there may be issues there.
This is what I have tried already
Changed the SQL Server Agent user to eliminate the issue being a proxy/user issue.
Changed the setting for the step to use 32bit runtime (Ticked “Use 32 bit runtime”)
I have tried compiling my code using Any CPU x86 x64 .. with different results but none of them work etc
The installation project (which is part of the solution) is a WIX Toolset project which can only compile using x86 which I don’t think I can change.
Logged where it is getting to a log file.
I think it might be 32bit/64bit issue but maybe wrong. The log file shows the following
When called from BIDS (works)
• Validate (code running as 32bit)
• Validate (code running as 32bit)
• Hits Pre Execute and it all works thereafter
When called from SQL Server Agent (doesn’t work)
• Validate (code running as 32bit)
• Validate (code running as 64bit)
• Never hits the Pre Execute
Like I said, I suspect it being a 64bit issue but maybe wrong.
Hi guys and sorry for not posting the answer.
First of all thank you for all your help, especially Nick McDermaid as you kept trying and trying. I really appreciated your pointers and without them I wouldn't have solved it ( kind of solved it :o) ).
My SSIS Custom components only work when I have a "Success path" coming out of them. This was only an issue on this particular occasion because it was the last component called in my Data Flow.
This could be down to a bug in my SSIS Custom Component but I am sure I have had this issue with other components in the past (I think it might have been the 'Send Mail Task').
If anyone comes across this issue again then I would love to hear from them.
I'm currently fire fighting at work so hadn't had a chance to look at the SSIS Custom Components again.
Once again, thanks for the help I received.
I realize this question is very old, but I thought I'd put in my answer. I just ran into this very issue and the answer was that the SSIS engine didn't see the custom component doing anything so it removed the component at runtime. I was able to get around this by changing the RunInOptimizedMode property of the Control Flow object to False. After this I was able to run the SSIS package as a SQL Agent job.
If you run the package through dtexec.exe as bilinkc suggested in your comments, it should give you messages that make it obvious if this is occurring.