Trouble specifying which database alarms get saved to (DSC)

[Mattjk]

Hello,

I am having a hard time specifying where the alarms are saved in the database.  I used an example built into Labview:

-Example finder

-toolkits and modules

-datalogging and supervisory control

-Fundamentals

-Create Online Process.vi

I modified the code to create only one shared variable instead of 4.  I also added some code to craete a database.  I have tried to pipe the database info into "create process" to specify where the alarms get saved.  I am more interested in the alarms than the shared variable values (It's a lone explaination).  After I run the code, I go into MAX, right click on Citadel 5 and create a new alarm view.  On the filter tab I select the newly created database and pick a time range.  Then I click on the Display tab and click refresh.  No alarms were saved here.  I do the same process with the Default_Database and I can see that the alarms were saved here.  

What am I doing Wrong?

Thanks

Matt

[Dave.T]

Hi MattyK, 

Try committing your shared variables before trying to write to them.  Looking at your code, it looks like you might be writing to them before you commit them. 

Take a look at the following knowledgebase:

http://digital.ni.com/public.nsf/allkb/401624509525B9508625783A00749B32?OpenDocument

Let me know if this helps, 

Thanks,

[Mattjk]

I am committing the shared variables before I write to them with the error wired to the for loop.  I tried putting the open data socket into a sequence so that the commit runs first before the open datasocket.  This makes no difference.  This takes 2 seconds to try.  You should have tried it before you assumed that this is the solution.  Thanks for trying though.

Matt

[Dave.T]

Hi MattyK, 

I'm seeing the same thing you're seeing and trying to debug it as we speak.  I am also able to create it in the default database and can see the alarms. 

One thing I want to note in the code that I've seen so far, is that when you're looking to see if the database already exists and delete it if it does, you'll have to undeploy the library that is associated with it or you'll get an error when trying to delete it. 

I'll keep you posted as I find out more information about this.  

Dave T.

[Mattjk]

Thanks for the help dave.  Undeploy, I'll have to add that.

[Dave.T]

Where are you creating and storing your database? 

I was able to successfully save and view historical alarms once I save the database to "c:\testdatabase"

If you're using an Windows Vista or Windows 7, Microsoft restricts your access to folders like "c:\users" , which is where I was initially trying to save my database.  Once I changed the location of my database I was successful. 

Let me know if this helps. 

Thanks, 

Dave T.

[Mattjk]

I am running Windows XP.  I just tried using another directory: c:\database.  All the necessary files were created.  Everything seemed fine.  Alarms are still being saved to the default database.

[Dave.T]

Hi Mattyk, 

I understand you've opened an email service request regarding this issue.  

Once the solution is found we'll copy the solution here and reply to your email. 

Thanks, 

Dave T.

[Mattjk]

OK Dave.  Are you still working on it?  You said that changing directories of where the Database was created solved your problem.  This did not solve my problem.  Can you try this solution on another PC to see if this solution works on all PCs?

[Dave.T]

I can set up a computer to duplicate your set up. 

What version of LabVIEW and dsc are you running?  Are you running XP SP3?   

Can you verify that you have administrator privileges?  Are you able to create these alarms when you use the project explorer to create the variables? 

I'm attaching a zip file that uses this method.  Can you try this and let me know the results? 

Run simplevi.vi  and go into the alarms and events viewer.  You should see 1 alarm when the data goes to 91.  

If you're not using LabVIEW 2010 sp1, let me know what version you are using, and I can save it for a previous version for you. 

Thanks, 

Dave T.