Data Base Management
-
-
@WrCombs said in Data Base Management:
but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Just important to not repeat things that make no sense. You know that the people you work with don't know this stuff and just say random things. So repeating it as if it might be accurate will cause problems. You should present it as "I was told X by people who don't understand IT, and I need to do Y..."
Don't present it as if you think that they might be correct. They might be, but it isn't very likely. But there is likely something to be discovered if we read into what they describe.
-
@scottalanmiller said in Data Base Management:
@WrCombs said in Data Base Management:
but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Just important to not repeat things that make no sense. You know that the people you work with don't know this stuff and just say random things. So repeating it as if it might be accurate will cause problems. You should present it as "I was told X by people who don't understand IT, and I need to do Y..."
Don't present it as if you think that they might be correct. They might be, but it isn't very likely. But there is likely something to be discovered if we read into what they describe.
Fair enough. This is just the way I'm told this is how it works- From the understanding of Point of sale.
-
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Right - so with what you just said - at no time does someone manually touch the DB files.
Your Software is what updates the SQL DB. Then the refresh process creates the changes send to Folder A, then the overwrite of folder B happens by another process.
I see no point where you need to actually deal with or worry about the DB files themselves.
So that we can see when changes were made: I've had multiple sites call in about things not working only to find out that somone changed the Settings and refreshed - Viewing database files helps us tell the site what happened and how to change it back.
That's really all we need it for.
Lets say a printer is set up to be on com port 2 and someone moves it to one in the office but not on the terminal it's self.
I need to be able to see the change so I can get that printer working again.
Does that make sense ?It makes sense. But it isn't nearly enough info. That you have database files called .dbf doesn't give us anything to go on. DBF files are not generic. So we get what you are trying to ask, but we don't have enough to actually tell you what you can do.
-
@WrCombs said in Data Base Management:
@scottalanmiller said in Data Base Management:
@WrCombs said in Data Base Management:
but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Just important to not repeat things that make no sense. You know that the people you work with don't know this stuff and just say random things. So repeating it as if it might be accurate will cause problems. You should present it as "I was told X by people who don't understand IT, and I need to do Y..."
Don't present it as if you think that they might be correct. They might be, but it isn't very likely. But there is likely something to be discovered if we read into what they describe.
Fair enough. This is just the way I'm told this is how it works- From the understanding of Point of sale.
Yup, we understand that that is the case. It's just wording it so that we know that you know that that is the case
-
@scottalanmiller said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Right - so with what you just said - at no time does someone manually touch the DB files.
Your Software is what updates the SQL DB. Then the refresh process creates the changes send to Folder A, then the overwrite of folder B happens by another process.
I see no point where you need to actually deal with or worry about the DB files themselves.
So that we can see when changes were made: I've had multiple sites call in about things not working only to find out that somone changed the Settings and refreshed - Viewing database files helps us tell the site what happened and how to change it back.
That's really all we need it for.
Lets say a printer is set up to be on com port 2 and someone moves it to one in the office but not on the terminal it's self.
I need to be able to see the change so I can get that printer working again.
Does that make sense ?It makes sense. But it isn't nearly enough info. That you have database files called .dbf doesn't give us anything to go on. DBF files are not generic. So we get what you are trying to ask, but we don't have enough to actually tell you what you can do.
I thought .dbf was just a generic file name
-
@WrCombs said in Data Base Management:
@scottalanmiller said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs said in Data Base Management:
@Dashrender said in Data Base Management:
@WrCombs how about telling us how the company currently does whatever you're talking about.
Do they really - something sent to the DB, then somehow translated to folder? then, then, then, etc?
Yeah - I barely understand what JB said - I've had only the tiniest of exposure to DB management/etc.
the way it was explained to me was : We make changes in our software. It is sent to SQL database , when we "Refresh" the data and send out information it goes to folder "A" and then copies over Folder "B" which is where the terminals pull their information.
in older versions - The dbfs are created by the software and help in folder "A" and copied over to folder "B" when refreshed and sent out.but Im not in the mood to argue with people. This is how it was explained that's all I know.
If you want to help me understand it great, if you want to put me down fuck off.Right - so with what you just said - at no time does someone manually touch the DB files.
Your Software is what updates the SQL DB. Then the refresh process creates the changes send to Folder A, then the overwrite of folder B happens by another process.
I see no point where you need to actually deal with or worry about the DB files themselves.
So that we can see when changes were made: I've had multiple sites call in about things not working only to find out that somone changed the Settings and refreshed - Viewing database files helps us tell the site what happened and how to change it back.
That's really all we need it for.
Lets say a printer is set up to be on com port 2 and someone moves it to one in the office but not on the terminal it's self.
I need to be able to see the change so I can get that printer working again.
Does that make sense ?It makes sense. But it isn't nearly enough info. That you have database files called .dbf doesn't give us anything to go on. DBF files are not generic. So we get what you are trying to ask, but we don't have enough to actually tell you what you can do.
I thought .dbf was just a generic file name
All extensions are just generic file naming conventions. But databases cannot be generic. So the extension tells you one thing...
That the person naming it intended for you to assume that it is data for a database.
That's it. It doesn't tell you what kind of data, that it is really a database, that it is for a specific database, etc. Nothing. It could be a text file, a Word doc, an XML doc, malware, a JetDB data file, a SQL Server data file, dBase, FoxPro, Clipper, or one of thousands of things we aren't thinking of.
It's likely to be something legitimate and normal. But that leaves about a dozen totally unrelated options.
-
Keep in mine that database = "place to store and retrieve structured data". That's it. Nothing more, nothing less. So knowing that something is "a database" only tells you that the data is not completely unstructured, nothing else. That's not much to go on.
-
Let's start at the beginning. What is the PoS software in use? From that we should be able to track down what the actual database is.
-
@travisdh1 said in Data Base Management:
Let's start at the beginning. What is the PoS software in use? From that we should be able to track down what the actual database is.
I work with Aloha
-
@WrCombs said in Data Base Management:
@travisdh1 said in Data Base Management:
Let's start at the beginning. What is the PoS software in use? From that we should be able to track down what the actual database is.
I work with Aloha
-
@Reid-Cooper said in Data Base Management:
@WrCombs said in Data Base Management:
@travisdh1 said in Data Base Management:
Let's start at the beginning. What is the PoS software in use? From that we should be able to track down what the actual database is.
I work with Aloha
yep... I knew that part...
Which tool do you you to **VIEW** .dbf files for accuracy/ troubleshooting. -
@WrCombs said in Data Base Management:
@Reid-Cooper said in Data Base Management:
@WrCombs said in Data Base Management:
@travisdh1 said in Data Base Management:
Let's start at the beginning. What is the PoS software in use? From that we should be able to track down what the actual database is.
I work with Aloha
yep... I knew that part...
Which tool do you you to **VIEW** .dbf files for accuracy/ troubleshooting.None, because that's not a standard structure for any database tools.
-
Looks like an Oracle database from what I can find.
-
https://lonetreerob.wordpress.com/2012/06/26/the-technical-side-of-aloha-pos-integration/
Finally, from an Aloha interface perspective, I need to discuss the Aloha database file system. Instead of using a single large database file to store all of its configuration information, the developers of Aloha elected to put most of this information in Dbase format files (DBFs). You can read these files with Excel and you can read these files programmatically. You can write to these files, but that’s dangerous, because Aloha adds fields to these files from time to time with new versions—so you can end up having to write code that treats the DBFs differently, depending on the version.
Aloha is the database engine here. There is no database tool being used. It's just something akin to CSV files with DBF names. If you show us the contents of one of them, we could tell you in a few minutes what they are. But they are not from any "database" product, they are simply the data files of Aloha.
So it sounds like Notepad will likely work just fine.
-
@Reid-Cooper
Does this help?
https://www.tek-tips.com/viewthread.cfm?qid=1638861
https://posforum.net/aloha-pos-support/aloha-database-integration/
If those posts are right, Aloha uses dBase et al DBF files -
It's hard to tell what is working for people and what is just something someone is suggesting. Also there is a lot of conflicting info, for example some people are saying that the system "used to be" flat file based, then others saying it has changed and is now SQL based. But flat file refers to how the data is stored on disk, and SQL refers to how it is referenced through the application, so it's like saying that a car used to use rubber tires, but has changed and how has leather seats - maybe the tires changed, too. But that someone says that the seat material changed and they associated that with the tires just tells us that people don't know what they are saying.
-
Easiest thing, show some contents of any one of the files and we will probably have all that we need to know almost instantly.
-
@Reid-Cooper
it seems like there are 2 versions of Aloha, one uses a SQL database and the other uses only DBF files easily manipulable in Fox Pro. But it seems like the SQL based Aloha stills has DBFs in the server.So the easiest thing would be to download a dBase DBF viewer and try it on a copy of an Aloha DBF.
I'm out but I will check later to see if @WrCombs has success
-
@Reid-Cooper said in Data Base Management:
https://lonetreerob.wordpress.com/2012/06/26/the-technical-side-of-aloha-pos-integration/
Finally, from an Aloha interface perspective, I need to discuss the Aloha database file system. Instead of using a single large database file to store all of its configuration information, the developers of Aloha elected to put most of this information in Dbase format files (DBFs). You can read these files with Excel and you can read these files programmatically. You can write to these files, but that’s dangerous, because Aloha adds fields to these files from time to time with new versions—so you can end up having to write code that treats the DBFs differently, depending on the version.
Aloha is the database engine here. There is no database tool being used. It's just something akin to CSV files with DBF names. If you show us the contents of one of them, we could tell you in a few minutes what they are. But they are not from any "database" product, they are simply the data files of Aloha.
So it sounds like Notepad will likely work just fine.
and nailed it..
